很長一段時間以來，嵌入式軟件一直用于安全性非常重要的關鍵應用。在嵌入式開發中，由于嵌入式設備通常是與物聯網(IoT)上的其他設備相連接的客戶端，因此還需要考慮安全性問題。這意味著，無論是從安全角度還是從功能安全角度來看，嵌入式設備的質量都極其重要。

 

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

 

最重要的代碼覆蓋率是：

報表覆蓋范圍確定測試執行了哪些指令。可以檢測死代碼以及還沒有為其創建合適測試的指令。

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

 

MC/DC(修改的條件/決策范圍)是標準要求的最高級別，相當復雜。為了最小化測試工作，使用了復合條件的所有原子條件。在嵌入式開發中，對于每一個原子條件，測試用例對被測試，導致復合條件的整體結果的改變，但是只有考慮中的原子條件的真值改變。這里，其他原子條件的真值必須保持不變。

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

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

 

這個過程如圖1所示。代碼覆蓋率分析器Testwell CTC++向源代碼添加計數器(“插裝”)。關于計數器的信息存儲在名為“符號數據”的文件中。在測試期間(圖的右側),執行的次數被計數并存儲在“數據文件”中。在過程的最后，Testwell CTC++的“報告生成器”將來自“符號數據”和“數據文件”的信息結合起來，生成一個“覆蓋報告”。在嵌入式開發中，覆蓋率分析的副作用是更高的內存消耗(通過比較使用和不使用工具時所需的內存顯示在底部)。

即使用C編寫的While條件很小，也能以這種方式顯著增長。

初始結構

通過使用代碼覆蓋率分析器Testwell CTC++，變成了以下代碼：

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

 

部分儀器

如果代碼覆蓋工具的插裝開銷太高，那么可以在RAM中使用部分插裝來繞過這個障礙。使用部分插裝，只有被測程序的一小部分被插裝和測試。對所有程序部分一個接一個地重復測試，并將結果數據組合在一起，形成一個整體圖。這允許確定整個程序的測試覆蓋率。

 

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

 

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

 

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

 

結論

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