很長一段時(shí)間以來，嵌入式軟件一直用于安全性非常重要的關(guān)鍵應(yīng)用。在嵌入式開發(fā)中，由于嵌入式設(shè)備通常是與物聯(lián)網(wǎng)(IoT)上的其他設(shè)備相連接的客戶端，因此還需要考慮安全性問題。這意味著，無論是從安全角度還是從功能安全角度來看，嵌入式設(shè)備的質(zhì)量都極其重要。
對于安全可靠的嵌入式設(shè)備，測試是質(zhì)量保證不可或缺的一部分。安全關(guān)鍵軟件開發(fā)的標(biāo)準(zhǔn)為測試方法和測試覆蓋范圍設(shè)定了精確的要求，這不是沒有原因的。通常，應(yīng)用程序越重要，對代碼覆蓋率的要求就越高。
最重要的代碼覆蓋率是：
報(bào)表覆蓋范圍確定測試執(zhí)行了哪些指令。可以檢測死代碼以及還沒有為其創(chuàng)建合適測試的指令。
分支覆蓋記錄是否所有程序分支都已經(jīng)過測試。這是對測試的最低要求。分支覆蓋可以通過合理的努力來實(shí)現(xiàn)。
MC/DC(修改的條件/決策范圍)是標(biāo)準(zhǔn)要求的最高級別，相當(dāng)復(fù)雜。為了最小化測試工作，使用了復(fù)合條件的所有原子條件。在嵌入式開發(fā)中，對于每一個(gè)原子條件，測試用例對被測試，導(dǎo)致復(fù)合條件的整體結(jié)果的改變，但是只有考慮中的原子條件的真值改變。這里，其他原子條件的真值必須保持不變。
由于代碼檢測，代碼大小增加了
為了測量軟件的哪些部分已經(jīng)被測試，代碼覆蓋分析器被使用。大多數(shù)覆蓋率分析器都是根據(jù)相同的原理工作的:它們在將代碼傳遞給編譯器之前對代碼進(jìn)行檢測。這意味著它們向代碼添加計(jì)數(shù)器，這些計(jì)數(shù)器計(jì)算相關(guān)的代碼部分是否已經(jīng)被執(zhí)行。這些計(jì)數(shù)器通常存儲(chǔ)為全局?jǐn)?shù)組。這種檢測的副作用是代碼變得更加龐大。這給RAM和ROM都增加了額外的負(fù)載。
這個(gè)過程如圖1所示。代碼覆蓋率分析器Testwell CTC++向源代碼添加計(jì)數(shù)器(“插裝”)。關(guān)于計(jì)數(shù)器的信息存儲(chǔ)在名為“符號數(shù)據(jù)”的文件中。在測試期間(圖的右側(cè)),執(zhí)行的次數(shù)被計(jì)數(shù)并存儲(chǔ)在“數(shù)據(jù)文件”中。在過程的最后，Testwell CTC++的“報(bào)告生成器”將來自“符號數(shù)據(jù)”和“數(shù)據(jù)文件”的信息結(jié)合起來，生成一個(gè)“覆蓋報(bào)告”。在嵌入式開發(fā)中，覆蓋率分析的副作用是更高的內(nèi)存消耗(通過比較使用和不使用工具時(shí)所需的內(nèi)存顯示在底部)。
即使用C編寫的While條件很小，也能以這種方式顯著增長。
初始結(jié)構(gòu)
通過使用代碼覆蓋率分析器Testwell CTC++，變成了以下代碼：
對于服務(wù)器或PC應(yīng)用程序，這種影響可以忽略。另一方面，對于嵌入式設(shè)備，儀器開銷可能會(huì)帶來挑戰(zhàn)，因?yàn)槌鲇诔杀驹?，硬件資源通常計(jì)算得非常嚴(yán)格。在這里，必須小心使用具有相對較低檢測開銷的代碼覆蓋率分析器，否則計(jì)數(shù)器將很快超過可用內(nèi)存的限制。當(dāng)需要非常苛刻的測試覆蓋級別（如MC/DC）時(shí)，尤其如此。為嵌入式系統(tǒng)優(yōu)化的專用分析儀，如Verifysoft Technology的Testwell CTC++，是正確的選擇。
部分儀器
如果代碼覆蓋工具的插裝開銷太高，那么可以在RAM中使用部分插裝來繞過這個(gè)障礙。使用部分插裝，只有被測程序的一小部分被插裝和測試。對所有程序部分一個(gè)接一個(gè)地重復(fù)測試，并將結(jié)果數(shù)據(jù)組合在一起，形成一個(gè)整體圖。這允許確定整個(gè)程序的測試覆蓋率。
測量小目標(biāo)代碼覆蓋率的另一個(gè)可能的解決方案是限制計(jì)數(shù)器的大小。通常，代碼覆蓋率工具使用32位計(jì)數(shù)器。這些計(jì)數(shù)器可以減少到16或8位。但是，這里應(yīng)該小心，因?yàn)樵谀承┣闆r下，計(jì)數(shù)器可能會(huì)溢出。因此，必須非常小心地解釋所獲得的數(shù)據(jù)。在極端情況下，計(jì)數(shù)器也可以降低到一位。在嵌入式開發(fā)中，這種位覆蓋(由Testwell CTC++提供)可能是有用的，例如，如果它與程序段運(yùn)行的頻率無關(guān)。
不幸的是，ROM中所需的額外空間幾乎是有限的。需要一個(gè)小的庫來捕獲代碼覆蓋率，它負(fù)責(zé)將計(jì)數(shù)器讀數(shù)傳輸?shù)街鳈C(jī)。
不要忘記:除了內(nèi)存之外，檢測還會(huì)給目標(biāo)中的處理器帶來負(fù)載。因此，可能會(huì)出現(xiàn)不再遵守規(guī)定時(shí)間的情況。特別是如果CPU已經(jīng)接近極限工作，可能會(huì)出現(xiàn)錯(cuò)誤的進(jìn)程?？偩€通信尤其容易受此影響。在這里，測試人員應(yīng)該仔細(xì)監(jiān)控過程，并仔細(xì)檢查結(jié)果。然而，強(qiáng)大的代碼覆蓋工具可以保持檢測內(nèi)存需求和運(yùn)行時(shí)行為變化相對較低。
結(jié)論
安全性在物聯(lián)網(wǎng)計(jì)劃的長期成功中發(fā)揮著重要作用。除了工業(yè)應(yīng)用，私營部門的物聯(lián)網(wǎng)項(xiàng)目也必須以用戶和制造商風(fēng)險(xiǎn)可控的方式進(jìn)行開發(fā)和測試。雖然MC/DC保險(xiǎn)對汽車和飛機(jī)中的安全關(guān)鍵應(yīng)用是強(qiáng)制性的，但至少分支機(jī)構(gòu)保險(xiǎn)在所有其他領(lǐng)域應(yīng)該是標(biāo)準(zhǔn)的。目前，只有少數(shù)標(biāo)準(zhǔn)要求非安全關(guān)鍵軟件的測試覆蓋范圍證明，但標(biāo)準(zhǔn)化機(jī)構(gòu)和行業(yè)協(xié)會(huì)增加安全關(guān)鍵應(yīng)用之外的要求只是時(shí)間和市場滲透的問題。在嵌入式開發(fā)中，更好的測試也符合制造商自身的利益，因?yàn)橛腥毕莸漠a(chǎn)品會(huì)導(dǎo)致高昂的后續(xù)成本，并會(huì)嚴(yán)重?fù)p害公司的聲譽(yù)。
