成功的自動化回歸測試

也許，像許多團隊一樣，您已經達到飽和點，現在您有太多的測試，以至于不能說明。也許運行測試的團隊已經不再是撰寫它們的團隊了，并且知識是稀少的?；蛘咭苍S您受困于對大量所支持的環境和代碼流不斷地重復運行同樣的測試的工作。對于那些您不能運行的測試，或者您沒有時間運行的，您對您所帶來的風險進行過觀察嗎？

無疑地，如果您只運行少量的測試，并且仍舊在代碼中找到一樣的缺陷，這是更好的。通過運行可能的測試盡可能快地找到第一次出現的缺陷不同樣是更好的嗎？

不能達到的目標

甚至是出于一片好心，每個測試人員在他或她的工作生涯中，都將撰寫一個根本不測試所打算測試內容的測試。這可能是由于缺乏經驗，對產品功能設計的變更，因為測試人員做出關于產品或其預期使用價值的無效假設，或者只是因為測試人員用盡了時間?？偠灾?，最終結果是由于與產品缺陷不相關的原因而失敗的測試。

這些失敗測試的累積效應創造了回歸套件中的灰色區域，您的回歸測試的 5％ 到 15％是困難的、不可靠的或不可能成功地運行完成的。這些阻塞的或不可靠的測試消耗了寶貴的測試時間，并且混淆了測試人員對真實的產品缺陷的觀察，這導致了在回歸測試循環末尾的測試進度中的指數的縮小。虛幻的所有可用測試的100％ 的運行目標常?？雌饋矸浅＝咏?，但是卻難以達到。

自動化陷阱

也許您已經落入了嚴重依賴于您的測試自動化基礎架構的陷阱了。這里有一些您可能考慮的問題。您是：

• 缺少用于測試您所期望的每樣東西的資源嗎？
• 陷入無休止的測試循環嗎？
• 在沒有找到任何新的缺陷的情況下，運行成千上萬的測試嗎？
• 在不了解那些測試的價值的情況下，花費您大部分的時間來確定壞掉的測試嗎？
• 瞄準 100％ 運行您所有的測試的目標嗎？在質量和風險方面您了解此目標嗎？

您可能需要的是，不再瞄準任意數量的測試，而著眼于從上次測試以來在產品中實際變更的功能是什么，以及測試此變更所需要的是什么?？偠灾?，您需要轉移到更深思熟慮的“目標”測試的方法。

停止運行測試，開始尋找缺陷

通常所說的累積測試分析（Cumulative Test Analysis，CTA）方法是基于五個基本原則的：

• 定期地運行自動化的測試。
• 了解現有測試材料的實際覆蓋和質量。
• 運行盡可能少的測試。將測試關注在只運行那些覆蓋了發生變更的功能的測試。
• 在做出評估時考慮所有的測試活動。
• 由四個較早的步驟所節省下來的時間可以用于增加測試套件的質量，或者執行額外的測試。

讓我們按順序討論這些原則。

原則 1：定期地運行自動化的測試

CTA 方法著重于通過在整個的開發循環中運行自動化的測試將“發生缺陷的時間” ¹ 最小化。任何回歸類型的缺陷都可以很早發現，并且與在循環的末尾運行單個的長期回歸運行相比使用了最小量的測試。

此測試的目標是提供對所有驅動程序的功能質量的一個觀察，作為進一步測試和最終向市場發布的基礎。此回歸測試減少了進入最終產品的缺陷數量，以及在這期間，減少可能防止新特性的更復雜的測試的基礎功能問題。由此可見，這些回歸類型的缺陷需要在其最方便確定的時候盡可能快速地清理掉。

原則 2：了解回歸測試套件中現有測試材料的質量和覆蓋

如早先討論的，包含于回歸套件中的許多測試在任何規模的測試操作中可能不能生成可靠的結果。為了完全了解產品的質量，事實上，根據潛在的產品缺陷，您在觀察的結果意味著什么，您必須首先了解測試實際上測試的功能是什么。

