近年來，智能網聯汽車行業已經進入飛速發展的軌道，“軟件定義汽車"已經成為業內人士的共識，同時也將面臨著功能安全、網絡安全等多重挑戰。本文通過對相關標準中測試要求的介紹，探討汽車功能安全測試的測試方法。

軟件安全測試內容及方法

根據軟件開發V模型，軟件安全詳細設計完成之后，需要進行相應的軟件驗證，集成及測試等內容，即V模型右邊內容，具體包括：軟件單元測試，軟件集成和測試，軟件安全要求驗證。具體如下圖所示：

軟件安全驗證方法

ISO 26262-6:2018針對軟件單元驗證、集成驗證、嵌入式軟件驗證這三部分內容分別進行了闡述，并根據不同的ASIL等級對其驗證方法進行推薦：

上面列舉的三類測試，雖然它們屬于軟件開發V模型不同測試層級，但很多測試方法是共通的，例如基于需求的測試、接口測試、故障注入測試等等。

為更好地理解，我們可以從測試類型的角度，將以上測試方法分為：

• 靜態分析(Static Analysis)

• 動態分析(Dynamic Analysis)

對于功能安全軟件安全測試、軟件單元驗證、集成驗證、嵌入式軟件驗證對應測試類型如下：

• 單元驗證：靜態分析 + 動態分析，靜態為主

• 集成驗證：靜態分析 + 動態分析，動態為主

• 嵌入式軟件驗證：動態分析

下面，對于靜態分析和動態分析進行詳細說明：

靜態分析

靜態測試屬于最基本的測試，是指不用執行程序的測試，它主要采取代碼走查、技術評審、代碼審查等方法對軟件產品進行測試，主要包括以下內容：

軟件/代碼是否滿足相關質量標準？

─ 走查，結對編程，檢查

─ 控制流分析

─ 數據流分析

─ 靜態代碼分析

除不同類型的人為分析檢查外，靜態分析最重要內容為靜態代碼分析，主要目的是檢查代碼編寫是否符合特定的編程規則。對于大部分車輛控制器代碼而言，靜態代碼分析，即C代碼靜態分析(如果基于模型開發，則是自動生成的代碼)，主要是保證代碼滿足MISRA C(Motor Industry Software Reliability Association, 汽車工業軟件可靠性協會)相關的要求。

靜態代碼分析一般可以直接采用自動化檢測軟件，例如SIMULINK、 Model Advisor; Vector、 VectorCAST; Perforce、Helix QAC等，通過配置代碼檢測規則，然后導入源文件進行自動化分析，如果不滿足相關要求，則需要對代碼進行修改，直至滿足為止。

動態分析

動態分析是指實際運行程序，并通過觀察程序運行的實際結果來發現錯誤的軟件測試技術，它包括了以下幾個方面：

①軟件/代碼是否做了它應該做的?

─ 基于需求測試─ 接口測試─ 背靠背測試

②軟件/代碼是否做了它不應該做的?

─ 魯棒性測試

③軟件/代碼是否足夠?

─ 結構覆蓋性測試

重要的動態測試包括：

【基于需求測試】 

基于分配的安全需求和測試環境，制定安全測試用例，測試用例一般包括5個關鍵參數，即: 初始狀態或前提條件，數據設置、輸入、預期輸出、實際輸出。

【接口測試】     

不同軟件層次接口，包括信號名稱、數目、數據類型、范圍測試。

【故障注入測試】  

即魯棒性測試，故障注入測試主要目的是驗證系統設計、軟件設計過程所提出安全機制或安全措施的有效性，通過在特定位置注入錯誤，包括錯誤的數值、方向、頻率等，對系統功能安全機制響應時間、診斷覆蓋等內容進行驗證。

【背靠背測試】

基于模型設計的測試，驗證模型和生成的代碼的一致性，即采用相同的測試用例，同時輸入模型和生成的代碼進行執行，對二者輸出結果進行比較，一致則通過，否則存在不一致。

除基本測試方法外，ISO 26262-6:2018對不同階段的軟件安全測試環境也有相應的要求：

單元驗證及集成驗證：基于開發環境的軟件測試，包括模型在環、軟件在環、處理器在環、硬件在環。

嵌入式軟件驗證：硬件在環或車輛

我們的服務

廣電計量信息化服務事業部在汽車功能安全服務方面可提供相應的培訓、咨詢、認證輔導服務。并且，可以基于汽車功能安全要求向整車企業及相關零部件企業提供完整的軟件評測服務。具體服務包括：