安全相關的軟體測試方法

作者：王順良 莎益博工程系統開發（上海）有限公司

在汽車、航空等安全相關的領域，不僅程式碼的體量越來越大，安全性監管也不斷提高，比如汽車行業出臺了ISO26262標準，航空業有DO-178標準等，對軟體設計、測試和驗證提出了全面、嚴格而且具體的要求。而企業的生存壓力要求新產品儘快投入市場，這無形中擠壓了裝置的設計和測試周期。基於模型的設計（MBD）正是在這種情況下出現的新方法，不僅加快了系統的開發，降低了維護成本，同時對測試手段，提出了新的要求。

軟體的測試，一般可以分為靜態測試和動態測試。靜態測試不執行程式，根據軟體的語句發現軟體在合規方面的缺陷，比如MISRA C對軟體的編寫，對語句的使用給出了非常具體的要求。靜態測試也可以根據軟體的邏輯關係，發現軟體可能存在的缺陷。動態測試是在軟體編譯完成後，利用測試用例來執行軟體，以達到測試目的。動態測試能夠直接考察軟體行為，判斷執行結果是否符合設計要求。動態測試是軟體釋出前最後的保障，其重要性不言而喻。

本文以汽車巡航系統為例，探討動態測試的方法。使用的模型如下圖_1和圖_2所示。

圖_1 巡航系統的模擬測試環境

圖_2 巡航系統控制器的Simul

ink模型

功能測試

軟體的設計是基於設計要求的，即軟體所需要實現的功能。所以軟體測試必須驗證軟體的輸入輸出等行為滿足設計要求的功能。對於一個控制系統，手工生成測試用例的難點是，設計要求所描述的狀態或場景，通常同時包含輸入和輸出，而且跟時序狀態有關。所以在自動化測試工具出現前，系統測試需要經驗豐富的工程師手動生成測試用例。

這是一個比較典型的設計要求：

在車速小於30km/h時，巡航系統應保持不工作狀態。

這是相對比較簡單的測試，要求測試工程師設計用例，尋找下面表示式的反例：

巡航系統已開啟 同時 巡航系統在工作狀態 同時 車輛的速度小於30km/h

而下面的功能需要系統在連續的3個時序上滿足特定的狀態：

當巡航系統在工作狀態，不能有連續3個時序，車輛速度和設定速度相差大於1mph。

這種在多個連續時序上滿足特定狀態的測試，有時候只需要複製滿足條件的第一個測試用例就能實現，而有時候並不這樣樂觀。

在上述兩種測試要求中，都用到了“巡航系統在工作狀態”，從圖_1可以看到，這個狀態是系統的輸出量，這就要求手工用例設計工程師，能夠從輸出量反推出一個或一組輸入（測試用例），來滿足“巡航系統在工作狀態”這樣的要求。

隨著系統越來越複雜，手工反推測試用例越來越困難。我們使用美國Reactive-Systems公司的Reactis產品，自動生成測試用例，取得了不錯的效果。

Reactis的驗證功能，使用User-Defined-Target（UDT）和Assertion（斷言）兩個模組來實現。

- UDT用來自動產生測試用例，使被測系統處於設計要求的場景或狀態下。

- Assertion用來發現違反設計要求的測試用例。

我們用上面提到的兩條設計要求為例，看看Reactis是如何實現自動測試的。

如果車速小於30km/h，巡航系統應保持不工作狀態。

對於比較簡單的設計要求，Reactis支援C語言來編寫UDT和Assertion。如下圖_3所示進入UDT和Assertion的設定介面。

圖_3 UDT的設定

從圖中ex

pression欄目可以看到，UDT的設定就是一句標準的C程式碼語句。對應的Assertion只需將ex

pression替換成：

！（（speed < 30） && active）

設定完成後，軟體介面上就會出現類似於瞄準鏡（UDT）和閃電（Assertion）的符號（如圖_7所示）。

當巡航系統在工作狀態，不能有連續3個時序，車輛速度和設定速度相差大於1mph。

