測量代碼覆蓋率對于嵌入式系統來說越來越重要，但需要一些經驗。這是因為有一些障礙需要克服，尤其是小目標。但是，使用正確的方法和合適的工具，無需過多努力即可測量測試覆蓋率。九個實用技巧可幫助您入門。

測量測試覆蓋率，也稱為代碼覆蓋率，對于嵌入式系統變得越來越重要。在許多情況下，這些設備對安全或業務至關重要。流程基于物聯網設備，患者依賴工作起搏器和智能胰島素泵，沒有嵌入式軟件就無法想象汽車和航空業。這份清單幾乎可以無限延續。隨著各種設備的重要性增加，在安全、安保和功能方面必須滿足的要求也在增加。安全標準將這一點考慮在內，并明確要求將測試覆蓋率記錄為產品驗證的一部分。

特別是對于初學者來說，測量代碼覆蓋率似乎非常復雜和耗時。但是，如果您注意一些基本方面，事情很快就會變得容易。

1.設定期望

通常并不完全清楚對代碼覆蓋的期望。覆蓋率測量并非旨在直接改進代碼。他們的目的是確定代碼是否經過全面測試以及測試用例是否完整。因此，代碼覆蓋率更適合于改進測試——并最終證明已經執行了足夠的測試。

2. 確定所需的測試覆蓋水平

有許多不同的測試覆蓋級別。可以說：測試覆蓋率越嚴格和詳細，實現它所需的努力和成本就越大。

不幸的是，只有少數標準，如航空領域的 DO-178C、電氣/電子、可編程電子安全相關系統的功能安全性 IEC 61508 或汽車領域的 ISO 26262，對所需的代碼覆蓋級別給出了具體指導。

根據 IEC 61508 的安全完整性等級 (SIL) 或 ISO 26262 的汽車安全等級 (ASIL)，需要語句覆蓋率、分支覆蓋率或 MC/DC（修改條件/決策覆蓋率）（有關代碼覆蓋率級別的更多信息，請參閱單獨解釋）。以下適用于所有標準：可能錯誤的影響越危險，所需的覆蓋級別就越嚴格。

這可以從 ISO 26262 標準的下表中看出。最高安全等級 ASIL D 需要最高覆蓋等級 MC/DC。表中++代表強烈推薦，+代表推薦。在這里我們可以說完整的修改條件/決策覆蓋自動意味著完整的分支覆蓋，而完整的分支覆蓋自動意味著完整的語句覆蓋。

圖 1：ISO 26262 表 12 – 軟件單元級別的結構覆蓋度量（來源：國際標準 ISO 26262-6）

對于沒有通過標準規定的軟件，提前確定哪些代碼需要根據哪些標準進行測試也很重要。將上述標準用作指南并將測試范圍與系統的關鍵性保持一致可能會有所幫助。

三、測試范圍的確定

完整的代碼覆蓋率最初意味著已達到指定測試級別的 100%。然而，這通常只在安全關鍵區域是必要的。

僅僅為了滿足這個標準而瞄準 100% 的代碼覆蓋率通常是沒有幫助的。重要的是要知道為什么要運行某些測試用例。如果您不知道，那么重復測試一遍又一遍地運行已經測試過的代碼的風險很高。這種更高的努力并沒有得到回報，因為這些額外的測試并沒有提供任何新的見解。順便說一句，使用代碼覆蓋分析器是避免這種冗余測試的好方法。

在非關鍵應用領域，測試既不應該“太少”也不“完整”，而應該“足夠”。

4. 確定支持的編程語言

有許多代碼覆蓋分析器：從免費工具（例如 GNU 編譯器集合 (GCC) 的一部分 GNU Coverage Testing Tool Gcov）到全面的解決方案（例如Verifysoft Technology 的Testwell CTC++ ），它除了支持所有代碼覆蓋之外級別還支持各種語言。如果可能，公司使用的所有語言都應該能夠使用單一的覆蓋工具進行處理。這樣，開發人員和測試人員可以在統一的界面中工作，而不必熟悉不同的工具。對于嵌入式軟件開發，該工具應至少涵蓋 C、C++ 和 Java。

關于代碼覆蓋級別的進一步說明

功能覆蓋

函數覆蓋率測量是否調用了程序的所有函數。功能覆蓋率是通常測試覆蓋率級別中“最弱的”。由于它忽略了軟件的內部工作，所以它的實用性很低。

聲明覆蓋范圍

語句覆蓋率決定了測試執行了哪些語句。例如，這可以用于檢測死代碼。它還顯示測試是否適用于所有語句。

決策覆蓋/分支覆蓋

在此覆蓋級別上，每個決策必須至少測試一次為真，一次為假。對于普通的 if 語句，這對應于分支覆蓋，其中每個分支都必須已執行。

條件覆蓋

條件覆蓋詳細考慮復合決策。對于由通過布爾運算符組成的多個原子條件組成的決策，必須將這些條件中的每一個單獨測試為“真”和“假”。

多條件覆蓋和修改條件/決策覆蓋 (MC/DC)

