嵌入式系統中的軟件測試很重要

2020-12-30

在嵌入式系統的世界中，不僅僅是繼續發(fā)展和發(fā)展的技術(shù)。用于開(kāi)發(fā)該技術(shù)的工具和方法正在日趨成熟和改進(jìn)。

在八十年代初期，一家小型計量公司開(kāi)發(fā)了軟件，將工程數學(xué)應用于坐標測量機（CMM）。但是開(kāi)發(fā)生命周期實(shí)質(zhì)上將生產(chǎn)軟件視為沙盒。將從生產(chǎn)代碼開(kāi)始，添加功能，執行一些相當基本的功能測試，然后進(jìn)行交付。

在這么小的公司中，工程團隊自然會(huì )包括軟件和硬件專(zhuān)家。事后看來(lái)，令人驚訝的是，盡管開(kāi)發(fā)的軟件確實(shí)需要廣泛的客戶(hù)支持，但對于所運行的硬件，卻幾乎沒(méi)有相同的消防文化。

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

軟硬件支持之間的部分差異是原始開(kāi)發(fā)過(guò)程的結果。但是，軟件的可擴展性和隨之而來(lái)的功能不斷增加的功能也起著(zhù)重要作用。簡(jiǎn)而言之，錯誤的方法比正確的方法要多得多，而且該特性要求將其視為工程學(xué)科。

這沒(méi)有什么新的。多年來(lái)，領(lǐng)先的航空，汽車(chē)和工業(yè)功能安全標準（例如DO-178，ISO 26262和IEC 61508）都要求這種方法。但是，要想從當今最先進(jìn)的開(kāi)發(fā)和測試工具中受益，擁有工程學(xué)科的思維定勢是至關(guān)重要的，這些工具旨在為這種方法提供服務(wù)。

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

要求事項

電氣系統設計通常從狀態(tài)機開(kāi)始，并且了解特定產(chǎn)品的不同操作模式。工程師通?？梢苑浅？焖?，輕松地將狀態(tài)機功能映射到邏輯。如果狀態(tài)機變得更加復雜，則通常將其轉換為軟件。

高水平的要求對于確保系統正常運行至關(guān)重要。這樣的需求表征了業(yè)務(wù)邏輯和預期的功能，并能夠評估系統是否按照預期的方式工作。最佳實(shí)踐遵循從高層需求到分析再到覆蓋的流程，自然而然，需求可追溯性工具就是為此而設計的。

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

功能安全標準將其擴展到需求可追溯性的概念。他們通常要求用戶(hù)根據高級要求來(lái)執行所有代碼，并通過(guò)低級測試來(lái)解釋和測試所有未發(fā)現的案例。最近，網(wǎng)絡(luò )安全中的“向左移動(dòng)”范式呼應了這一信息，如圖1所示的V模型。

測試組件，然后測試系統

在任何工程學(xué)科中，重要的是要確保組件在集成到系統中之前能夠獨立正常工作。要將這種思想應用于軟件，工程師需要定義較低級別的要求，并確保每個(gè)功能和功能集都在發(fā)揮作用。工程師還需要確保為系統的其余部分提供適當的接口。

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

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

盡早發(fā)現問(wèn)題

任何學(xué)科的工程師都會(huì )告訴您，發(fā)現問(wèn)題的時(shí)間越早，修復這些問(wèn)題的費用就越少。

靜態(tài)分析執行源代碼分析，以在不實(shí)際運行系統的情況下對系統的執行進(jìn)行建模。編寫(xiě)代碼后即可使用，靜態(tài)分析可幫助開(kāi)發(fā)人員最大程度地提高代碼的清晰度，可維護性和可測試性。靜態(tài)分析工具的主要功能包括：

代碼復雜度分析：了解代碼不必要的復雜之處，以便工程師可以執行適當的緩解活動(dòng)。

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

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

遵守編碼標準：通常選擇編碼標準以確保對網(wǎng)絡(luò )安全性，功能安全性的關(guān)注，或者就MISRA標準而言，選擇一種或兩種。編碼標準有助于確保代碼遵循最佳編程實(shí)踐，這與應用程序無(wú)關(guān)，無(wú)疑是個(gè)好主意。

圖2諸如靜態(tài)分析之類(lèi)的活動(dòng)是開(kāi)發(fā)生命周期早期的開(kāi)銷(xiāo)，但從長(cháng)遠來(lái)看，它們卻能帶來(lái)回報。

制定足夠質(zhì)量的代碼

高質(zhì)量的工程產(chǎn)品更昂貴也就不足為奇了。堅持任何開(kāi)發(fā)過(guò)程都需要付出一定的代價(jià)，并且開(kāi)發(fā)最好的產(chǎn)品可能并不總是在商業(yè)上可行。

在安全性很重要的地方，功能安全性標準通常需要分析成本和發(fā)生故障的可能性。每個(gè)系統，子系統和組件都需要進(jìn)行此風(fēng)險評估，以確保執行相應的緩解措施。無(wú)論系統對安全性至關(guān)重要還是對安全性至關(guān)重要，同樣的原理也是有意義的。如果您以相同的嚴格程度測試系統的每個(gè)部分，則會(huì )在風(fēng)險較低的系統部分中過(guò)度投資，而在風(fēng)險較高的情況下，將無(wú)法充分緩解故障。

軟件安全實(shí)踐首先要了解如果組件或系統出現故障會(huì )發(fā)生什么，然后將潛在的故障跟蹤到適當的活動(dòng)中以減輕這樣做的風(fēng)險。例如，考慮一個(gè)控制飛機引導的系統，該系統可能會(huì )導致災難性事故。必須在子條件覆蓋范圍內執行嚴格的緩解活動(dòng)，以確保正確生成代碼。

與機上娛樂(lè )系統進(jìn)行對比。如果該系統發(fā)生故障，飛機將不會(huì )墜毀，因此與可能立即造成生命損失的系統相比，測試機上娛樂(lè )系統的要求較低。

軟件的可塑性既是福也是禍。使系統幾乎可以在合理范圍內執行任何操作非常容易。但是，在確保軟件不會(huì )失敗時(shí)，同樣的靈活性也可能成為致命弱點(diǎn)。

即使在商業(yè)世界中，雖然并非所有軟件故障都是災難性的，但它們也不可取。許多開(kāi)發(fā)人員在對安全至關(guān)重要的行業(yè)中工作，除了遵守最嚴格的標準外別無(wú)選擇。但是這些標準所倡導的原理之所以存在，是因為已經(jīng)證明它們可以使最終產(chǎn)品發(fā)揮更好的功能。因此，無(wú)論應用程序有多重要，按比例采用這些原則是完全有意義的。

盡管適用于軟件開(kāi)發(fā)的功能安全標準過(guò)多，令人困惑，但它們之間的相似之處遠勝于區別。所有這些都是基于這樣一個(gè)事實(shí)，即軟件開(kāi)發(fā)是一門(mén)工程學(xué)科，要求我們建立需求，進(jìn)行設計和開(kāi)發(fā)以實(shí)現它們，并盡早對需求進(jìn)行測試。