對於比較複雜的功能，Reactis支援Simul

ink/Stateflow模型來定義UDT和Assertion。如圖_4所示。

圖_4 使用模型的UDT設定

圖_4的Library用於選擇一個包含UDT模型的Simul

ink檔案，而System在這個檔案中，選擇用於該測試的模型。下面的Inputs是做輸入關聯的，使驗證模型和被測模型的輸入一一對應。

Assertion的設定類似，圖_5是Assertion的Stateflow模型，用於計數有幾個連續時序發生速度偏差大於1mph，當發現有超過3個時序時報錯。在設定完成後，軟體介面上會出現帶框的瞄準鏡和閃電圖示（如圖_7所示）。

圖_5 Assertion模型

測試工程師完成上述設定後，就可以利用Reactis來自動生成測試用例，如圖_6所示。

圖_6 自動生成測試用例的設定

由於這裡只考慮UDT和Assertion，可以只選擇這兩項

Reactis仿照ISO26262的覆蓋度測試方法，把UDT和Assertion都看作是覆蓋度目標。UDT是否覆蓋表示設計要求的場景或狀態的測試用例是否存在，而Assertion是否覆蓋表示在設計要求的場景或狀態下，違犯設計要求的反例是否找到。

在生成測試用例後，會報告是否找到違反設計要求（Assertion）的情況。這時需要注意，只有在UDT實現覆蓋，即找到滿足設計要求所需要的場景和狀態的情況下，Assertion的報告才是有效的。測試工程師可根據Reactis所報告的，發生違反設計要求的這個測試用例，對模型進行除錯，發行軟體的缺陷。

圖_7 Reactis報告違反設計要求的測試用例

安全測試

ISO26262標準中與軟體測試相關的內容，主要定義在ISO26262-6檔案中，如圖_8所示。

圖_8 與軟體相關的ISO26262

ISO26262從三方面來定義系統的危害：

- 傷害的嚴重性，從S0（無傷害）到S3（危及生命）

- 暴露在危險中的可能性，從E1（幾乎不可能）到E4（可能性高）

- 可控性，從C0（通常可控）到C3（幾乎不可控）

將上述三方面綜合起來，就可以得到ASIL安全等級，從A（安全危險最低）到D（安全危險最高）。對於系統測試的每一個方面（測試目標），ISO26262用符號表示對於不同安全等級適用性：

“++” 表示高度推薦。

“+” 表示推薦。

“o” 表示不推薦或不相關。

對於測試工程師來說，ISO26262-6-9的單元測試和ISO26262-6-10整合測試是最相關的部分，圖_9是我們總結的測試要點。

圖_9 ISO26262-6-9和6-10的測試要點

基於設計要求的測試，在前一節已經作了簡要說明，下面就9。4。5和10。4。6的要求，作進一步解釋。

圖_10 ISO26262-6-9。4。5單元測試要求

圖_11 ISO26262-6-10。4。6整合測試要求

從ISO26262-6-9。4。5可以看到，覆蓋度測試，包括語句、分支和MC/DC應該在單元測試階段得到滿足。同樣，ISO26262-6-10。4。6指出，函式和呼叫的覆蓋度測試的重要性。如果未能滿足這些覆蓋度測試要求，應增加測試用例來滿足，或說明原因。

功能測試是ISO26262的組成部分，但功能測試只是包含了設計要求所例舉的一些場景，與9。4。5和10。4。6所要求的覆蓋度測試，側重點不同。功能測試所生成的測試用例，通常達不到覆蓋度測試的要求。而覆蓋度測試並不關心繫統功能，不能驗證系統是否滿足設計要求。

為了進行覆蓋度測試，我們依然選擇美國Reactive-Systems公司的Reactis軟體。行業內也有不少其他軟體可以實現同樣的功能，我們認為Reactis的操作比較直觀，功能完整（支援基於S-Function的C程式碼白盒子測試），自動生成的測試用例效率比較高，並集成了除錯功能。

