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

---

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

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

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

敏捷Agile和DevOps以及測試瓶頸

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

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

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

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

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

什么是右移測試？

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

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

圖3：轉移權利測試依賴于可靠的開發(fā)運營基礎架構來在面對關鍵缺陷時回滾發(fā)布。

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

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

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

測試影響分析

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

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

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

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

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

總結

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