如何優(yōu)化安全和業(yè)務關鍵型嵌入式軟件開發(fā)

開發(fā)安全或業(yè)務關鍵型軟件只需要更多的知識和努力，以確保以不犧牲質量的方式使用工具和技術。

任何優(yōu)化軟件開發(fā)過程的嘗試都將不可避免地遇到質量、資源和時間之間的古老權衡。這個三重約束對于項目經理來說是眾所周知的，格言是只有三分之二才有可能成功。

當然，沒有一家公司真的想在質量上妥協(xié)，但對于安全關鍵型或業(yè)務關鍵型軟件而言，風險更高，因為在質量上妥協(xié)可能會導致嚴重的財務或危及生命的后果，因此主要關注點必須放在質量上對于此類項目。那么，當項目的性質要求軟件質量必須是最重要的時候，您如何優(yōu)化嵌入式軟件開發(fā)呢？

培養(yǎng)質量文化
質量文化將減少實現(xiàn)優(yōu)質產品的開銷，并意味著在生產高質量軟件時需要更少的有意識的思考和努力。

幸運的是，通過遵循一些簡單的原則，發(fā)展質量文化相對容易。質量文化傾向于促進透明度和所有權。他們還將測試和質量控制視為開發(fā)過程的重要組成部分，而不是最后的開發(fā)步驟。

有效的質量文化的基石是良好的溝通。技術包括從每日例會到報告錯誤時提高清晰度的所有內容，以便在修復錯誤時不太可能犯錯誤?？缏毮軋F隊和團隊之間的密切溝通也有助于促進質量文化，并確保所有利益相關者對質量和安全目標有很好的理解。

優(yōu)化您的軟件開發(fā)方法
現(xiàn)代軟件開發(fā)方法，如敏捷和 DevOps，被廣泛認為比傳統(tǒng)的瀑布方法產生更快的結果。所有主要的軟件安全標準（例如，IEC 61508、ISO 26262 和 DO-178C）都將軟件開發(fā)定義為一個線性過程，v 模型在左側顯示需求定義，在右側顯示測試，如下圖所示：

這使得在開發(fā)安全關鍵軟件時很難擺脫線性瀑布方法。現(xiàn)代敏捷開發(fā)實踐側重于頻繁發(fā)布，這可能會給安全關鍵型軟件的開發(fā)帶來問題，因為每個發(fā)布都需要經過正式的驗證和/或認證流程。同樣，DevOps 原則（例如持續(xù)部署）在涉及硬件時會變得更加復雜。

但是，仍然可以利用許多 DevOps 和敏捷原則來創(chuàng)建一種簡化的、更具迭代性的方法來開發(fā)安全關鍵型和業(yè)務關鍵型嵌入式項目。

Shift-left
在項目開發(fā)生命周期中較早（左）移動工作量通常會導致整體工作量減少?；ǜ鄷r間確保軟件需求和設計正確可減少生產問題并避免將時間花在浪費性的開發(fā)活動上。左移的測試方法的原理是，更早地發(fā)現(xiàn)錯誤意味著可以更快、更容易、更便宜地修復它們。這主要是因為，如果測試被延遲，依賴項變得難以解除。

Shift-left 可以增量地應用于大型和復雜的系統(tǒng)。敏捷通過在敏捷方法中為每個沖刺或迭代使用迷你 v 模型來進一步實現(xiàn)這一點。

編寫高質量的需求
定義明確的需求需要正確、完整、分解、明確和邏輯一致。這將有助于避免昂貴的返工和受挫的利益相關者。

為確保完整性，根據實際用例驗證需求或按照某些敏捷方法中的建議創(chuàng)建故事很有用。通過分解將需求定義到適當的詳細程度也有助于確保低層次的需求集中在單一的概念上。一旦定義了一組需求，最好檢查它們的邏輯一致性。使用模板來鼓勵語法一致性有助于使這些檢查更容易，從而在需求重疊或沖突時變得明顯。

從硬件開始 在軟件設計過程的早期考慮硬件對于確保不浪費精力至關重要。同樣，盡早修復應用程序編程接口 (API) 功能等通信接口也是一個好主意。

