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

　　上面中的第一個在產品代碼處于某種庫控制形式時相對容易獲得。庫系統，例如 CMVC、CVS 或 Rational ClearCase 提供創建邏輯變更或截然不同的層次集合的機制。對于這些層次，個別的工具能夠提供某種粒度上的一系列變更，不論是文件、包、類或某些更細粒度的類別。有了這兩項信息，確定將在最少的時間內，達到變更功能的最大代碼或路徑覆蓋的現有測試記錄的子集是可能的。

　　如果沒什么發生變更 —— 或者，更可能的是，您沒有對發生變更的功能進行測試 —— 您只是不運行任何東西!這樣做是對您可以花費在其他地方的寶貴時間的浪費。

　　此處給出一個警告：如果回歸測試套件是范圍非常廣泛的，那么這將有極好的效果。但如果覆蓋很低，那么有時候，目標測試可能使您得出結論，您沒有合適的測試值得運行。記住，在這一點上，用回歸測試的標準方法，團隊會盲目地運行整個回歸套件。這幾乎不會增加價值，但確實會花費很多時間。通過使用 CTA 方法，您可以利用節省的時間來撰寫新測試增加您的覆蓋率(參見在下面的原則 5 中的討論)。

　　累積觀點：沿用先前的測試結果

　　除了確定測試目標，CTA 還利用另一個關鍵的概念減少了所需的測試運行的數量：累積的結果分析。一旦確定了測試的目標是只覆蓋變更的功能，那么來自于未變更代碼區域的結果就可能從一次構建轉移到下一次。

　　此方法的重要好處是允許使用最少的測試數據進行質量評估。這對于發布循環的末期是特別有用的，此時要做出少量的變更，并且大范圍的運行測試會過高地耗費時間。最終的決策可以根據實際上許多星期或月之前的測試數據做出，而產品仍舊保持一段時間的功能穩定。

　　通過將目標測試和累積結果分析兩條原則組合起來，在測試循環早期運行的測試可能不再需要再次運行了，它們的結果將保留到最后。類似地，任何覆蓋不穩定的代碼區域的測試可能需要每天都重新運行。通過采用此方法，可以將測試著重于產品的那些攜帶最高風險缺陷的區域。

　　實例：傳統測試與目標測試

　　下面的一系列圖表顯示了一個來自于典型的回歸測試執行的可能輸出的人為實例。我們首先使用傳統方法，然后對這個系列的構建使用目標方法，以及累積結果分析。

　　考慮下面圖 1 中顯示的場景，這可能是導致輸出一般利用率(GA)的開發循環的一部分。測試團隊已經利用了由構建 3 和構建 11 獲得的最重要的結果數字對連續的構建嘗試許多回歸執行。

　　圖 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 中的新圖表，顯示出每次構建中變更的影響，以及那些變更測試得有多好。數據重新從構建帶到相關的構建中，被變更了的類被反映在零線以上，而覆蓋這些變更的測試在零線以下。充分測試的變更將因此顯示為一個綠色的條，處于與上面所示的變更相同高度的軸之下。

原文轉自：http://www.anti-gravitydesign.com