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

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

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

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

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

　　實際上，實現確定目標的測試需要兩件事：1)了解在測的產品驅動程序中確切變更了什么，以及 2)了解您的測試材料(如前面部分中討論的)。

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

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

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

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

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

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

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

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

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

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

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

• 共5頁:
• 上一頁
• 1
• 2
• 3
• 4
• 5
• 下一頁