更加智能而非更加艱難的測試：擁有測試影響分析的左移和右移測試

---

測試影響分析意味著將測試重點放在每次迭代期間所做的更改上，并自動準(zhǔn)確地測試需要測試的內(nèi)容。利用此技術(shù)的團隊可以通過即時反饋有關(guān)需要完成的工作來優(yōu)化開發(fā)中的測試工作。

經(jīng)過行業(yè)調(diào)查和報告的頻繁確認，即使在實施了敏捷Agile、DevOps和持續(xù)集成/部署等現(xiàn)代開發(fā)流程之后，軟件測試仍然是瓶頸。在某些情況下，軟件團隊的測試能力不足，并且不得不在開發(fā)周期的后期階段處理bug和安全漏洞，這錯誤地假設(shè)這些新流程無法兌現(xiàn)其承諾。某些問題的一種解決方案是右移測試，該測試依賴于在生產(chǎn)環(huán)境中監(jiān)視應(yīng)用程序，但是它需要堅如磐石的基礎(chǔ)架構(gòu)才能在出現(xiàn)嚴重缺陷時回滾新的更改。

結(jié)果，組織仍然無法按時完成任務(wù)，質(zhì)量和安全性也在遭受損失。但是有更好的方法！為了進行更明智的測試，組織正在使用一種稱為“測試影響分析”的技術(shù)來準(zhǔn)確了解要測試的內(nèi)容。這種數(shù)據(jù)驅(qū)動的方法支持左右移位測試。

敏捷Agile和DevOps以及測試瓶頸

任何迭代過程中的測試都是在有限的循環(huán)時間內(nèi)可以進行多少測試的折衷方案。在大多數(shù)項目中，不可能對每個迭代都進行完全回歸。取而代之的是，執(zhí)行一組有限的測試，而測試的內(nèi)容正是基于最佳猜測。由于通常沒有足夠完整的新功能來進行測試，因此測試也被循環(huán)加載。最終的工作量與時間的關(guān)系圖就像鋸齒一樣結(jié)束，如圖1所示。在每個循環(huán)中，僅執(zhí)行有限的一組測試，直到執(zhí)行完整回歸測試的最后一個循環(huán)為止。

圖1：敏捷Agile過程導(dǎo)致測試活動“鋸齒”。只有完整的回歸周期才能進行“完整”測試。

不幸的是，沒有一個項目能夠以零錯誤和零安全漏洞到達最后一個周期。由于已修復(fù)并重新測試了錯誤，因此在此階段發(fā)現(xiàn)缺陷會增加延遲。即使存在所有這些延遲，仍然存在許多錯誤，如下所示。

圖2：集成和全面回歸測試永遠不會出錯。后期缺陷會導(dǎo)致進度計劃和成本超支。

這種情況導(dǎo)致采用了所謂的“右移測試”，即組織繼續(xù)在部署階段測試其應(yīng)用程序。右移測試的目的是擴大和擴展測試工作，在部署階段最適合測試，例如API監(jiān)視，切換生產(chǎn)中的功能，從實際操作中獲取反饋。

什么是右移測試？

在重現(xiàn)現(xiàn)實的測試環(huán)境以及在測試中使用真實的數(shù)據(jù)和流量的困難導(dǎo)致團隊不得不使用生產(chǎn)環(huán)境來監(jiān)視和測試其應(yīng)用程序。這樣做有很多好處，例如，能夠使用實時生產(chǎn)流量測試應(yīng)用程序，從而支持容錯和性能改進。一個常見的用例是所謂的canary版本，其中首先將軟件的新版本發(fā)布給一小部分客戶，然后在報告和修復(fù)錯誤時將其發(fā)布到越來越多的客戶群中。例如，Roku這樣做是為了更新其設(shè)備固件。

右移測試依賴于開發(fā)基礎(chǔ)架構(gòu)，該基礎(chǔ)架構(gòu)可以在發(fā)生嚴重缺陷時回滾發(fā)布。例如，金絲雀版本中存在嚴重的安全漏洞，這意味著回滾該版本，直到準(zhǔn)備好新的更新版本為止，如您在此處的插圖中所見：

圖3：轉(zhuǎn)移權(quán)利測試依賴于可靠的開發(fā)運營基礎(chǔ)架構(gòu)來在面對關(guān)鍵缺陷時回滾發(fā)布。

但是使用生產(chǎn)環(huán)境來監(jiān)視和測試軟件存在風(fēng)險，當(dāng)然，右移測試的目的絕不是在部署之前替換單元、API和UI測試實踐！右移測試是一種補充實踐，將連續(xù)測試的理念擴展到生產(chǎn)中。盡管如此，組織可以輕松地濫用該概念來證明在開發(fā)期間進行更少的單元和API測試是合理的。為了防止這種情況，我們需要在開發(fā)階段進行測試，以使其更容易，更具生產(chǎn)力并生產(chǎn)質(zhì)量更高的軟件。

