累積測試分析和目標測試入門[2] 軟件測試
在不了解那些測試的價值的情況下，花費您大部分的時間來確定壞掉的測試嗎?
瞄準 100% 運行您所有的測試的目標嗎?在質量和風險方面您了解此目標嗎?
您可能需要的是，不再瞄準任意數量的測試，而著眼于從上次測試以來在產品中實際變更的功能是什么，以及測試此變更所需要的是什么�？偠灾�，您需要轉移到更深思熟慮的“目標”測試的方法。
停止運行測試，開始尋找缺陷
通常所說的累積測試分析(Cumulative Test Analysis，CTA)方法是基于五個基本原則的：
定期地運行自動化的測試。
了解現有測試材料的實際覆蓋和質量。
運行盡可能少的測試。將測試關注在只運行那些覆蓋了發生變更的功能的測試。
在做出評估時考慮所有的測試活動。
由四個較早的步驟所節省下來的時間可以用于增加測試套件的質量，或者執行額外的測試。
讓我們按順序討論這些原則。
原則 1：定期地運行自動化的測試
CTA 方法著重于通過在整個的開發循環中運行自動化的測試將“發生缺陷的時間” 1 最小化。任何回歸類型的缺陷都可以很早發現，并且與在循環的末尾運行單個的長期回歸運行相比使用了最小量的測試。
此測試的目標是提供對所有驅動程序的功能質量的一個觀察，作為進一步測試和最終向市場發布的基礎。此回歸測試減少了進入最終產品的缺陷數量，以及在這期間，減少可能防止新特性的更復雜的測試的基礎功能問題。由此可見，這些回歸類型的缺陷需要在其最方便確定的時候盡可能快速地清理掉。
原則 2：了解回歸測試套件中現有測試材料的質量和覆蓋
如早先討論的，包含于回歸套件中的許多測試在任何規模的測試操作中可能不能生成可靠的結果。為了完全了解產品的質量，事實上，根據潛在的產品缺陷，您在觀察的結果意味著什么，您必須首先了解測試實際上測試的功能是什么。
為此，我們求助于代碼覆蓋的使用。對于外行來說，這實際上是所有方法、類和測試從開始到結束所經過的代碼途徑的細微痕跡。這種在一個測試接一個測試的基礎上的運行時度量提供了對測試做什么的觀察，并且比起在實際的測試運行過程中的運行時收集信息時依賴于測試計劃或測試文檔來說，是一種了解要測什么內容的更精練的方法。當然，對于此途徑存在著由，例如，尋找缺陷并執行異常路徑的測試引起的偏差�？偟膩碚f，盡管，如果代碼覆蓋數據是在成功的測試運行過程中收集的，那么此信息可以存儲起來隨后作為測試的功能的指示。
有許多可用的工具可以提供代碼覆蓋率。它們都典型地使用被測代碼的某種形式的裝置，這將鉤子(hooks )加入了產品代碼中。當測試材料遇到這些鉤子時，代碼覆蓋工具使用這些鉤子來記錄每個測試在其執行時所經歷的過程。最終結果是一個表示與特定的產品驅動程序沖撞的所有測試的完全覆蓋的數據庫。因為回歸測試材料隨著時間的推移變化得不大，那么此數據仍舊相對靜態。然而，如果產品或測試材料隨著時間的推移變化很大，那么就需要重復實施裝置。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
