累積測試分析和目標測試入門[8] 軟件測試
注意我們說過“團隊幾乎做了每件事情”，因為方法將只瞄準那些已經包含于回歸套件中的測試。如果因為出現了變更，當您沒有對變更進行測試，那么您將會無法查看到您仍舊具有的風險。
使用此新方法，您可以確信的是，您已經運行了您現有的測試組合中可能的每個測試，來確保最低可能的風險。圖 7 例舉了這一點，基于每個變更類型中方法的唯一覆蓋率，顯示出測試套件和它們所覆蓋的變更之間的關系。
圖 7：測試套件和它們所覆蓋的變更之間的關系
在圖 7 中的實例中，組 S3、S4 和 S5 不唯一地覆蓋 S1 和 S2 所覆蓋的任何方法，然而，通過運行它們，團隊可以確定它們可以運行觸及部分變更的每一個測試。
最顯著的是，橙色區域 —— 沒有被綠色覆蓋的部分 —— 在圖中表示根本沒有被回歸套件中的測試覆蓋到的變更。因此團隊需要將他們工作的重點集中于撰寫提供此覆蓋的測試，為了完全測試變更并且將錯過潛在缺陷的風險減少到其最低可能的值。幸運的是，CTA 方法給團隊時間來開發這些所需的測試。
心理轉變
這不是新技術或一種根本的新樣式。背后的思想在最初設想代碼覆蓋時就出現了。技術提供的東西，盡管，從測試團隊的觀點來看是一組直覺上正確的思想，但這仍舊表示對許多內容強調的基本變化。只運行測試的子集去掉了“做一些有價值的事情”的興奮感覺，這是運行整個回歸套件的傳統實踐提供的感覺。該新方法還需要來自于項目管理團隊對不再朝著基于風險的 100%的運行目標，而只對每次構建運行恰當的測試的了解和支持。這沒有去掉將團隊著重于調試測試失敗或撰寫新測試的需求，但這樣做可以為做重要的工作贏得額外的時間!
文章來源于領測軟件測試網 http://www.kjueaiud.com/