使用Reactis實現覆蓋度測試非常方便直接：

- 載入被測模型

- 定義輸入變數的取值範圍

- 如果需要對S-Function的C程式碼進行白盒子測試，只需右鍵點選S-Function模組，設定所包含的C程式碼原始檔。

- 對於不需要考慮覆蓋度的節點，比如S-Function的封裝程式碼等，設定不需要覆蓋。

- 鉤選ISO26262-6-9和6-10所要求的測試目標，及其它關心的目標。

- 點選生成。

從圖_6可以看到，Reactis提供了多種覆蓋度目標，不僅包含ISO26262-6-9和6-10所要求的語句、分支、MC/DC、函式，以及呼叫等目標，還包括一些使用者可能關心的目標。比如“CSEPT”用來對Stateflow進行測試，當主狀態切換時，考察子狀態是否退出。

使用Reactis的報告功能，可以很方便的檢視各測試目標的覆蓋度和總體覆蓋度。如圖_12所示。

圖_12 測試用例的覆蓋度報告

提高覆蓋度

雖然藉助測試工具軟體可以自動產生測試用例，但是完全依賴工具達到ISO26262要求的覆蓋度也不太可能，或者需要一些技巧。所以，如何提高覆蓋度，就成為測試工程師新的課題。

從本文的功能測試部分可以看到，Reactis把功能測試也看作覆蓋度目標來自動生成測試用例，可謂一切皆覆蓋。所以，Reactis在提高覆蓋度方面，提供了一些實用的手段。

輸入量取值範圍的精確設定

由於軟體中包含大量的條件判斷語句，這些語句對輸入量的取值非常敏感，過於寬鬆的輸入值範圍，將使得自動搜尋測試用例變得非常困難，而不恰當的輸入值設定，會使得搜尋演算法根本找不到能夠覆蓋的用例。所以，測試工程師在匯入模型後，必須對每一個變數，根據實際的可能性進行設定。圖_13是Reactis提供的輸入值設定視窗，可以看到Reactis提供了豐富的設定方式，滿足各種型別的取值需求。

圖_13 輸入取值範圍的設定

利用已知測試用例

在很多情況下，我們已經有了一個測試用例的子集，比如實現功能測試的用例，我們希望擴充這個子集，來覆蓋ISO26262的安全性測試要求。如圖_14所示，Reactis提供了“Preload Files”功能，讓使用者將這個子集預先匯入到軟體中，當自動生成的測試用例跟子集中的測試用例重複時，可以使用“Prune”選項告訴Reactis是否可以剪下子集中的測試用例。

圖_14 自動生成測試用例

聚焦覆蓋度目標

當已有測試用例在某個或某些目標的測試方面表現不佳時，可以針對這些覆蓋度目標進行測試用例的生成。如圖_14所示，在“Coverage Objectives”欄目，可以僅僅選擇需要聚焦的覆蓋度目標。

使用UDT來實現覆蓋

在本文的功能測試部分已經提到UDT測試。在那裡，UDT主要是為了尋找設計要求的場景或狀態，一般與Assertion配合使用。事實上UDT也可以單獨用於覆蓋度的測試。對於比較複雜的邏輯，比如涉及較長的連續時序，預設的設定很難發現有效的測試用例。這時必須明確告訴工具軟體去關注這種需求。在這種情況下，就可以使用UDT來達到自動生成測試用例的目的。

結語

安全相關的控制系統測試，不僅需要滿足功能驗證的要求，還需要滿足行業的安全規範。由於測試的要求，不僅涉及輸入量，還需要同時考慮輸出量、系統狀態、時序、以及覆蓋目標，給測試工程師提出了很高的挑戰。本文以Reactis工具為例，透過使用自動化測試工具，工程師只需要從設計要求和安全要求出發，編制測試模型或測試條件，就能讓工具自動產生高效的測試用例，滿足功能和安全性的測試要求。

https：//www。auto-testing。net/news/show-108807。html