累積測試分析和目標測試入門[6] 軟件測試
利用該技術，我們立即有了更多要考慮的信息：
橙色“遺漏”結果表明構建 1 和 2 沒有充分的測試，但它們從對早期的構建的測試(沒有顯示)那里帶來了非常多有效的結果。
對構建 3 的測試減少到遺漏測試累積的大約三分之二，所需的余下的測試在整個過程中都沒運行，直到構建 11。
附加的測試針對于構建 6(“遺漏”測試的數量增加)，說明對產品有附加的功能變更。
對許多構建出現了大量的測試，構建 3、構建 9 和構建 11 特別的昂貴 —— 問題是，這些都是必要的嗎?
接下來，因為知道變更是 CTA 的重要部分，所以我們引入一個圖 4 中的新圖表，顯示出每次構建中變更的影響，以及那些變更測試得有多好。數據重新從構建帶到相關的構建中，被變更了的類被反映在零線以上，而覆蓋這些變更的測試在零線以下。充分測試的變更將因此顯示為一個綠色的條，處于與上面所示的變更相同高度的軸之下。
圖 4：每此構建的變更以及所完成的測試
通過傳統的回歸測試的觀點查看該數據，可以看到，對構建 3 的測試是有效的，但是構建 4 到 8 中對產品類的附加的功能變更(顯示為“新的”或者“非常新的”項)，直到構建 11 才完全測試完成。上面較早描述的其它提示點：
構建 1 中出現的大量變更，并且幾乎所有這些都對構建 3 充分測試了。
在構建 3 之后，許多未測試的變更從一個構建帶到了下一個中，使“確定缺陷的時間”拉得更長。
在構建 4 和 5 中出現的大量變更，可能已經否定了早先執行的測試的某些好處。更重要的是，對構建 3 運行的并且隨后不在循環中重新運行的測試可能會錯過構建 4 或之后引入的缺陷。
我們管理了對每個構建運行的少量測試，我們將提供所引入變更的最有效的覆蓋。
利用目標測試使效果最大化
指出了老方法中的不足，我們現在使用新的方法。假設相同的環境，通過 CTA 可以完成什么?要論證這點，如先前一樣，我們使用同樣的兩個圖表，圖 5 和 6 中分別顯示出結果和變更。
圖 5：利用目標測試方法的 CTA 累積測試結果
圖 5 和 6 中的數據是基于已經部署了累積測試分析和目標測試的測試團隊，在需要覆蓋每次構建中的變更時只運行那些確定出來的測試。
文章來源于領測軟件測試網 http://www.kjueaiud.com/