在為安全或業(yè)務關鍵型項目選擇或設計硬件時，還值得考慮用于測試的硬件可用性的時間范圍。當然，最好讓選定的硬件可用于測試，但這并不總是可行的，因為有時硬件是并行開發(fā)的。在這些情況下，主機然后目標測試可能是一種可行的解決方案，或者在模擬器上進行測試（如果有的話）。當需要在這些不同的環(huán)境中執(zhí)行測試時，可以使用條件編譯（例如，#ifdef 等 C 指令），從而避免重復測試的需要。

讓領域專家參與需求定義
確保正確的人員正在審查需求并驗證它們的正確性和完整性是至關重要的。領域專家的示例包括業(yè)務分析師、技術專家、營銷和最終用戶。從廣泛的角度考慮需求有助于從一開始就正確地定義它們。

領域專家應確保指定的需求真正捕捉到應用程序或設備的目標。他們還應該檢查需求是否與編寫它們要實現(xiàn)的業(yè)務、功能和安全目標相匹配?；蛘撸瑢τ谳^低級別的需求，將它們追溯到滿足這些目標之一的較高級別的需求。

為確保優(yōu)化此流程，不同角色將需要不同級別的需求數據；例如，業(yè)務分析師將驗證的需求不會分解到與開發(fā)人員將驗證的需求相同的級別。需求管理工具 (RMT) 可用于確保以清晰和有組織的方式向所有利益相關者提供他們所需的需求數據。將需求保留在 RMT 中還可以通過清楚地顯示更高級別和更低級別需求之間的可追溯性來幫助分解。

優(yōu)化項目范圍
在項目的設計階段，值得注意的是質量和范圍的區(qū)別。產品的質量是安全或業(yè)務關鍵項目中不能犧牲的東西；但是，可能有縮小范圍的空間。大多數安全標準都建議盡可能簡單地設計系統(tǒng)，因為這使它們更容易測試，更不用說實施、維護和適應了。

簡單的設計
應用程序和固件/硬件之間的內存管理和分層的必要性通常意味著代碼復雜性是嵌入式開發(fā)中的一個問題。但是，限制使用全局變量和避免嵌套 if 語句（超過兩個或三個）等編碼實踐有助于限制代碼復雜性并提高可維護性。MISRA C/C++ 等語言子集可以提供一種有用的方法來提高程序的安全性和可移植性。

確保代碼是模塊化的有助于防止脆弱的設計，避免具有過長實現(xiàn)的函數，并旨在通過松散耦合使組件具有內聚性。架構分析矩陣是識別組件依賴關系的有用方法，并且可以使用工具來自動生成它們。通過應用分層等技術優(yōu)化交互也有助于保持嵌入式代碼的可管理性。

靜態(tài)分析
第一個驗證階段很可能是靜態(tài)分析。此技術可用于在代碼執(zhí)行之前發(fā)現(xiàn)代碼問題。靜態(tài)分析工具提供有關代碼潛在問題的即時反饋。靜態(tài)分析解決方案應提供有關影響可靠性、可維護性和可移植性的代碼的信息。靜態(tài)分析還可用于強制執(zhí)行 MISRA C/C++ 等編碼標準。

自動化測試生成
驗證的下一階段是在單元級別動態(tài)測試代碼并執(zhí)行檢查以確保行為符合需求中的定義。創(chuàng)建這些詳細的測試很耗時，但很有必要?，F(xiàn)代測試工具可以自動生成這些低級測試。這通常通過解析代碼和生成單元測試來實現(xiàn)所需的結構代碼覆蓋率。

自動生成的測試向量不僅可以驅動代碼，還可以檢查函數之間傳遞的參數、可訪問的全局數據的值、調用順序和返回值。此過程還將確保生成一套全面的測試，涵蓋已在代碼中實現(xiàn)的所有功能。這些生成的測試需要根據軟件單元設計需求進行驗證，以確保需求得到驗證。

使用持續(xù)集成
一旦創(chuàng)建了一組通過的測試，它們就可以不斷地重新運行，以識別在增強或重構代碼時引入的任何回歸錯誤。這個基線安全網減少了對耗時且昂貴的系統(tǒng)測試的依賴，并且更加徹底并準確地識別錯誤的位置。

