測試覆蓋率和代碼覆蓋率是衡量代碼有效性的最流行方法。這些術語有時會同時出現，因為它們的基本原理相同。但是它們並不是那么一致。很多時候，測試團隊和開發團隊對這兩個術語的使用感到困惑。下面詳細討論代碼覆蓋率和測試覆蓋率之間的區別的原因。
概念
代碼覆蓋率：表示通過用Selenium或任何其他測試自動化框架進行的手動測試和自動化測試，測試用例覆蓋的代碼百分比。例如，如果源代碼具有一個簡單的if...else循環，則如果測試代碼可以覆蓋這兩種情況（即if＆else），則代碼覆蓋率將為100％。
測試范圍：包括測試作為功能需求規范，軟件需求規范和其他必需文檔的一部分而實現的功能。例如，如果要對Web應用程序執行跨瀏覽器測試，以確保應用程序可以在其他瀏覽器流暢運行。測試覆蓋范圍是已驗證Web應用程序的瀏覽器兼容性的瀏覽器+操作系統組合的數量。
代碼覆蓋率
開發人員在單元測試期間執行代碼覆蓋，以驗證代碼實現，盡可能多執行代碼語句。大多數代碼覆蓋率工具都使用靜態工具，將監視執行的語句插入代碼中的必要位置。盡管添加檢測代碼會導致總體應用程序大小和執行時間增加，但與通過執行檢測代碼生成的信息相比，開銷卻很小。輸出包含一個詳細描述測試套件測試范圍的報告。
為什么要執行代碼覆蓋率
單元測試主要用於在單個單元級別上測試代碼。由於單元測試是由開發人員自己編寫的，因此他對應該作為單元測試的一部分包含的測試具有更好的可見性。單元測試有助於提高軟件的整體質量，但是關於構成單元測試的測試數量始終存在疑問。測試套件中是否有足夠數量的測試方案？我們應該添加更多測試嗎？代碼覆蓋率是所有這些問題的重要衡量標准。
隨着產品開發的進行，新功能以及BUG修復補丁將添加到發布周期中。這意味着測試代碼可能還需要進行更改，以使其與開發過程中所做的軟件更改保持一致。在項目開始時設定的測試標准必須與后續的發布周期保持一致，這一點很重要。代碼覆蓋率可用於確保測試過程符合這些標准，並且質量最好的代碼進入生產階段。
代碼覆蓋率越高，發生未檢測到的錯誤的概率越低。在某些組織中，質量團隊設置在將軟件推向生產階段之前需要實現的最小代碼覆蓋量。這樣做的主要原因是為了減少在產品開發的后期階段檢測到錯誤的可能性。
如何執行代碼覆蓋率
代碼覆蓋范圍有不同的級別，代碼覆蓋率的一些常見子類型為：
- 分支機構的覆蓋范圍：分支機構的覆蓋范圍也稱為決策覆蓋范圍，用於確保決策過程中使用的每個可能的分支都得到執行。例如，如果您要使用代碼中的If ... An條件語句或DWhile語句合並后備跨瀏覽器兼容性，作為覆蓋范圍的一部分；通過提供適當的輸入以使跨瀏覽器兼容的網站來確保對所有分支（即If，Else，While）進行測試。
- 功能覆蓋范圍：功能覆蓋范圍可確保測試必要的功能（尤其是導出的功能/ API）。這還應包括使用不同類型的輸入參數測試功能，因為這也將測試功能中使用的邏輯。一旦測試了代碼中的所有功能，功能覆蓋率將為100％。
- 語句覆蓋率：這是一種重要的代碼覆蓋率方法，其中必須以某種方式編寫測試代碼，即源代碼中的每個可執行語句至少執行一次。這也包括極端情況或邊界情況。
- 循環覆蓋：這種方法是確保源中的每個循環至少執行一次。可能會根據在運行時獲得的結果執行某些循環，同樣重要的是測試此類循環以使代碼萬無一失。
為了檢查代碼覆蓋率，使用了一種稱為檢測的方法。工具可用於監視性能，插入跟蹤信息以及診斷源代碼中的任何類型的錯誤。
儀器分為三種主要類型
- 代碼檢測：這里的源代碼是在添加檢測語句之后編譯的。編譯應使用常規工具鏈完成，編譯成功將導致生成檢測裝配。例如，為了檢查在代碼中執行特定功能所花費的時間，可以在功能的“開始”和“結束”中添加檢測語句。
- 運行時檢測：與代碼檢測方法相反，此處的信息是從運行時環境（即在執行代碼時）收集的。
- 中間代碼檢測：在這種檢測類型中，通過向已編譯的類文件中添加字節碼來生成檢測類。
根據測試要求，團隊應該選擇正確的代碼覆蓋率工具以及該工具支持的最佳檢測方法。
代碼覆蓋率工具
有許多支持不同編程語言的代碼覆蓋工具，其中許多還可以兼用作QA工具。許多工具可以與構建工具和項目管理工具集成在一起，從而使它們更加強大的作用。選擇開源代碼覆蓋率工具時，應檢查該工具支持的功能以及該工具是否正在積極開發迭代中。下面是一些流行的開源代碼覆蓋工具：
- Coverage.py：這是Python的代碼覆蓋工具。顧名思義，它可以分析您的源代碼並確定已執行代碼的百分比。它是用Python開發的。
- Serenity BDD：支持Java和Groovy編程語言，Serenity BDD是一個流行的開源庫，主要用於更快地編寫出色的質量驗收測試。它可以與JUnit，Cucumber和JBehave一起使用。Serenity BDD可以輕松地與Maven，Cradle，JIRA和Ant集成。
- JaCoCo：JaCoco是Java的代碼覆蓋工具。盡管還有其他選項，例如Cobertura和EMMA，但由於長時間沒有更新，因此不推薦使用這些工具。除了積極開發JaCoCo之外，使用JaCoCo的另一個優勢是可以與CI/CD和項目管理工具（例如Maven，Jenkins，Gradle等）無縫集成。
- JCov：JCov是一個測試框架不可知代碼覆蓋工具。它可以輕松地與Oracle的測試基礎架構JavaTest和JTReg集成。盡管尚未積極開發，但對即時檢測和脫機檢測的支持是使用JCov的主要優勢。
- PITest：這是一個突變測試框架。它有快、可擴展，並與當前測試和構建工具集成好的優點。傳統的測試覆蓋率（即行，語句，分支等）僅衡量測試執行的代碼。 它不會檢查測試是否真正能夠檢測到所執行代碼中的錯誤。 因此，它只能識別絕對未經測試的代碼。PITest是一種非常流行的代碼覆蓋工具，用於Java和JVM的變異測試。它通過修改測試代碼來完成突變測試的工作，並且現在已經在修改后的代碼上執行了單元測試。PITest易於使用，快速且正在積極開發中。它還與流行的CI/CD工具集成在一起使用。
測試覆蓋率
與代碼覆蓋率是白盒測試方法不同，測試覆蓋率是黑盒測試方法。以最大范圍覆蓋FRS（功能需求規范），SRS（軟件需求規范），URS（用戶需求規范）等中提到的需求的方式編寫測試用例。
如何執行測試覆蓋率
像代碼覆蓋率一樣，也可以通過不同類型的測試來評估測試覆蓋率。但是，應遵循哪種測試完全取決於具體的業務。例如在以用戶為中心的Web應用程序中，可能存在UI/UX測試比功能測試具有更高優先級的情況，而在其他類型的應用程序中（例如銀行，金融）；可用性測試，安全性測試等可能更為重要。
以下是一些測試覆蓋率機制：
- 單元測試：這種測試在單元級別/模塊級別執行。在單元級別遇到的錯誤可能與集成階段遇到的問題不同。
- 功能測試：在功能測試中，將根據功能需求規范（FRS）中提到的要求對功能/功能進行測試。
- 集成測試：由於軟件是在系統級別進行測試的，因此也稱為系統測試。一旦集成了所有必需的模塊，便會執行此類測試。
- 驗收測試：全部取決於驗收測試的結果，是否將產品發布給最終客戶。
要注意的另一個重要點是，測試覆蓋范圍的目的和含義可能會有所不同，具體取決於執行測試的級別。它還取決於執行黑盒測試的產品類型。用於測試手機的測試覆蓋率指標將不同於用於網站測試的指標。一些分類如下：
- 功能覆蓋范圍：在此情況下，以最大程度覆蓋產品功能覆蓋范圍的方式開發測試用例。
- 風險覆蓋范圍：每個產品/項目需求文檔都有一節提到與項目相關的風險與緩解措施。盡管某些風險（例如，業務動態變化）不在計划/開發/測試團隊的范圍內，但是在測試階段仍需要解決一些風險。
- 需求范圍：這里定義測試的方式是最大程度地覆蓋各種需求規范文檔中提到的產品需求。
測試覆蓋率工具
在代碼覆蓋率的情況下，度量標准是通過測試用例/測試套件測試的代碼的百分比。因此，可以量化測試結果，即在100 LOC（代碼行）中，代碼覆蓋率為80行。這意味着代碼覆蓋率為80％。由於執行測試是為了驗證功能要求，因此無法量化測試覆蓋率的結果。還可以提出可以在單個測試中測試多個需求的黑匣子測試。
盡管在少數情況下必須編寫測試代碼來達到測試覆蓋率要求，但是在某些情況下，您可能仍需要使用一些流行的測試框架。兩種最受歡迎的測試框架是：
- JUnit：JUnit是Java的單元測試框架。它也可以用於UI測試。它是開源的，並且在TDD（測試驅動開發）的開發中被認為很重要。開發人員和測試人員使用JUnit編寫和執行重復的測試。這也使它成為回歸測試的流行框架。
- PyUnit：PyUnit（也稱為Python單元測試框架）是一種廣泛用於單元測試的廣泛使用的測試框架。它是JUnit的Python端口，由遵循TDD方法的Python開發人員使用。PyUnit支持測試用例，測試套件，測試裝置等的開發。unittest模塊是PyUnit框架的核心。
- Pytest：Pytest是一個使創建簡單及可擴展性測試用例變得非常方便的框架。測試用例清晰、易讀而無需大量的繁瑣代碼。只要幾分鍾你就可以對你的應用程序或者庫展開一個小型的單元測試或者復雜的功能測試。
代碼覆蓋率與測試覆蓋率：哪一個？
衡量代碼覆蓋率和測試覆蓋率的影響的基礎完全不同。代碼覆蓋率是通過測試期間覆蓋的代碼百分比來衡量的，而測試覆蓋率是通過測試覆蓋的功能來衡量的。
重要的是“其中哪一項最適合項目”？這個問題沒有確切的答案，因為解決方案取決於項目的類型和復雜性。在大多數情況下，使用測試覆蓋率和代碼覆蓋率，因為它們在軟件項目中同等重要。
測試覆蓋范圍的優勢
- 一種測試軟件功能並比較不同規范文檔（需求，功能，產品，UI/UX等）結果的好方法。
- 由於作為覆蓋范圍一部分執行的測試實際上是黑盒，因此執行這些測試可能不需要太多的專業知識。
測試覆蓋范圍的缺點
- 由於測試主要是黑盒測試，因此沒有自動化范圍。測試結果必須與預期的輸出進行手動比較，因為這些測試是在功能級別而非代碼級別執行的。
- 沒有測量測試覆蓋率的具體方法。因此，覆蓋范圍的結果在很大程度上取決於正在執行測試的測試人員的領域能力，並且可能因一個測試人員而異。
代碼覆蓋范圍的優勢
- 提供測試代碼的有效性以及如何提高覆蓋率。
- 無論使用哪種工具（開源，高級），設置代碼覆蓋率工具都不會花費太多時間。
- 通過捕獲代碼中的錯誤來幫助提高代碼質量。
代碼覆蓋范圍的缺點
- 大多數代碼覆蓋率工具僅限於單元測試。因此，工具使用的方法可能會有所不同；可能無法將一種工具的代碼覆蓋率結果與另一種工具進行比較。
- 搜索最適合的工具可能是一項艱巨的任務，因為需要先從這些工具中比較並嘗試功能，然后再選擇最適合項目需求的工具。
- 提供很少支持不同編程語言（例如Java，Python，C#等）的工具。因此，如果團隊使用多種編程語言（用於測試代碼開發），則需要多個工具。
測試團隊應花費大量時間來了解總體要求並確定測試活動的優先級。為了跟蹤進度，他們應該有一個清單，該清單應定期更新（至少在每次發行之后）。測試團隊還必須與質量保證（QA）團隊保持頻繁的溝通，這是很重要的，因為他們具有要發布給客戶/客戶的產品/項目必須達到的目標（測試/代碼）覆蓋范圍的詳細信息。沒有專門的經驗法則提到測試產品時需要達到的最小代碼覆蓋率或測試覆蓋率百分比。
不要為了覆蓋而覆蓋
追求覆蓋率只是手段而不是目的。測試同學的終極目的還是要在首先的資源情況下最大顯得保障產品質量。不能因為KPI就盲目追求手段的極致，反而本末倒置，最終陷入泥潭不能自拔。