對于多條件覆蓋，必須檢查所有可能的真假組合以進行復合決策。在一個決策中有多個條件的情況下，這需要大量幾乎不切實際的測試用例。因此，在實踐和標準中，修改的條件/決策覆蓋（MC/DC）是相關的，其中測試用例的數量減少了，而測試覆蓋的信息價值仍然足夠高。對于 MC/DC，使用復合條件的所有原子條件。對每一個原子條件測試一個測試用例對，這會導致復合條件的整體結果發生變化，但只有考慮的原子條件的真值發生變化，而其他原子條件的真值必須保持不變持續的。

5.節省內存空間

在小目標上測量代碼覆蓋率時，有限的內存空間通常是一個障礙。原因是需要對代碼進行檢測：為了測量覆蓋率，代碼覆蓋率工具會在代碼中插入計數器。此外，必須在要測試的目標上實現一個庫，其中包括處理到主機的數據傳輸。

計數器通常作為全局數組存儲在數據存儲器中。特別是對于尺寸非常緊湊的目標，這可能會導致問題。

補救措施是專門用于嵌入式設備的代碼覆蓋率分析器。此類工具盡可能少用。在檢測開銷仍然很高的情況下，可以針對各個代碼部分單獨分析代碼覆蓋率。

第三種方法是減小計數器的大小。通常，計數器的大小為 32 位。特殊安排將計數器大小減少到 16 或 8 位。但是，必須注意避免溢出。覆蓋分析儀 Testwell CTC++ 的 bit-cov-measure 是針對小型嵌入式目標和微處理器的特殊安排。

6. 檢查可能對處理器造成的影響

為了節省成本，很多嵌入式設備不僅內存小，而且處理器也經常有局限性。但是，儀器也會影響處理器。因此，可能會超出定義的時間，這可能會導致在某些情況下程序運行錯誤。

不幸的是，由于處理器負載略高，無法提前可靠地預測是否會出現問題。可能的影響只會在相應的項目中變得明顯。出于這個原因，還應根據其對時序的影響來選擇代碼覆蓋分析器。如有必要，使用較小的計數器（如上所述）或部分儀器可以糾正這種情況。

也可以在覆蓋分析的情況下運行一次測試，在沒有覆蓋分析的情況下運行一次，以確定覆蓋分析是否導致程序行為的變化。

7.檢查集成到您的工具鏈中的可能性

越來越多的測試正在自動化。這是有道理的，因為人工干預始終是潛在的錯誤來源，也會導致巨大的成本。構建系統測試的自動化是必需的，尤其是在使用持續集成/持續部署 (CI/CD) 的敏捷開發中。但是，這要求使用的代碼覆蓋分析器可以集成到工具鏈和構建系統中。此外，覆蓋工具也應該獨立于所使用的編譯器。

尤其是在大型開發項目中，自動化測試和代碼覆蓋率的自動捕獲是不可缺少的。因此，重要的是代碼覆蓋工具可以輕松順利地集成到工具鏈中。另一方面，復雜的儀表板和前端對于自動化測試來說是微不足道的。

8. 驗證報告的可理解性

代碼覆蓋會產生大量數據。每個測試領域——單元測試、模塊測試、功能測試等——都提供了自己的代碼覆蓋率數據。為了獲得完整的圖片，應該匯總這些信息。由代碼覆蓋率分析器以有意義且可解釋的方式準備此信息。

此外，這些數據在可能需要的認證或審核方面也很重要。

重要的是，覆蓋工具提供的信息既可以用于進一步自動處理的機器可讀形式（例如 XML），也可以以人類可讀的形式（例如 HTML）提供，以便快速和良好地概覽。

圖 2：代碼覆蓋率分析器 Testwell CTC++ 的 HTML 報告（函數摘要）一目了然地顯示了測試覆蓋了哪些函數。完全覆蓋的功能以藍色顯示。對于以紅色顯示的功能，覆蓋率低于 100%。例如，函數“lights()”具有 75% 的多條件覆蓋率和 83% 的語句覆蓋率（TER 代表“測試有效性比率”）。（來源：Verifysoft Technology）

圖 3：Testwell CTC++ 的執行配置文件顯示了源代碼中涵蓋項目的詳細信息。（來源：Verifysoft Technology）

9. 檢查代碼覆蓋工具是否適合開發安全關鍵型軟件

對于安全關鍵型軟件的開發，不言而喻，代碼覆蓋工具必須支持相應標準要求的覆蓋水平。

此外，標準要求對整個工具鏈進行鑒定。用于代碼覆蓋分析器的工具鑒定工具包的可用性大大簡化了這項工作。在這種情況下，工具提供商是否在此提供適當的建議也很重要。

結論

測量代碼覆蓋率并非易事，但也不是太復雜。因此，幾乎沒有任何充分的理由放棄代碼覆蓋——即使在非關鍵領域也是如此。測試覆蓋率在多個層面上有所幫助：可以優化測試和測試程序，從而帶來顯著的成本和時間優勢。此外，代碼覆蓋率確保產品已經過充分測試，并以一定的最低質量到達客戶手中。

嵌入式系統供應商不應該重蹈 IT 行業的覆轍：交付在客戶現場成熟的“香蕉軟件”。嵌入式設備的用戶不會接受這一點——尤其是當涉及“關鍵”產品時，例如汽車行業的醫療設備或 ECU。

審核編輯 黃昊宇