通過專注于測試，更智能而不是更艱難地進行測試

大多數(shù)軟件尚未經(jīng)過全面測試，而測試內(nèi)容的決定基本上是基于開發(fā)人員對關(guān)鍵功能的最佳猜測。在SCRUM沖刺或其他過程的迭代過程中，很難確定要測試的內(nèi)容，因為“測試所有內(nèi)容”當(dāng)然不是一種選擇。由于時間很短，因此只能測試通過最新功能更新的軟件部分，但是確切地知道受影響的代碼通常是未知的。測試自動化會有所幫助，但是如果不確切了解要在哪里進行測試，則測試覆蓋率是不夠的。

測試影響分析

這些缺點可以通過使用測試影響分析來克服，這是對測試覆蓋率，代碼更改和相關(guān)性的多變量分析，可準(zhǔn)確指出需要測試的代碼。此外，可以將這些確切的測試安排為自動執(zhí)行。

測試影響分析在IDE中的開發(fā)人員級別上進行，收集有關(guān)哪些測試執(zhí)行哪些代碼的信息，并在開發(fā)人員更改代碼時在開發(fā)人員的IDE中應(yīng)用該信息，從而使開發(fā)人員能夠輕松地識別和執(zhí)行特定的測試，需要運行以驗證更改后的代碼不會破壞任何測試。同樣，跟蹤哪些受影響的測試已經(jīng)運行，通過了哪些以及失敗了，這使開發(fā)人員可以輕松地確定哪些測試仍然需要運行，或者哪些測試失敗了并且需要解決。一旦所有測試運行并通過，開發(fā)人員就會知道提交代碼并繼續(xù)進行是安全的。

通過無縫集成到項目的構(gòu)建系統(tǒng)（例如Maven或Gradle）中，測試影響分析可在CI/CD流程中進行，以獲取有關(guān)更改的即時反饋。測試影響分析可確定自基線構(gòu)建以來（即最近的夜間構(gòu)建）更改了哪些代碼，確定需要運行哪些測試以執(zhí)行該代碼，然后僅運行該測試的子集。通過此工作流程，團隊可以設(shè)置僅基于最新代碼更改運行測試的CI作業(yè)，從而將運行CI作業(yè)所需的時間從數(shù)小時縮短至數(shù)分鐘。

測試影響分析具有以下主要優(yōu)點：

• 了解每個測試涵蓋的內(nèi)容：通過將測試執(zhí)行數(shù)據(jù)與測試覆蓋數(shù)據(jù)自動關(guān)聯(lián)，測試影響分析提供了一種機制，可以根據(jù)當(dāng)前正在開發(fā)的代碼來確定需要運行哪些測試。用戶可以節(jié)省時間而不必運行不必要的測試，并且團隊可以從開發(fā)過程中以及代碼簽入后的即時反饋中受益。
• 了解發(fā)生了什么變化：開發(fā)人員通常不知道要運行哪些測試來驗證代碼更改，因此他們要么（a）在不運行任何測試的情況下檢入他們的代碼（一種非常糟糕的做法），（b）僅運行一個或兩個測試他們知道的信息（很容易錯過一些信息），或（c）運行所有測試（浪費時間）。測試影響分析通過立即確定哪些測試與哪些代碼更改相關(guān)來解決此問題，并通過自動執(zhí)行測試來進一步采取措施。簽入代碼變得更加穩(wěn)定，因為在簽入之前已經(jīng)對其進行了全面的測試。
• 專注于驗證更改和受影響的依賴關(guān)系的測試：僅識別和運行驗證自上一次基準(zhǔn)構(gòu)建（通常是每晚構(gòu)建）以來已提交的所有代碼更改和受影響的依賴關(guān)系所需的一組測試，即可顯著減少運行CI所需的時間。這使團隊可以從真正的CI流程中受益。
• 立即和持續(xù)的反饋：測試影響分析不僅識別測試和代碼之間的直接依賴關(guān)系，還識別間接依賴關(guān)系，可幫助團隊在檢查代碼后盡快了解代碼是否破壞了測試。

總結(jié)

為了大大減少開發(fā)中的測試瓶頸，并提高測試人員在每次迭代中投入的“鋸齒”工作效率，開發(fā)團隊可以從測試影響分析技術(shù)中受益。具有測試影響分析的測試自動化意味著將測試重點放在每次迭代期間所做的更改上，并自動準(zhǔn)確地測試需要測試的內(nèi)容。這些團隊通過對需要完成的工作，哪些代碼無法通過測試以及哪些其他代碼受到新更改的影響的即時反饋，來優(yōu)化其開發(fā)中的測試工作。