加快回歸測試的步伐：累積測試分析和目標測試入門(4)

　　在構建 4 和 5 中出現的大量變更，可能已經否定了早先執行的測試的某些好處。更重要的是，對構建 3 運行的并且隨后不在循環中重新運行的測試可能會錯過構建 4 或之后引入的缺陷。

　　我們管理了對每個構建運行的少量測試，我們將提供所引入變更的最有效的覆蓋。

　　利用目標測試使效果最大化

　　指出了老方法中的不足，我們現在使用新的方法。假設相同的環境，通過 CTA 可以完成什么?要論證這點，如先前一樣，我們使用同樣的兩個圖表，圖 5 和 6 中分別顯示出結果和變更。

　　圖 5：利用目標測試方法的 CTA 累積測試結果

　　圖 5 和 6 中的數據是基于已經部署了累積測試分析和目標測試的測試團隊，在需要覆蓋每次構建中的變更時只運行那些確定出來的測試。

　　從此結果數據中看，第一件要注意的事情是采用了較少的測試 —— 實際上，相比使用傳統方法的 3000 個，運行了大約 1700 個測試。這在圖 5 中顯示為較少的“新的”或“重新運行的”測試，這可以折合為相對短的時間間隔內的重要的時間節省。

　　圖 5 和 3 中第二個明顯的差別是構建 3 之后沒有橙色的“遺漏”條了。在這種情況下，測試團隊利用許多構建來測試構建 1 中引入的所有變更，而在很短的一段時間內，運行了所有確定的測試。即使有這一點延遲，確定缺陷的時間比傳統方法減少了。更重要的是，在測試循環中出現的測試中，不再存在對最終構建質量上的觀察的 11 天的延遲。這極大地降低了一個已被交付的未測試的變更風險。

　　圖 6 中還說明了效率，這顯示出更少量的從一次構建到下一次的未測試的或“帶過來的”變更。通過在引入了缺陷的構建中找到這些缺陷，可以盡可能低成本地進行確定，并且減少了相互依賴的缺陷修復的復雜鏈的風險。對一次構建啟動測試，并在隨后的構建中償還債務的方法，只要在后繼的構建中相同的功能沒有變更時都會有效。

　　最后的重點是相同的缺陷 —— 也就是，圖 5 中的失敗測試 —— 用新的和舊的方法都找到了。

　　圖 6：利用目標測試方法，每個構建的變更和完成的測試

　　原則 4：考慮對所有構建執行的所有測試

　　CTA 的第四個基本原則依賴于這樣的事實，每個對軟件的測試都提供一個質量指數。該測試可能延伸到基本的產品安裝、單元測試、簡單的配置，或正式的 FVT 或 SVT 活動。類似的，如果在不同的環境中運行同樣的或相似的測試(舉例來說，在不同的操作系統上)，那么結果應該包含于質量說明中。

　　此原則的一個擴展是這樣一個事實，對一個沒有變更的功能執行的測試可能仍舊認為是有效的。如圖3 和 圖5 中所示，允許收集累積的結果。同樣的，如果新的區域內的后繼測試提供了一個存在測試問題的指示，那么這也應該包含于質量評估中。因此在提供已知構建的質量投影的時候，工具考慮了所有測試。

　　原則 5：利用節省的時間來提高質量、撰寫新的測試

　　利用 CTA 和目標測試意味著您不再有 100% 執行的目標了。確切地說，目標隨著對產品做出的變更日復一日的改變。問題出來了：人們如何知道什么時候回歸測試完成了?回答很簡單：直到所有變更都停止了，并且覆蓋所有的變更 —— 那些由分析過程所確定的 —— 的測試都運行了，測試才完成。在這一點上，團隊利用回歸套件幾乎完成了每件可能的事情，以確保不會引入額外的缺陷。

　　注意我們說過“團隊幾乎做了每件事情”，因為方法將只瞄準那些已經包含于回歸套件中的測試。如果因為出現了變更，當您沒有對變更進行測試，那么您將會無法查看到您仍舊具有的風險。

　　使用此新方法，您可以確信的是，您已經運行了您現有的測試組合中可能的每個測試，來確保最低可能的風險。圖 7 例舉了這一點，基于每個變更類型中方法的唯一覆蓋率，顯示出測試套件和它們所覆蓋的變更之間的關系。

　　圖 7：測試套件和它們所覆蓋的變更之間的關系

原文轉自：http://www.uml.org.cn/Test/200610251.htm