時(shí)間限制給嵌入式開發(fā)人員帶來了在嚴(yán)格的時(shí)間表內(nèi)完成項(xiàng)目需求的壓力，在許多情況下，時(shí)間表是不夠的。此外，人們對嵌入式軟件的可靠性、準(zhǔn)確性和性能的期望高于實(shí)時(shí)計(jì)算。我們還需要考慮嵌入式軟件在其上運(yùn)行的實(shí)際目標(biāo)硬件的約束。軟件符合性和認(rèn)證要求通常是由工業(yè)強(qiáng)加的，以解決安全和保障問題。嵌入式系統(tǒng)的軟件開發(fā)項(xiàng)目面臨著各種各樣的挑戰(zhàn)。
過程標(biāo)準(zhǔn)提供了過程、驗(yàn)證方法和最佳實(shí)踐，以確保軟件安全、安全和高質(zhì)量。其中包括：
DO-178B/C（航空電子設(shè)備）
ISO 26262（汽車）
IEC 62304（醫(yī)療）
IEC 61508（工業(yè)）
EN 50128（軌道）
軟件驗(yàn)證和確認(rèn)是遵守過程標(biāo)準(zhǔn)的重要組成部分。這是一個(gè)涉及不同軟件測試技術(shù)的過程，可能是嚴(yán)格的、昂貴的和耗時(shí)的。
采用一兩種軟件測試技術(shù)不會解決問題。在開發(fā)生命周期中使用各種自動化方法將會節(jié)省你的時(shí)間和金錢。這也將有助于建立一個(gè)可靠的聲譽(yù)，這是無價(jià)的。
嵌入式軟件開發(fā)的自動化測試方法
自動化對于測試嵌入式軟件至關(guān)重要，因?yàn)槭謩臃椒ㄈ菀壮鲥e(cuò)且耗時(shí)。讓我們來討論一下對嵌入式開發(fā)團(tuán)隊(duì)有幫助的重要的自動化測試方法。
1.靜態(tài)代碼分析
首先，建議總是將靜態(tài)代碼分析作為第一種測試方法。執(zhí)行靜態(tài)分析的一個(gè)極好的優(yōu)點(diǎn)是，你可以在項(xiàng)目的任何階段引入和使用它。即使項(xiàng)目是不完整的和部分編碼的，靜態(tài)代碼分析也是有效的，因?yàn)椴恍枰a執(zhí)行。
引入靜態(tài)分析的最大挑戰(zhàn)是大量的代碼會產(chǎn)生大量的警告，將靜態(tài)分析集成到項(xiàng)目中時(shí)，建議關(guān)注以下幾點(diǎn)：
盡快提高團(tuán)隊(duì)效率。
盡量減少團(tuán)隊(duì)被所有靜態(tài)分析警告淹沒的機(jī)會。
這并不是為了降低這些警告的重要性，然而，大多數(shù)嵌入式開發(fā)人員沒有修復(fù)現(xiàn)有或遺留代碼的特權(quán)。
因?yàn)橛懈鞣N編碼符合性標(biāo)準(zhǔn)（MISRA C:2012、AUTOSAR C++14、SEI CERT、CWE等），所以從目標(biāo)開始。如果安全是關(guān)鍵目標(biāo)，那么啟用所有與安全相關(guān)的規(guī)則，禁用不太重要的規(guī)則，并啟用內(nèi)置安全編碼標(biāo)準(zhǔn)之一（如CERT C/C++）是有意義的。
2.動態(tài)分析方法或運(yùn)行時(shí)錯(cuò)誤檢測
如前所述，一種測試方法是不夠的。僅通過靜態(tài)分析不可能識別所有錯(cuò)誤或缺陷。動態(tài)分析方法或運(yùn)行時(shí)錯(cuò)誤檢測也是一種測試實(shí)踐。
這個(gè)測試應(yīng)該與需求相聯(lián)系。它檢查運(yùn)行的代碼，暴露架構(gòu)和行為缺陷、其他弱點(diǎn)和/或安全漏洞，包括內(nèi)存泄漏等等。
嵌入式開發(fā)團(tuán)隊(duì)可以在不同層次的軟件抽象中應(yīng)用這種類型的測試。從測試每個(gè)單獨(dú)的單元或功能開始，然后集成額外的軟件部分。最終軟件測試系統(tǒng)作為一個(gè)整體或黑盒。這通常表現(xiàn)在眾所周知的V-model軟件生命周期中。
3.結(jié)構(gòu)化代碼覆蓋率
在動態(tài)分析方法中，覆蓋了其他可以應(yīng)用的技術(shù)，比如結(jié)構(gòu)化代碼覆蓋。
簡而言之，結(jié)構(gòu)覆蓋是為了確定系統(tǒng)是否經(jīng)過充分測試而對已經(jīng)執(zhí)行和記錄的代碼的識別。如果你可以通過測試用例的執(zhí)行來確定已經(jīng)被執(zhí)行的代碼，那么未被覆蓋或未被執(zhí)行的代碼暴露了對額外測試的需求。
如果你的符合性需求是獲得100%的代碼覆蓋率，那么你將需要至少通過單元測試和手動測試的方式來執(zhí)行覆蓋率。雖然我們可以繼續(xù)揭示其他測試方法，如回歸、性能、壓力、API、UI、驗(yàn)收等等，但是讓我們深入到嵌入式系統(tǒng)測試的現(xiàn)代部署中。
4.持續(xù)集成和持續(xù)交付
在過去的幾年中，一個(gè)越來越受歡迎的話題是持續(xù)集成和持續(xù)交付(CI/CD)。CI/CD是每夜集成的軟件開發(fā)實(shí)踐(將較小的構(gòu)建單元組合成應(yīng)用程序、庫或組件)，目的是構(gòu)建可測試的軟件，用于持續(xù)交付和早期檢測構(gòu)建/集成問題和錯(cuò)誤。
嵌入式開發(fā)開發(fā)中的CI/CD通常受到應(yīng)用程序開發(fā)所沒有的約束。除了目標(biāo)硬件平臺的物理和計(jì)算約束之外，還有合規(guī)性約束。嵌入式軟件市場對極長生命周期的安全性有著獨(dú)特的要求。產(chǎn)品可以在市場上保留幾十年。
今天，一些組織將靜態(tài)分析合并到他們的CI/CD現(xiàn)代開發(fā)工作流程中。自適應(yīng)通常圍繞基于Git的開發(fā)環(huán)境，采用動態(tài)方法進(jìn)行分支和合并，其中開發(fā)人員可以指定一個(gè)父/引用分支來與他們當(dāng)前的開發(fā)分支進(jìn)行比較，并自動比較和計(jì)算用于分析的增量。
因此，不需要在整個(gè)項(xiàng)目上運(yùn)行分析，這可能需要相當(dāng)長的時(shí)間，甚至幾個(gè)小時(shí)，它可以在最少的文件集上運(yùn)行。這縮短了評估會議和聚焦的持續(xù)時(shí)間。然后，可以解決編碼違規(guī)問題并進(jìn)行補(bǔ)救，以獲得干凈、安全和可靠的構(gòu)建。
5.集裝箱化的開發(fā)環(huán)境
另一種類型的現(xiàn)代化來自于集裝箱化的開發(fā)環(huán)境。開發(fā)工具的容器化部署正在成為嵌入式開發(fā)團(tuán)隊(duì)的有力工具。
盡管最初開發(fā)容器是為了解決微服務(wù)和基于web的應(yīng)用程序的部署問題，但最近它們在嵌入式團(tuán)隊(duì)中受到了歡迎。尤其是對于使用容器來管理復(fù)雜工具鏈的大型團(tuán)隊(duì)。
當(dāng)涉及到管理復(fù)雜的開發(fā)環(huán)境時(shí)，尤其是在安全關(guān)鍵領(lǐng)域，團(tuán)隊(duì)通常會面臨以下挑戰(zhàn)，這些挑戰(zhàn)使用容器很容易解決：
將整個(gè)團(tuán)隊(duì)的升級同步到工具的最新版本，比如編譯器、構(gòu)建工具鏈等等。
對庫或軟件開發(fā)工具包(SDK)的新安全補(bǔ)丁作出動態(tài)反應(yīng)，等等。
確保所有團(tuán)隊(duì)成員的工具鏈和自動化基礎(chǔ)設(shè)施(CI/CD)的一致性。
能夠?qū)﹂_發(fā)環(huán)境進(jìn)行版本控制，并恢復(fù)它以服務(wù)于通過特定工具鏈認(rèn)證的產(chǎn)品的舊版本。
總結(jié)
如果你希望簡化嵌入式開發(fā)團(tuán)隊(duì)工作流程、削減成本并縮短上市時(shí)間，那么了解嵌入式安全和安全關(guān)鍵系統(tǒng)開發(fā)中的挑戰(zhàn)、解決方案和現(xiàn)代方法對你非常重要。
