在圖 7 中的實例中,組 S3、S4 和 S5 不唯一地覆蓋 S1 和 S2 所覆蓋的任何方法,然而,通過運行它們,團隊可以確定它們可以運行觸及部分變更的每一個測試。
最顯著的是,橙色區域 —— 沒有被綠色覆蓋的部分 —— 在圖中表示根本沒有被回歸套件中的測試覆蓋到的變更。因此團隊需要將他們工作的重點集中于撰寫提供此覆蓋的測試,為了完全測試變更并且將錯過潛在缺陷的風險減少到其最低可能的值。幸運的是,CTA 方法給團隊時間來開發這些所需的測試。
心理轉變
這不是新技術或一種根本的新樣式。背后的思想在最初設想代碼覆蓋時就出現了。技術提供的東西,盡管,從測試團隊的觀點來看是一組直覺上正確的思想,但這仍舊表示對許多內容強調的基本變化。只運行測試的子集去掉了“做一些有價值的事情”的興奮感覺,這是運行整個回歸套件的傳統實踐提供的感覺。該新方法還需要來自于項目管理團隊對不再朝著基于風險的 100%的運行目標,而只對每次構建運行恰當的測試的了解和支持。這沒有去掉將團隊著重于調試測試失敗或撰寫新測試的需求,但這樣做可以為做重要的工作贏得額外的時間!
注釋
1 發現缺陷的時間(Time to defect):將缺陷引入到產品代碼中和將缺陷報告分配給進行確定的開發人員期間經過的時間。
原文轉自:http://www.uml.org.cn/Test/200610251.htm