累積測試分析和目標測試入門[7] 軟件測試
從此結果數據中看，第一件要注意的事情是采用了較少的測試 —— 實際上，相比使用傳統方法的 3000 個，運行了大約 1700 個測試。這在圖 5 中顯示為較少的“新的”或“重新運行的”測試，這可以折合為相對短的時間間隔內的重要的時間節省。
圖 5 和 3 中第二個明顯的差別是構建 3 之后沒有橙色的“遺漏”條了。在這種情況下，測試團隊利用許多構建來測試構建 1 中引入的所有變更，而在很短的一段時間內，運行了所有確定的測試。即使有這一點延遲，確定缺陷的時間比傳統方法減少了。更重要的是，在測試循環中出現的測試中，不再存在對最終構建質量上的觀察的 11 天的延遲。這極大地降低了一個已被交付的未測試的變更風險。
圖 6 中還說明了效率，這顯示出更少量的從一次構建到下一次的未測試的或“帶過來的”變更。通過在引入了缺陷的構建中找到這些缺陷，可以盡可能低成本地進行確定，并且減少了相互依賴的缺陷修復的復雜鏈的風險。對一次構建啟動測試，并在隨后的構建中償還債務的方法，只要在后繼的構建中相同的功能沒有變更時都會有效。
最后的重點是相同的缺陷 —— 也就是，圖 5 中的失敗測試 —— 用新的和舊的方法都找到了。
圖 6：利用目標測試方法，每個構建的變更和完成的測試
原則 4：考慮對所有構建執行的所有測試
CTA 的第四個基本原則依賴于這樣的事實，每個對軟件的測試都提供一個質量指數。該測試可能延伸到基本的產品安裝、單元測試、簡單的配置，或正式的 FVT 或 SVT 活動。類似的，如果在不同的環境中運行同樣的或相似的測試(舉例來說，在不同的操作系統上)，那么結果應該包含于質量說明中。
此原則的一個擴展是這樣一個事實，對一個沒有變更的功能執行的測試可能仍舊認為是有效的。如圖3 和 圖5 中所示，允許收集累積的結果。同樣的，如果新的區域內的后繼測試提供了一個存在測試問題的指示，那么這也應該包含于質量評估中。因此在提供已知構建的質量投影的時候，工具考慮了所有測試。
原則 5：利用節省的時間來提高質量、撰寫新的測試
利用 CTA 和目標測試意味著您不再有 100% 執行的目標了。確切地說，目標隨著對產品做出的變更日復一日的改變。問題出來了：人們如何知道什么時候回歸測試完成了?回答很簡單：直到所有變更都停止了，并且覆蓋所有的變更 —— 那些由分析過程所確定的 —— 的測試都運行了，測試才完成。在這一點上，團隊利用回歸套件幾乎完成了每件可能的事情，以確保不會引入額外的缺陷。
文章來源于領測軟件測試網 http://www.kjueaiud.com/