持續(xù)集成可用于將代碼集成到具有自動單元、集成以及系統(tǒng)級測試（如果可能）的共享存儲庫中。這可以大大加快開發(fā)速度，因為每次構建代碼時運行回歸測試提供了一個非常快速的反饋循環(huán)。它還使合并代碼分支更容易，從而減少破壞現(xiàn)有代碼的機會。

圖 3：持續(xù)集成過程（來源：QA Systems Ltd）

在設置持續(xù)集成環(huán)境時，重要的是優(yōu)化運行的測試，以確保您擁有一套全面但精簡的測試，這些測試運行速度快，同時仍執(zhí)行必要的檢查。分析代碼更改的影響以識別并僅運行受影響的測試有助于優(yōu)化此過程。自動測試生成也可以是一個好方法，只需單擊一個按鈕即可創(chuàng)建一套初始的精益回歸測試。

保持硬件循環(huán)
持續(xù)集成的一個目標是持續(xù)部署，當涉及到硬件時，這可能很難實現(xiàn)。嵌入式平臺上的測試引入了不同于本地主機測試的挑戰(zhàn)，例如內存不足、缺乏可用功能（例如文件 I/O）、中斷處理以及編程語言的非標準擴展。盡管可以使用變通方法來解決這些問題中的許多問題，但如果可以通過事先計劃來避免它們，則效率會更高；例如，通過確保選擇具有“內存蠕變”能力的目標并確保硬件有足夠的準備來測試軟件。

調用控制技術，例如存根（有時稱為模擬），是一種標準且有用的方法來管理對不可用對象（例如，硬件）的調用。諸如“包裝”之類的高級技術可用于攔截呼叫。這對于集成測試檢查返回路徑并使用返回值或替換它非常有用。這允許在添加對象時驗證對象之間的交互。該技術對于模擬無法實現(xiàn)的現(xiàn)實條件（例如硬件故障）也特別有用。

簡化需求可追溯性
所有安全標準都需要測試和需求之間的可追溯性證據。將需求與測試用例匹配的過程很難自動化。對于以自然語言定義的需求，將需求翻譯成代碼的可靠解釋水平仍然遠遠超出當前機器學習 (ML) 的水平。但是，可以使用一些工具來提高記錄需求可追溯性的手動過程的效率。

需求可追溯性經常出現(xiàn)的一個問題是對不斷變化的需求的管理。在這里，使用工具來突出顯示更改以及與修改后的需求相關的測試用例是非常寶貴的。

編寫易于
維護的測試 在重構代碼時維護測試也是一個重大問題，因為即使是很小的更改也會破壞測試。單元和集成測試非常依賴源代碼結構，因此在更改代碼時它可能很脆弱（在某些情況下甚至沒有構建），并且修復它們可能很耗時。在這里，測試工具可用于識別影響測試的代碼更改和自動化測試維護，包括根據對代碼所做的更改提供測試的自動重構。

明智地投資
通過以適合您項目的方式選擇上述技術的組合，優(yōu)化您的開發(fā)過程是可行的，即使在質量上不可能妥協(xié)。但是，所有優(yōu)化都需要一定程度的投資，這可能涉及開發(fā)新流程、改進工具或增加開發(fā)團隊的規(guī)模。

可以有效地開發(fā)安全或業(yè)務關鍵型軟件，當然也不能幸免于現(xiàn)代開發(fā)技術。只需要更多的知識和努力來確保以不犧牲質量的方式使用工具和技術。

QA Systems是歐洲領先的安全關鍵市場軟件質量解決方案提供商。我們的工具用于自動化單元測試、代碼覆蓋、集成測試和靜態(tài)分析。所有工具均由 SGS TüV 獨立認證，可用于所有主要安全標準（ISO 26262、IEC 61508、IEC 62304、EN 50128 和 IEC 60880）的安全相關軟件開發(fā)的最高完整性級別，并且符合 DO 等標準-178B/C。QA Systems 最近在馬薩諸塞州波士頓開設了第一家北美辦事處，以更好地幫助北美客戶加速開發(fā)符合安全標準的關鍵業(yè)務軟件。

審核編輯 黃昊宇