為此，我們求助于代碼覆蓋的使用。對于外行來說，這實際上是所有方法、類和測試從開始到結束所經過的代碼途徑的細微痕跡。這種在一個測試接一個測試的基礎上的運行時度量提供了對測試做什么的觀察，并且比起在實際的測試運行過程中的運行時收集信息時依賴于測試計劃或測試文檔來說，是一種了解要測什么內容的更精練的方法。當然，對于此途徑存在著由，例如，尋找缺陷并執行異常路徑的測試引起的偏差?？偟膩碚f，盡管，如果代碼覆蓋數據是在成功的測試運行過程中收集的，那么此信息可以存儲起來隨后作為測試的功能的指示。

有許多可用的工具可以提供代碼覆蓋率。它們都典型地使用被測代碼的某種形式的裝置，這將鉤子（hooks ）加入了產品代碼中。當測試材料遇到這些鉤子時，代碼覆蓋工具使用這些鉤子來記錄每個測試在其執行時所經歷的過程。最終結果是一個表示與特定的產品驅動程序沖撞的所有測試的完全覆蓋的數據庫。因為回歸測試材料隨著時間的推移變化得不大，那么此數據仍舊相對靜態。然而，如果產品或測試材料隨著時間的推移變化很大，那么就需要重復實施裝置。

原則 3：盡可能少地運行：關注于您的測試

該標題可以等同于這樣措辭，“不要浪費時間運行您與先前的驅動程序沖撞的測試，除非它們測試的功能已經變更了?！睖p少測試運行的數量可能對那些使用回歸套件作為獲取回歸安全網的許多團隊來說需要信仰上的飛躍，但是這種飛躍將節省數不盡的不必要的回歸測試時間。

實際上，實現確定目標的測試需要兩件事：1）了解在測的產品驅動程序中確切變更了什么，以及 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）。

• 如以前一樣，通過（綠色）或失?。t色）的新測試顯示為暗色。因為圖 3 顯示了測試循環的末尾，所以顯示出很少“新的”測試運行。
• 用橙色突出的測試表示那些瞄準已知構建，但因某種原因沒運行的分析。
• 淺綠和淺紅色的結果表示從較早的構建中轉過來的結果?！靶碌摹焙汀爸匦逻\行”的測試之間的差別僅僅是，“新的”測試是那些對正討論的構建首次運行的測試。

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

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

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

• 橙色“遺漏”結果表明構建 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 中的數據是基于已經部署了累積測試分析和目標測試的測試團隊，在需要覆蓋每次構建中的變更時只運行那些確定出來的測試。

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

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

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

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

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

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

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

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

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

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

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

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

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

在圖 7 中的實例中，組 S3、S4 和 S5 不唯一地覆蓋 S1 和 S2 所覆蓋的任何方法，然而，通過運行它們，團隊可以確定它們可以運行觸及部分變更的每一個測試。

最顯著的是，橙色區域 —— 沒有被綠色覆蓋的部分 —— 在圖中表示根本沒有被回歸套件中的測試覆蓋到的變更。因此團隊需要將他們工作的重點集中于撰寫提供此覆蓋的測試，為了完全測試變更并且將錯過潛在缺陷的風險減少到其最低可能的值。幸運的是，CTA 方法給團隊時間來開發這些所需的測試。

心理轉變

這不是新技術或一種根本的新樣式。背后的思想在最初設想代碼覆蓋時就出現了。技術提供的東西，盡管，從測試團隊的觀點來看是一組直覺上正確的思想，但這仍舊表示對許多內容強調的基本變化。只運行測試的子集去掉了“做一些有價值的事情”的興奮感覺，這是運行整個回歸套件的傳統實踐提供的感覺。該新方法還需要來自于項目管理團隊對不再朝著基于風險的 100％的運行目標，而只對每次構建運行恰當的測試的了解和支持。這沒有去掉將團隊著重于調試測試失敗或撰寫新測試的需求，但這樣做可以為做重要的工作贏得額外的時間！

注釋

¹ 發現缺陷的時間（Time to defect）：將缺陷引入到產品代碼中和將缺陷報告分配給進行確定的開發人員期間經過的時間。

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