在嵌入式系統的世界中，不斷發(fā)展和發(fā)展的不僅僅是技術。用于開發(fā)該技術的工具和方法正在不斷成熟和改進。

在 1980 年代初期，我為一家小型計量公司開發(fā)了軟件，將工程數學應用于坐標測量機 (CMM)。我想認為我很擅長。但我們的開發(fā)生命周期本質上將生產軟件視為沙盒。我們將從生產代碼開始，添加功能，執(zhí)行一些相當基本的功能測試，然后發(fā)布。

在這樣一個小公司，我們的工程團隊自然包括軟件和硬件專家。事后看來，令人驚訝的是，雖然我們開發(fā)的軟件需要廣泛的客戶支持，但它所運行的硬件卻遠沒有相同的消防文化。

軟件開發(fā)是一門工程學科

軟件和硬件支持之間的部分差異是原始開發(fā)過程的結果。但是軟件的絕對可塑性以及由此產生的不斷增加的功能的能力也起著重要作用。簡而言之，出錯的方法比正確的方法要多得多，而且這種特性要求它被視為一門工程學科。

這一切都沒有什么新鮮事。多年來，領先的航空、汽車和工業(yè)功能安全標準（例如 DO-178、ISO 26262 和 IEC 61508）一直要求采用這種方法。但是，如果您要從當今旨在服務于這種方法的尖端開發(fā)和測試工具中獲益，那么擁有工程學科的思維方式是必不可少的。

最近，ISO/IEC/IEEE 29119 的發(fā)展表明了軟件測試的重要性，這是一套可在任何軟件開發(fā)生命周期或組織中使用的軟件測試國際標準。

需求很重要

電氣系統設計通常從狀態(tài)機開始，并了解特定產品的不同操作模式。工程師通常可以非?？焖佟⑤p松地將狀態(tài)機功能映射到邏輯。如果狀態(tài)機變得更復雜，它通常被翻譯成軟件。

高級別的要求對于確保系統正常運行至關重要。這樣的需求描述了業(yè)務邏輯和預期的功能，并能夠評估系統是否完成了它應該做的事情。最佳實踐遵循從高級需求到分析到覆蓋率的流程，自然，需求可追溯性工具旨在支持這一點。

在狀態(tài)機模型中，表征每個狀態(tài)的需求是高級需求的示例。通過代碼跟蹤執(zhí)行路徑以確保正確解釋每個需求是檢查正確實現的一種非常好的方法。

功能安全標準將此擴展到需求可追溯性的概念。他們經常要求用戶從高級需求中執(zhí)行所有代碼，并通過低級測試解釋和測試任何未發(fā)現的案例。最近，網絡安全中的“左移”范式呼應了這一信息，如圖 1 中的 V 模型所示。

圖 1. 顧名思義，V-model 體現了一個產品開發(fā)過程，該過程顯示了每個開發(fā)階段的測試規(guī)范之間的聯系。資料來源：LDRA

測試組件，然后測試系統

在任何工程學科中，重要的是要確保組件在集成到系統之前自行正常工作。要將這種思想應用于軟件，工程師需要定義較低級別的需求，并確保每個功能和功能集發(fā)揮作用。工程師還需要確保他們?yōu)橄到y的其余部分提供適當的接口。

單元測試涉及在功能和模塊級別對輸入和輸出進行參數化，執(zhí)行審查以確保輸入和輸出之間的連接正確并遵循覆蓋范圍內的邏輯。單元測試工具可以提供經過驗證的測試工具和圖形表示，將各個輸入和輸出連接到執(zhí)行路徑，并使其正確性得到驗證。

在功能和模塊級別上理解接口也很重要。靜態(tài)分析工具可以展示這些接口，連接不同層次的邏輯。

盡早發(fā)現問題

任何學科的工程師都會告訴你，越早發(fā)現問題，解決問題的成本就越低。

靜態(tài)分析執(zhí)行源代碼分析以模擬系統的執(zhí)行而不實際運行它。編寫代碼后立即可用，靜態(tài)分析可以幫助開發(fā)人員最大限度地提高代碼的清晰度、可維護性和可測試性。靜態(tài)分析工具的主要特點包括：

代碼復雜性分析：了解您的代碼在哪里不必要地復雜，因此工程師可以執(zhí)行適當的緩解活動。

程序流程分析：繪制程序執(zhí)行的設計審查流程圖，以確保程序按預期流程執(zhí)行。

預測性運行時錯誤檢測：通過盡可能多的可執(zhí)行路徑對代碼執(zhí)行進行建模，并尋找潛在的錯誤，例如數組邊界溢出和被零除。

遵守編碼標準：通常選擇編碼標準以確保關注網絡安全、功能安全，或者在 MISRA 標準的情況下，選擇其中之一或兩者兼而有之。編碼標準有助于確保代碼符合最佳編程實踐，無論應用程序如何，這無疑都是一個好主意。

圖 2. 像靜態(tài)分析這樣的活動在開發(fā)生命周期的早期是一種開銷，但從長遠來看它們會帶來好處。資料來源：LDRA

開發(fā)足夠質量的代碼

質量更高的工程產品價格更高也就不足為奇了。堅持任何開發(fā)過程都是有代價的，開發(fā)最好的產品可能并不總是在商業(yè)上可行。

在安全很重要的情況下，功能安全標準通常需要對成本和故障概率進行分析。每個系統、子系統和組件都需要進行這種風險評估，以確保執(zhí)行相應的緩解活動。無論系統是安全關鍵還是安全關鍵，同樣的原則都是有意義的。如果您以相同的嚴格程度測試系統的每個部分，您將過度投資于風險較低的系統部分，而無法充分緩解風險較高的故障。

軟件安全實踐首先要了解如果組件或系統發(fā)生故障會發(fā)生什么，然后將潛在故障跟蹤到適當的活動中以降低這樣做的風險。例如，考慮一個控制飛機引導的系統，該系統的故障可能是災難性的。必須在子條件覆蓋級別執(zhí)行嚴格的緩解活動，以確保正確的代碼生成。

與機上娛樂系統形成鮮明對比。如果該系統出現故障，飛機不會墜毀，因此測試機上娛樂系統的要求低于可能立即造成人員傷亡的系統。

軟件的延展性既是福也是禍。它使系統在合理范圍內幾乎可以做任何事情變得非常容易。但是，在確保軟件不會失敗時，同樣的靈活性也可能成為致命弱點。

即使在商業(yè)世界中，雖然并非所有軟件故障都是災難性的，但它們絕不是可取的。許多開發(fā)人員在對安全和安保至關重要的行業(yè)工作，別無選擇，只能遵守最嚴格的標準。但是這些標準所提倡的原則是存在的，因為它們已被證明可以使最終的產品功能更好。因此，無論應用程序有多重要，以適當的方式采用這些原則都是完全有意義的。

盡管適用于軟件開發(fā)的功能安全和安全標準令人困惑，但它們之間的相似之處遠多于差異。所有這些都基于這樣一個事實，即軟件開發(fā)是一門工程學科，要求我們建立需求、設計和開發(fā)以實現它們，并針對需求進行早期測試。

采用這種思維方式將為整個行業(yè)的支持工具打開大門，從而更有效地開發(fā)更高質量的軟件。

LDRA Software Technology的技術專家 Mark Pitchford與開發(fā)團隊合作，希望在安全和安保關鍵環(huán)境中實現合規(guī)的軟件開發(fā)。

審核編輯 黃昊宇