摘要：
就軟件質量而言，測試覆蓋率是軟件測試中的重要指標。接下來一起了解測試範圍、測試技術，測試標準以及如何改進它。由於軟件中普遍存在的錯誤，全世界都見證了一些災難性事件。2008年在英國希思羅機場5號航站樓開業。工程師對終端的工作充滿信心，這與他們的嚴格測試標準有關。由於行李處理系統在現實情況運行時陷入了癱瘓，導致系統完全關閉。在接下來的10天裏，大約42000個行李箱變成了無主之物，順帶着取消了500多次航班。最終的結果是將事故歸因於工程師未能對可能的實際場景進行測試覆蓋測試。
接下來，我們將討論測試覆蓋率的相關問題，以及它如何幫助提高軟件質量的。
測試覆蓋率概述
測試覆蓋率被定義爲一種測試技術指標，它表明我們的測試用例是否真正完全覆蓋了應用程序代碼中的各種可能以及在運行這些測試用例時執行了多少代碼。
如果有10個需求並創建了100個場景測試用例，並且執行了90個測試用例，則測試覆蓋率爲90％。現在，基於這個指標，測試人員可以爲其餘需求創建其他測試用例。以下是測試覆蓋率的更多優勢。
1.可以在早期和代碼級別發現需求、測試用例和BUG之間的差距。
2.可以使用測試覆蓋率分析來防止BUG的遺漏。
3.測試覆蓋率還有助於進行迴歸測試、測試用例優先級劃分、測試套件擴展和測試套件顆粒化。
測試覆蓋技術
語句覆蓋
語句覆蓋率確保源代碼中的所有場景都經過至少一次測試用例中執行。它提供了全部代碼塊中已執行和未執行的代碼塊的詳細信息。
讓我們通過流程圖示例來了解它。在給定的示例中，此路徑1A-2C-3D-E-4G-5H涵蓋了所有語句，因此僅需要一個測試用例即可滿足所有要求。一個測試用例意味着一個語句覆蓋。
在複雜的代碼中，單個路徑不足以覆蓋所有語句。在這種情況下，測試工程師需要根據實際情況編寫多個測試用例來覆蓋所有場景。
好處：
1.它可以直接應用於目標代碼，並且不需要處理源代碼。
·它可以驗證代碼功能中對於需求是否滿足。
缺點：
·語句覆蓋率僅涵蓋每個語句的條件。
·語句覆蓋率範圍對邏輯運算符（比如||和&&）完全不敏感，很容易漏掉。
·語句覆蓋率是基本覆蓋率，因此不能保證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。
功能測試指標
需求範圍
需求覆蓋率用於確定測試用例滿足軟件需求的程度。爲此，測試工程師只需要將發佈或項目的需求數量除以範圍需求的總數即可。
測試範圍
在需求模塊中，可以通過將測試用例鏈接到需求來統計測試覆蓋率。測試覆蓋率評估測試或需求變更的影響。通過覆蓋多個用例，用需求覆蓋測試配置可以提供更精細的粒度。
用例質量
此度量標準用於查看要測試的功能以及符合要求的測試數量。大多數需求包含多個測試用例。瞭解特定需求正向和逆向的測試場景對於編寫特定需求的測試用例非常重要。
測試範圍
此標準對利益相關者非常重要，因爲它直觀展示了應用程序/軟件開發對於需求的完成度。
應用程序級別指標
缺陷密度
缺陷密度是對已知缺陷總數的度量除以要測量的軟件實體（通常是代碼行數、模塊數、功能數）的數量。
測試範圍
它可以被用於標識需要自動化的模塊。如果特定功能的缺陷密度很高，則需要重新測試。爲了減少重新測試的工作，可以將已知缺陷的測試用例自動化。
在評估缺陷時，考慮缺陷的優先級很重要。通常較高優先級的缺陷會作爲此度量標準的極其重要的一部分而獲得更高的權重。
如何衡量測試覆蓋率
許多質量檢查團隊在衡量測試覆蓋率時不會考慮的一件事：如何衡量測試覆蓋率？如何測量測試覆蓋率？
測試覆蓋率是根據代碼行測得的。這是上面討論的測試執行覆蓋率。例如，如果測試工程師已經通過測試用例執行了800行代碼，那麼在1000行代碼中，改項目的測試覆蓋率爲80％。
如果需要按需求衡量測試的覆蓋率，以專注於測試用例庫中的更高效的測試用例。一個好的測試用例可以追溯到實現的需求（包括正向和反向的流程），擁有良好的測試用例所要做的就是建立需求可追溯性。
當然也可以通過涵蓋某個版本項目迭代範圍內的所有要求，從而實現在項目中的可追溯性。通過建立需求可追溯性，可以在任何時間點了解需求需要的測試範圍。
提高測試覆蓋率
刪除無效代碼
總覆蓋率可以定義爲代碼覆蓋率和測試覆蓋率的比率（covered/total）。可以通過減少作爲總代碼的分母來增加覆蓋範圍。這可以通過刪除Dead代碼來實現。良好覆蓋率測試可以找到死代碼，同樣需要刪除調試代碼和開發人員遺留的測試代碼。
可以通過手動測試或使用自動化工具輕鬆找到無效代碼。在刪除無效代碼之前，測試工程師需要執行功能測試，如果測試完全按照要求執行，則可以刪除未使用的代碼。測試工程師還可以使用靜態測試覆蓋率分析工具從源代碼中識別未使用的無效代碼。
刪除冗餘代碼
刪除複製的代碼可以像刪除無效代碼一樣提高測試覆蓋率。
程序中包含基本代碼和代碼塊，這些代碼塊在程序中具有很搞重複性。如果找到這些複製的代碼並將其刪除。通過從源代碼中刪除複製的代碼，可以將測試覆蓋率提高5-10％。
增加設備覆蓋率
移動設備和操作系統版本投放市場的節奏具有很強的節奏感，而瀏覽器（例如Chrome和Firefox）也具有相同的特性。每個發行版不僅帶來了測試範圍方面的挑戰，而且還引入了需要額外測試工作的新特性和功能。爲了提高最大的測試覆蓋範圍，就必需提高設備的覆蓋率（硬件和軟件）。
衡量移動測試覆蓋率的方法是通過使用情況和客戶分析來了解。列出軟件正式環境中最常用的設備，還需要確保其中包括各個版本的iOS的設備。
測試工程師要關注即將發佈的設備、操作系統版本和瀏覽器版本，將其與現有分析結合使用，保證測試設備庫的及時更新。
結論
如今，開發工作越來越系統化，企業尋求測試完整性和有效性的方法，用來評估測試工作完成程度和工作完成質量。在所有的標準中，測試覆蓋率被認爲是最優價值的指標之一。爲了確保的軟件測試具有較高水平，就需要採用結構化方法，因爲軟件測試覆蓋率是衡量和確保軟件質量的關鍵因素。