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

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

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

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

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

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

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

需求很重要

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

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

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

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

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

測試組件，然后測試系統(tǒng)

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

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

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

盡早發(fā)現(xiàn)問題

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

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

代碼復(fù)雜性分析：了解您的代碼在哪里不必要地復(fù)雜，因此工程師可以執(zhí)行適當?shù)木徑饣顒印?/p>

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

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

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

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

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

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

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

軟件安全實踐首先要了解如果組件或系統(tǒng)發(fā)生故障會發(fā)生什么，然后將潛在故障跟蹤到適當?shù)幕顒又幸越档瓦@樣做的風險。例如，考慮一個控制飛機引導(dǎo)的系統(tǒng)，該系統(tǒng)的故障可能是災(zāi)難性的。必須在子條件覆蓋級別執(zhí)行嚴格的緩解活動，以確保正確的代碼生成。

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

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

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

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

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

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

審核編輯 黃昊宇