代碼覆寫率VS測試覆寫率

測試覆寫率和代碼覆寫率是衡量代碼有效性的最流行方法。這些術語有時會同時出現，因為它們的基本原理相同。但是它們并不是那麼一緻。很多時候，測試團隊和開發團隊對這兩個術語的使用感到困惑。下面詳細讨論代碼覆寫率和測試覆寫率之間的差別的原因。

概念

代碼覆寫率：表示通過用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#等）的工具。是以，如果團隊使用多種程式設計語言（用于測試代碼開發），則需要多個工具。

不要為了覆寫而覆寫

Have Fun ~ Tester ！歡迎關注FunTester

• 140道面試題目（UI、Linux、MySQL、API、安全）
• 圖解HTTP腦圖
• 分享一份Fiddler學習包
• 線程池處理批量接口請求實踐
• 10萬QPS，K6、Gatling和FunTester終極對決！
• 性能瓶頸調優【粉絲投稿】
• 如何選擇API測試工具
• 初學者的API測試技巧
• API自動化測試指南
• API測試基礎
• 無資料驅動自動化測試
• 自動化和手動測試，保持平衡！
• 43種常見軟體測試分類