近年來(lái)，智能網(wǎng)聯(lián)汽車(chē)行業(yè)已經(jīng)進(jìn)入飛速發(fā)展的軌道，“軟件定義汽車(chē)”已經(jīng)成為業(yè)內(nèi)人士的共識(shí)，同時(shí)也將面臨著功能安全、網(wǎng)絡(luò)安全等多重挑戰(zhàn)。本文通過(guò)對(duì)相關(guān)標(biāo)準(zhǔn)中測(cè)試要求的介紹，探討汽車(chē)功能安全測(cè)試的測(cè)試方法。

軟件安全測(cè)試內(nèi)容及方法

根據(jù)軟件開(kāi)發(fā)V模型，軟件安全詳細(xì)設(shè)計(jì)完成之后，需要進(jìn)行相應(yīng)的軟件驗(yàn)證，集成及測(cè)試等內(nèi)容，即V模型右邊內(nèi)容，具體包括：軟件單元測(cè)試，軟件集成和測(cè)試，軟件安全要求驗(yàn)證。具體如下圖所示：

軟件安全驗(yàn)證方法

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

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

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

? 靜態(tài)分析(Static Analysis)

? 動(dòng)態(tài)分析(Dynamic Analysis)

對(duì)于功能安全軟件安全測(cè)試、軟件單元驗(yàn)證、集成驗(yàn)證、嵌入式軟件驗(yàn)證對(duì)應(yīng)測(cè)試類(lèi)型如下：

?單元驗(yàn)證：靜態(tài)分析 + 動(dòng)態(tài)分析，靜態(tài)為主

? 集成驗(yàn)證：靜態(tài)分析 + 動(dòng)態(tài)分析，動(dòng)態(tài)為主

?嵌入式軟件驗(yàn)證：動(dòng)態(tài)分析

下面，對(duì)于靜態(tài)分析和動(dòng)態(tài)分析進(jìn)行詳細(xì)說(shuō)明：

靜態(tài)分析

靜態(tài)測(cè)試屬于最基本的測(cè)試，是指不用執(zhí)行程序的測(cè)試，它主要采取代碼走查、技術(shù)評(píng)審、代碼審查等方法對(duì)軟件產(chǎn)品進(jìn)行測(cè)試，主要包括以下內(nèi)容：

軟件/代碼是否滿(mǎn)足相關(guān)質(zhì)量標(biāo)準(zhǔn)？

─ 走查，結(jié)對(duì)編程，檢查

─ 控制流分析

─ 數(shù)據(jù)流分析

─ 靜態(tài)代碼分析

除不同類(lèi)型的人為分析檢查外，靜態(tài)分析最重要內(nèi)容為靜態(tài)代碼分析，主要目的是檢查代碼編寫(xiě)是否符合特定的編程規(guī)則。對(duì)于大部分車(chē)輛控制器代碼而言，靜態(tài)代碼分析，即C代碼靜態(tài)分析(如果基于模型開(kāi)發(fā)，則是自動(dòng)生成的代碼)，主要是保證代碼滿(mǎn)足MISRA C(Motor Industry Software Reliability Association, 汽車(chē)工業(yè)軟件可靠性協(xié)會(huì))相關(guān)的要求。

靜態(tài)代碼分析一般可以直接采用自動(dòng)化檢測(cè)軟件，例如SIMULINK、 Model Advisor; Vector、 VectorCAST; Perforce、Helix QAC等，通過(guò)配置代碼檢測(cè)規(guī)則，然后導(dǎo)入源文件進(jìn)行自動(dòng)化分析，如果不滿(mǎn)足相關(guān)要求，則需要對(duì)代碼進(jìn)行修改，直至滿(mǎn)足為止。

動(dòng)態(tài)分析

動(dòng)態(tài)分析是指實(shí)際運(yùn)行程序，并通過(guò)觀察程序運(yùn)行的實(shí)際結(jié)果來(lái)發(fā)現(xiàn)錯(cuò)誤的軟件測(cè)試技術(shù)，它包括了以下幾個(gè)方面：

①軟件/代碼是否做了它應(yīng)該做的?

─ 基于需求測(cè)試─ 接口測(cè)試─ 背靠背測(cè)試

②軟件/代碼是否做了它不應(yīng)該做的?

─ 魯棒性測(cè)試

③軟件/代碼是否足夠?

─ 結(jié)構(gòu)覆蓋性測(cè)試

重要的動(dòng)態(tài)測(cè)試包括：

【基于需求測(cè)試】

基于分配的安全需求和測(cè)試環(huán)境，制定安全測(cè)試用例，測(cè)試用例一般包括5個(gè)關(guān)鍵參數(shù)，即: 初始狀態(tài)或前提條件，數(shù)據(jù)設(shè)置、輸入、預(yù)期輸出、實(shí)際輸出。

【接口測(cè)試】

不同軟件層次接口，包括信號(hào)名稱(chēng)、數(shù)目、數(shù)據(jù)類(lèi)型、范圍測(cè)試。

【故障注入測(cè)試】

即魯棒性測(cè)試，故障注入測(cè)試主要目的是驗(yàn)證系統(tǒng)設(shè)計(jì)、軟件設(shè)計(jì)過(guò)程所提出安全機(jī)制或安全措施的有效性，通過(guò)在特定位置注入錯(cuò)誤，包括錯(cuò)誤的數(shù)值、方向、頻率等，對(duì)系統(tǒng)功能安全機(jī)制響應(yīng)時(shí)間、診斷覆蓋等內(nèi)容進(jìn)行驗(yàn)證。

【背靠背測(cè)試】

基于模型設(shè)計(jì)的測(cè)試，驗(yàn)證模型和生成的代碼的一致性，即采用相同的測(cè)試用例，同時(shí)輸入模型和生成的代碼進(jìn)行執(zhí)行，對(duì)二者輸出結(jié)果進(jìn)行比較，一致則通過(guò)，否則存在不一致。

除基本測(cè)試方法外，ISO 26262-6:2018對(duì)不同階段的軟件安全測(cè)試環(huán)境也有相應(yīng)的要求：

單元驗(yàn)證及集成驗(yàn)證：基于開(kāi)發(fā)環(huán)境的軟件測(cè)試，包括模型在環(huán)、軟件在環(huán)、處理器在環(huán)、硬件在環(huán)。

嵌入式軟件驗(yàn)證：硬件在環(huán)或車(chē)輛

我們的服務(wù)

廣電計(jì)量信息化服務(wù)事業(yè)部在汽車(chē)功能安全服務(wù)方面可提供相應(yīng)的培訓(xùn)、咨詢(xún)、認(rèn)證輔導(dǎo)服務(wù)。并且，可以基于汽車(chē)功能安全要求向整車(chē)企業(yè)及相關(guān)零部件企業(yè)提供完整的軟件評(píng)測(cè)服務(wù)。具體服務(wù)包括：