通過了解需要進行新測試的地方，智能地使用代碼覆蓋率指標將測試工作集中在最需要的地方，并創建可維護的測試套件。

敏捷的主要宗旨之一是確保增量交付物的可交付質量，同時響應不斷變化的需求。但是，在平衡新功能測試同時驗證現有功能的正確操作方面所面臨的挑戰使許多敏捷開發團隊陷入了擴展，擴展測試套件的創建，管理和維護困境。最后，如果沒有適當的信息財富，那么加速敏捷和對產品質量和安全性都充滿信心將變得非常困難。

為了了解所執行的風險緩解水平，查看測試期間執行的代碼量是一個有用的指標，但是它經常被濫用，并且從宏觀角度來看，它并不是質量的良好指標。在本文中，我將向您展示如何智能地使用代碼覆蓋率指標，通過了解需要進行新測試的地方，將測試工作集中在最需要的地方。我們還將介紹一些創建可維護測試套件的最佳實踐。

如何考慮有用的代碼覆蓋率

代碼覆蓋率不是確定您何時有足夠測試的“數字”，而是對于指導團隊關注的重點非常有用的“數字”。

不幸的是，它經常被錯誤地用來管理團隊，因為他們只關注人數本身并針對代碼庫按特定百分比射擊，例如，使用諸如“我們必須擁有80％的覆蓋率才能發布”或“覆蓋率”之類的策略應該與先前的版本相同或更高。”

這種方法的問題在于，獲取和維護目標保險單號本身很困難且耗時，因此我們盲目地努力爭取該保險單號，沒有人會花時間問一些重要問題，例如：

• 我們涵蓋了哪80％？

• 測試工作會驗證質量并降低交付應用程序的風險嗎？

• 隨著代碼的發展，我將如何維護測試？

正如我在上一個博客中所討論的那樣，代碼庫中的每個更改都代表引入風險，了解每個變更對現有代碼的特定影響，以及了解如何減輕這種風險都很重要。

通過識別代碼庫中的更改，并使用代碼覆蓋率將測試與這些更改相關聯，可以根據需要進行重新測試的位置來創建最佳測試計劃（在此處了解有關基于更改的測試的更多信息。)

但這并不能涵蓋所有風險。顯然，我們仍然需要為新功能創建測試，但是現有/舊版代碼又如何呢？我們討論過的許多組織的目標是60-80％的代碼覆蓋率，但實際上要達到50％以上是很困難的。因此，很有可能現有的測試用例不會覆蓋對現有代碼的更改。宏覆蓋目標僅關注于保留或逐步增長，就無法避免將回歸引入“已經使用多年”的傳統功能。

相反，通過仔細查看覆蓋率詳細信息，可以快速識別出未覆蓋的特定已修改行，因此您可以將團隊集中在需要創建新測試的位置。此外，利用測試用例與它們執行的特定代碼之間的可追溯性，您可以識別出可以重復或擴展以覆蓋更改的潛在測試用例。

通過專注于實現已修改代碼的100％覆蓋率，而不是團隊任意設定的“總覆蓋率80％”的目標，團隊可以在降低新代碼風險的同時更加高效，同時消除影響整體項目穩定性的因素（例如，對舊代碼。）

修改后的代碼覆蓋范圍

使用Parasoft DTP的Modified Code Coverage小部件（Parasoft DTP的過程智能引擎（PIE）的分析“切片”）可以測量此智能代碼的覆蓋率。在這里，您可以輕松查看在兩個內部版本之間添加或更改的代碼的覆蓋范圍（例如，當前內部版本和您選擇的目標內部版本）。例如，圖1顯示了這樣的小部件。在此示例中，在兩個版本之間添加或更改了177行代碼，并且其中的109行已經過測試，即61.6％。這意味著有68行新代碼或更改的代碼未經過任何測試，因此尚未通過驗證，并且在代碼庫中代表風險。

此小部件后面的是修改后的覆蓋率報告。該報告提供了有關缺少適當測試的代碼的確切詳細信息。這是開發人員和測試人員集中精力所需要的關鍵信息。圖2顯示了這樣的報告，其中可以根據更改數量或缺少代碼的代碼對修改后的文件進行排序，未發現的修改行用紅色標記。

該報告回答了“我缺少哪些測試？”這一問題。根據每個構建的此處信息，可以創建測試計劃。

要創建哪種類型的測試？

一旦確定了缺少測試的代碼，實際上就需要開始工作并創建測試以填補空白——但是，您將創建哪種類型的測試？測試金字塔（由Martin Fowler和Mike Cohn宣傳）概述了如何創建有效，可管理和可維護的測試組合。通過最大程度地減少脆弱的UI級別測試，并專注于堅實的單元測試基礎（以全面的Service/API級別測試作為后盾），您可以構建可擴展、可維護并且可以連續執行的測試策略。

我們不會在此博客中介紹創建單元或API測試的詳細信息，但是您可以查看我以前的有關單元測試的博客，并關注有關Parasoft SOAtest的博客：用于簡化API/服務級別測試的創建。

結論

代碼覆蓋率是一項重要指標，但是它經常被濫用和濫用，尤其是在用于衡量質量時。為了從代碼覆蓋范圍中獲取更多價值，請利用Parasoft DTP的分析智能來檢測需要進行新測試的地方，降低風險，集中測試并優化實現質量目標。