摘要：就軟件質量而言，測試覆蓋率是軟件測試中的重要指標。接下來一起了解測試范圍、測試技術，測試標准以及如何改進它。
由於軟件中普遍存在的錯誤，全世界都見證了一些災難性事件。2008年在英國希思羅機場5號航站樓開業。 工程師對終端的工作充滿信心，這與他們的嚴格測試標准有關。由於行李處理系統在現實情況運行時陷入了癱瘓，導致系統完全關閉。在接下來的10天里，大約42000個行李箱變成了無主之物，順帶着取消了500多次航班。 最終的結果是將事故歸因於工程師未能對可能的實際場景進行測試覆蓋測試。
接下來，我們將討論測試覆蓋率的相關問題，以及它如何幫助提高軟件質量的。
測試覆蓋率概述
測試覆蓋率被定義為一種測試技術指標，它表明我們的測試用例是否真正完全覆蓋了應用程序代碼中的各種可能以及在運行這些測試用例時執行了多少代碼。
如果有10個需求並創建了100個場景測試用例，並且執行了90個測試用例，則測試覆蓋率為90％。現在，基於這個指標，測試人員可以為其余需求創建其他測試用例。以下是測試覆蓋率的更多優勢。
- 可以在早期和代碼級別發現需求、測試用例和BUG之間的差距。
- 可以使用測試覆蓋率分析來防止BUG的遺漏。
- 測試覆蓋率還有助於進行回歸測試、測試用例優先級划分、測試套件擴展和測試套件顆粒化。
測試覆蓋技術
語句覆蓋
語句覆蓋率確保源代碼中的所有場景都經過至少一次測試用例中執行。它提供了全部代碼塊中已執行和未執行的代碼塊的詳細信息。
讓我們通過流程圖示例來了解它。在給定的示例中，此路徑1A-2C-3D-E-4G-5H涵蓋了所有語句，因此僅需要一個測試用例即可滿足所有要求。一個測試用例意味着一個語句覆蓋。
在復雜的代碼中，單個路徑不足以覆蓋所有語句。在這種情況下，測試工程師需要根據實際情況編寫多個測試用例來覆蓋所有場景。
好處：
- 它可以直接應用於目標代碼，並且不需要處理源代碼。
- 它可以驗證代碼功能中對於需求是否滿足。
缺點：
- 語句覆蓋率僅涵蓋每個語句的條件。
- 語句覆蓋率范圍對邏輯運算符（比如||和&&）完全不敏感，很容易漏掉。
- 語句覆蓋率是基本覆蓋率，因此不能保證100％語句覆蓋率。
分支覆蓋
幾乎沒有一個業務場景是可以不需要進行判斷的，在任何時候他們都需要分支出代碼來滿足功能要求。代碼中的分支實際上是從一個決策點到另一決策點的跳轉。分支覆蓋范圍檢查代碼中每個可能的路徑或分支是否被覆蓋。
分支覆蓋率可以通過找到確保覆蓋所有邊緣的最小路徑數來計算。在給定的示例中，沒有一條路徑可以確保一次覆蓋所有邊緣。
例如，如果您沿此路徑1A-2C-3D-E-4G-5H覆蓋最大邊緣數A，C，D，E，G和H，則仍然會錯過兩個邊緣B和F 。測試人員需要遵循另一條路徑1A-2B-E-4F覆蓋其余兩個邊緣分支。通過組合以上兩條路徑，可以確保在所有分支均被測試用例覆蓋到。
好處：
- 分支覆蓋涵蓋了所有條件判斷。
- 分支覆蓋驗證是否所有分支都已測試。
缺點：
- 分支覆蓋忽略布爾表達式中由於短路算子而出現的分支。
路徑覆蓋
路徑測試是一種結構測試方法，涉及使用程序的源代碼來查找每個可能的可執行路徑。路徑覆蓋范圍可確保從頭到尾覆蓋所有路徑。在此示例中，有四種可能的路徑：
- 1A-2B-E-4F
- 1A-2B-E-4G-5H
- 1A-2C-3D-E-4G-5H
- 1A-2C-3D-E-4F
好處：
- 它有助於減少冗余測試。
- 路徑覆蓋率提供了較高的測試覆蓋率，因為它覆蓋了代碼中的所有語句和分支。
缺點：
- 測試每條路徑既困難又費時，因為許多路徑與分支的數量成指數關系。
- 在實際業務中，由於數據的關系，許多路徑很可能是不通的。
條件覆蓋
條件覆蓋率檢查每個條件的兩個結果（true或false）是否均已執行。邏輯判斷點的結果僅與檢查條件有關。每個條件需要兩個測試用例才能實現兩個結果。
好處：
- 條件覆蓋范圍相互獨立地測量條件。
- 條件覆蓋對控制流具有更好的敏感性。
缺點：
- 類似於分支機構/決策范圍，決策點和測試用例指數關系。
- 對於多條件測試經常，很難避免用例重復
邊界值覆蓋
對於那些由於輸入數字而發生錯誤的應用程序，邊界值覆蓋率指標非常有用。大多數BUG都是發生在邊界值處。在邊界值覆蓋范圍內，在等效類的端點處選擇測試用例。對於此測試覆蓋率示例，以下是需要3位數字作為輸入的應用程序的邊界值。
- 100（最低）
- 99（僅低於最小邊界值）
- 999（最大）
- 1000（僅在最大邊界值之上）
好處：
- 測試小組使用邊界值覆蓋數據代替測試大量數據集是很容易的。
- 邊界值覆蓋易於使用，因為它易於自動化已識別測試的性質和一致性。
缺點：
- 邊界值覆蓋無法測試兩個輸入之間的依賴關系。
- 邊界值覆蓋不能覆蓋包含布爾函數的代碼。
什么是測試覆蓋率指標
下面是是5個關鍵的測試覆蓋率指標。
代碼級指標
測試執行覆蓋率，它也稱為已執行測試，是已通過/已執行測試在總測試數量中所占的百分比。
- 優點是可以通過統計通過和失敗的測試次數來獲得測試進度的直觀描述。
- 缺點是計數通過的測試用例並不能說明這些測試的質量。例如，某些測試可能會通過，但是在某些非正常時候，程序會觸發一些
BUG。
功能測試指標
需求范圍
需求覆蓋率用於確定測試用例滿足軟件需求的程度。為此，測試工程師只需要將發布或項目的需求數量除以范圍需求的總數即可。
測試范圍
在需求模塊中，可以通過將測試用例鏈接到需求來統計測試覆蓋率。測試覆蓋率評估測試或需求變更的影響。通過覆蓋多個用例，用需求覆蓋測試配置可以提供更精細的粒度。
用例質量
此度量標准用於查看要測試的功能以及符合要求的測試數量。大多數需求包含多個測試用例。了解特定需求正向和逆向的測試場景對於編寫特定需求的測試用例非常重要。
測試范圍
此標准對利益相關者非常重要，因為它直觀展示了應用程序/軟件開發對於需求的完成度。
應用程序級別指標
缺陷密度
缺陷密度是對已知缺陷總數的度量除以要測量的軟件實體（通常是代碼行數、模塊數、功能數）的數量。
測試范圍
它可以被用於標識需要自動化的模塊。如果特定功能的缺陷密度很高，則需要重新測試。為了減少重新測試的工作，可以將已知缺陷的測試用例自動化。
在評估缺陷時，考慮缺陷的優先級很重要。通常較高優先級的缺陷會作為此度量標准的極其重要的一部分而獲得更高的權重。
測試覆蓋率矩陣
下面是一個登錄功能的矩陣表，用於確保考慮了所有可能要測試的條件/特征。可以將其視為檢查清單，以確保以所有可能的組合驗證被測對象的某項功能。
| 特征 | 模組 | 案件類型 | 測試用例 |
|---|---|---|---|
| 用戶 | 登錄 | 默認情況 | 有效的用戶名 ，有效的密碼 |
| 負 | 用戶名無效，密碼有效 | ||
| 負 | 用戶名有效，密碼無效 | ||
| 負 | 用戶名為空，密碼為空 | ||
| 邊界 | 用戶名和密碼超過10個字符的最大長度 |
如何衡量測試覆蓋率
許多質量檢查團隊在衡量測試覆蓋率時不會考慮的一件事：如何衡量測試覆蓋率？如何測量測試覆蓋率？
測試覆蓋率是根據代碼行測得的。這是上面討論的測試執行覆蓋率。例如，如果測試工程師已經通過測試用例執行了800行代碼，那么在1000行代碼中，改項目的測試覆蓋率為80％。
如果需要按需求衡量測試的覆蓋率，以專注於測試用例庫中的更高效的測試用例。一個好的測試用例可以追溯到實現的需求（包括正向和反向的流程），擁有良好的測試用例所要做的就是建立需求可追溯性。
當然也可以通過涵蓋某個版本項目迭代范圍內的所有要求，從而實現在項目中的可追溯性。通過建立需求可追溯性，可以在任何時間點了解需求需要的測試范圍。
提高測試覆蓋率
刪除無效代碼
總覆蓋率可以定義為代碼覆蓋率和測試覆蓋率的比率（covered/total）。可以通過減少作為總代碼的分母來增加覆蓋范圍。這可以通過刪除Dead代碼來實現。良好覆蓋率測試可以找到死代碼，同樣需要刪除調試代碼和開發人員遺留的測試代碼。
可以通過手動測試或使用自動化工具輕松找到無效代碼。在刪除無效代碼之前，測試工程師需要執行功能測試，如果測試完全按照要求執行，則可以刪除未使用的代碼。測試工程師還可以使用靜態測試覆蓋率分析工具從源代碼中識別未使用的無效代碼。
刪除冗余代碼
刪除復制的代碼可以像刪除無效代碼一樣提高測試覆蓋率。
程序中包含基本代碼和代碼塊，這些代碼塊在程序中具有很搞重復性。如果找到這些復制的代碼並將其刪除。通過從源代碼中刪除復制的代碼，可以將測試覆蓋率提高5-10％。
增加設備覆蓋率
移動設備和操作系統版本投放市場的節奏具有很強的節奏感，而瀏覽器（例如Chrome和Firefox）也具有相同的特性。每個發行版不僅帶來了測試范圍方面的挑戰，而且還引入了需要額外測試工作的新特性和功能。為了提高最大的測試覆蓋范圍，就必需提高設備的覆蓋率（硬件和軟件）。
衡量移動測試覆蓋率的方法是通過使用情況和客戶分析來了解。列出軟件正式環境中最常用的設備，還需要確保其中包括各個版本的iOS和Android的設備。
測試工程師要關注即將發布的設備、操作系統版本和瀏覽器版本，將其與現有分析結合使用，保證測試設備庫的及時更新。
結論
如今，開發工作越來越系統化，企業尋求測試完整性和有效性的方法，用來評估測試工作完成程度和工作完成質量。在所有的標准中，測試覆蓋率被認為是最優價值的指標之一。 為了確保的軟件測試具有較高水平，就需要采用結構化方法，因為軟件測試覆蓋率是衡量和確保軟件質量的關鍵因素。
公眾號FunTester首發，原創分享愛好者，騰訊雲和掘金社區首頁推薦，知乎七級原創作者，歡迎關注、交流，禁止第三方擅自轉載。