您的測試團隊已經非常成功了。您已經對自動化大量投資，并且因生成大型且全面的測試集而著稱 —— 您可以無可非議地為之自豪！在整個開發過程和多個環境中，這些組合為您很好地服務。因此現在是您休息一會，并且收獲您所勞動的好處的時候了，對嗎？或者，您將成為您自己的自動化測試集的犧牲品？
也許，像許多團隊一樣，您已經達到飽和點，現在您有太多的測試，以至于不能說明。也許運行測試的團隊已經不再是撰寫它們的團隊了，并且知識是稀少的�；蛘咭苍S您受困于對大量所支持的環境和代碼流不斷地重復運行同樣的測試的工作。對于那些您不能運行的測試，或者您沒有時間運行的，您對您所帶來的風險進行過觀察嗎？
無疑地，如果您只運行少量的測試，并且仍舊在代碼中找到一樣的缺陷，這是更好的。通過運行可能的測試盡可能快地找到第一次出現的缺陷不同樣是更好的嗎？
不能達到的目標
甚至是出于一片好心，每個測試人員在他或她的工作生涯中，都將撰寫一個根本不測試所打算測試內容的測試。這可能是由于缺乏經驗，對產品功能設計的變更，因為測試人員做出關于產品或其預期使用價值的無效假設，或者只是因為測試人員用盡了時間�？偠灾�，最終結果是由于與產品缺陷不相關的原因而失敗的測試。
這些失敗測試的累積效應創造了回歸套件中的灰色區域，您的回歸測試的 5％ 到 15％是困難的、不可靠的或不可能成功地運行完成的。這些阻塞的或不可靠的測試消耗了寶貴的測試時間，并且混淆了測試人員對真實的產品缺陷的觀察，這導致了在回歸測試循環末尾的測試進度中的指數的縮小。虛幻的所有可用測試的100％ 的運行目標常�？雌饋矸浅＝咏�，但是卻難以達到。
自動化陷阱
也許您已經落入了嚴重依賴于您的測試自動化基礎架構的陷阱了。這里有一些您可能考慮的問題。您是：
- 缺少用于測試您所期望的每樣東西的資源嗎？
- 陷入無休止的測試循環嗎？
- 在沒有找到任何新的缺陷的情況下，運行成千上萬的測試嗎？
- 在不了解那些測試的價值的情況下，花費您大部分的時間來確定壞掉的測試嗎？
- 瞄準 100％ 運行您所有的測試的目標嗎？在質量和風險方面您了解此目標嗎？
您可能需要的是，不再瞄準任意數量的測試，而著眼于從上次測試以來在產品中實際變更的功能是什么，以及測試此變更所需要的是什么�？偠灾�，您需要轉移到更深思熟慮的“目標”測試的方法。
停止運行測試，開始尋找缺陷
通常所說的累積測試分析（Cumulative Test Analysis，CTA）方法是基于五個基本原則的：
- 定期地運行自動化的測試。
- 了解現有測試材料的實際覆蓋和質量。
- 運行盡可能少的測試。將測試關注在只運行那些覆蓋了發生變更的功能的測試。
- 在做出評估時考慮所有的測試活動。
- 由四個較早的步驟所節省下來的時間可以用于增加測試套件的質量，或者執行額外的測試。
讓我們按順序討論這些原則。
原則 1：定期地運行自動化的測試
CTA 方法著重于通過在整個的開發循環中運行自動化的測試將“發生缺陷的時間” 1 最小化。任何回歸類型的缺陷都可以很早發現，并且與在循環的末尾運行單個的長期回歸運行相比使用了最小量的測試。
此測試的目標是提供對所有驅動程序的功能質量的一個觀察，作為進一步測試和最終向市場發布的基礎。此回歸測試減少了進入最終產品的缺陷數量，以及在這期間，減少可能防止新特性的更復雜的測試的基礎功能問題。由此可見，這些回歸類型的缺陷需要在其最方便確定的時候盡可能快速地清理掉。
原則 2：了解回歸測試套件中現有測試材料的質量和覆蓋
如早先討論的，包含于回歸套件中的許多測試在任何規模的測試操作中可能不能生成可靠的結果。為了完全了解產品的質量，事實上，根據潛在的產品缺陷，您在觀察的結果意味著什么，您必須首先了解測試實際上測試的功能是什么。
為此，我們求助于代碼覆蓋的使用。對于外行來說，這實際上是所有方法、類和測試從開始到結束所經過的代碼途徑的細微痕跡。這種在一個測試接一個測試的基礎上的運行時度量提供了對測試做什么的觀察，并且比起在實際的測試運行過程中的運行時收集信息時依賴于測試計劃或測試文檔來說，是一種了解要測什么內容的更精練的方法。當然，對于此途徑存在著由，例如，尋找缺陷并執行異常路徑的測試引起的偏差�？偟膩碚f，盡管，如果代碼覆蓋數據是在成功的測試運行過程中收集的，那么此信息可以存儲起來隨后作為測試的功能的指示。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
