對于安全可靠的嵌入式設備，測試是質量保證不可或缺的一部分。安全關鍵型軟件開發標準對測試方法和測試覆蓋率設定了精確要求，這并非沒有道理。通常，應用程序越關鍵，對代碼覆蓋率的要求就越高。

最重要的代碼覆蓋率級別是：

語句覆蓋率確定測試執行了哪些指令。可以檢測死代碼以及尚未創建合適測試的指令。

分支覆蓋記錄是否所有程序分支都經過測試。這是應放在測試中的最低要求。可以通過合理的努力來實現分支覆蓋。

MC/DC（Modified Condition/Decision Coverage）是標準要求的最高級別，而且相當復雜。為了盡量減少測試工作，使用復合條件的所有原子條件。對于每個原子條件，測試一個測試用例對，導致復合條件的整體結果發生變化，但只有所考慮的原子條件的真值發生變化。這里其他原子條件的真值必須保持不變。

由于代碼檢測，代碼大小增加

為了測量軟件的哪些部分已經過測試，使用了代碼覆蓋分析器。大多數覆蓋分析器的工作原理相同：它們在將代碼傳遞給編譯器之前對其進行檢測。這意味著他們將計數器添加到代碼中，以計算相關代碼部分是否已被執行。這些計數器通常存儲為全局數組。這種檢測的副作用是代碼變得更加龐大。這會給 RAM 和 ROM 帶來額外的負載。

該過程如圖 1 所示：代碼覆蓋率分析器 Testwell CTC++ 將計數器添加到源代碼（“儀器”）。有關計數器的信息存儲在名為“符號數據”的文件中。在測試期間（圖右側），執行次數被計算并存儲在“數據文件”中。在過程結束時，Testwell CTC++ 的“報告生成器”將“符號數據”和“數據文件”中的信息結合起來生成“覆蓋報告”。覆蓋率分析的副作用是更高的內存消耗（通過比較沒有和有儀器的所需內存顯示在底部）。

點擊查看完整大小的圖片

（來源：Verifysoft Technology）

即使是用 C 語言編寫的一個小的 While 條件也可以通過這種方式顯著增長。

初始結構

而（！b == 0）
{
r = a % b;
a = b;
b = r;
}
結果=一個；

通過使用代碼覆蓋率分析器 Testwell CTC++ 進行檢測，變為以下內容：

而 (((! b == 0) ? (ctc_t[23]++, 1): (ctc_f[23]++, 0)))
{
r = a % b;
a = b;
b = r;
}
結果=一個；

對于服務器或 PC 應用程序，這種影響可以忽略不計。另一方面，對于嵌入式設備，儀器開銷可能會帶來挑戰，因為出于成本原因，硬件資源的計算通常非常嚴格。在這里，必須注意使用具有相對較低檢測開銷的代碼覆蓋分析器，否則計數器將很快超過可用內存的限制。當需要非常苛刻的測試覆蓋級別（例如 MC/DC）時尤其如此。針對嵌入式系統優化的特殊分析儀，例如 Verifysoft Technology 的 Testwell CTC++，是正確的選擇。

部分儀器

If the code coverage tool has a too high instrumentation overhead, this hurdle can be circumvented in RAM with partial instrumentation. With partial instrumentation, only small sections of the program under test are instrumented and tested. The test is repeated one after the other with all program parts, and the resulting data is combined to form an overall picture. This allows to determine the test coverage for the complete program.

測量小目標上的代碼覆蓋率的另一種可能的解決方案是限制計數器的大小。通常，代碼覆蓋工具使用 32 位計數器。這些計數器可以減少到 16 或 8 位。但是，這里應該小心，因為在某些情況下，計數器可能會溢出。因此，必須非常小心地解釋獲得的數據。在極端情況下，計數器也可以降低到單個位。此位覆蓋（由 Testwell CTC++ 提供）可能很有用，例如，如果與程序部分運行的頻率無關。

不幸的是，ROM 中所需的額外空間幾乎是有限的。需要一個小型庫來捕獲代碼覆蓋率，除其他外，它負責將計數器讀數傳輸到主機。

不要忘記：除了內存之外，檢測還會給目標中的處理器帶來負擔。因此，可能會發生不再遵守定義的時間安排的情況。特別是如果 CPU 已經接近極限工作，可能會出現錯誤的進程。總線通信對此特別敏感。在這里，測試人員應該仔細監控過程并仔細檢查結果。然而，強大的代碼覆蓋工具可以使檢測內存需求和運行時行為變化保持相對較低。

結論

安全和安保在物聯網計劃的長期成功中發揮著重要作用。除了工業應用外，還必須以可控制用戶和制造商風險的方式開發和測試私營部門的物聯網程序。雖然 MC/DC 覆蓋對于汽車和飛機中的安全關鍵型應用是強制性的，但至少分支覆蓋應該是所有其他領域的標準。目前，只有少數標準要求證明對非安全關鍵軟件的測試覆蓋率，但標準化機構和行業協會在安全關鍵應用程序之外增加要求只是時間和市場滲透的問題。更好的測試也符合制造商本身的利益，因為有缺陷的產品會導致高昂的后續成本，并會嚴重損害公司的聲譽。嵌入式領域的客戶幾乎不會接受以 PC 聞名的“香蕉軟件”，交付后才成熟。