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

　　圖 1：每次構建的測試完成百分比，使用傳統的回歸測試方法

　　利用傳統的分析方法并研究圖 1 中的圖表，我們只能得出以下有限的結論：

　　沒有一次回歸達到 100% 完成 —— 不可能說出余下的測試對整個質量陳述是否重要。

　　很可能的是對構建 4 到 8 的小百分比的測試，要么為測試的確定重新運行，要么新的測試是覆蓋沒有為構建 4 的額外功能 —— 不論發生哪種情況，都不可能在不進一步分析的情況下確定地知道。

　　此圖表中不清楚的是為什么對構建 9 執行如此多的測試。

　　不可能從圖 1 中的得知的是，回歸套件中的所有測試是否在某一處都運行了。對此，我們求助于圖 2 中顯示的圖表。

　　圖 2：利用傳統回歸測試方法的累積測試完成百分比。

　　圖 2 顯示了對構建 11 收集的一段時間的測試的累積結果。此處，很可能看到的是團隊計劃運行大部分可用的測試，并且發現許多測試失敗，然而，運行這些測試所花費的時間意味著在產品發布的時候這些中的許多仍舊存在。

　　讓我們為該虛擬場景填充一些背后細節。設想構建 3 是最初的 GA 候選，差不多 80% 的可用測試生成了好的結果。其間，缺陷確定和其他變更慢慢地進入到由于工作都集中于構建 3 而很少測試到的后繼構建中。構建 9 宣布為新的 GA 候選，并且測試再次開始。當構建 11 成為最終的 GA 構建時，測試工作再次重新開始。如在圖 2 中可以看到的，此次對構建的測試直到 GA 驅動程序生成之后 11 天才能完成。

　　累積測試分析的情況

　　現在，讓我們將圖 1 和 2 中例舉的傳統方法與新方法在同樣的情況下進行對比。首先，我們對來自于上面測試的結果執行累積測試分析的新技術。為了這樣做，我們向此圖表引入許多附加顏色(參見圖 3)。

　　如以前一樣，通過(綠色)或失敗(紅色)的新測試顯示為暗色。因為圖 3 顯示了測試循環的末尾，所以顯示出很少“新的”測試運行。

　　用橙色突出的測試表示那些瞄準已知構建，但因某種原因沒運行的分析。

　　淺綠和淺紅色的結果表示從較早的構建中轉過來的結果。“新的”和“重新運行”的測試之間的差別僅僅是，“新的”測試是那些對正討論的構建首次運行的測試。

　　還要注意的是圖表不再從 0% 到 100%，而替換為測試的度量數字。這背后的原因將在我們討論新數據時顯現出來。

　　圖 3：利用傳統回歸測試方法的 CTA 累積測試結果

　　利用該技術，我們立即有了更多要考慮的信息：

　　橙色“遺漏”結果表明構建 1 和 2 沒有充分的測試，但它們從對早期的構建的測試(沒有顯示)那里帶來了非常多有效的結果。

　　對構建 3 的測試減少到遺漏測試累積的大約三分之二，所需的余下的測試在整個過程中都沒運行，直到構建 11。

　　附加的測試針對于構建 6(“遺漏”測試的數量增加)，說明對產品有附加的功能變更。

　　對許多構建出現了大量的測試，構建 3、構建 9 和構建 11 特別的昂貴 —— 問題是，這些都是必要的嗎?

　　接下來，因為知道變更是 CTA 的重要部分，所以我們引入一個圖 4 中的新圖表，顯示出每次構建中變更的影響，以及那些變更測試得有多好。數據重新從構建帶到相關的構建中，被變更了的類被反映在零線以上，而覆蓋這些變更的測試在零線以下。充分測試的變更將因此顯示為一個綠色的條，處于與上面所示的變更相同高度的軸之下。

　　圖 4：每此構建的變更以及所完成的測試

　　通過傳統的回歸測試的觀點查看該數據，可以看到，對構建 3 的測試是有效的，但是構建 4 到 8 中對產品類的附加的功能變更(顯示為“新的”或者“非常新的”項)，直到構建 11 才完全測試完成。上面較早描述的其它提示點：

　　構建 1 中出現的大量變更，并且幾乎所有這些都對構建 3 充分測試了。

　　在構建 3 之后，許多未測試的變更從一個構建帶到了下一個中，使“確定缺陷的時間”拉得更長。

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