隨著汽車嵌入式軟件功能的不斷疊加，軟件復(fù)雜性不斷提升，對(duì)汽車嵌入式軟件的安全性提出了更高要求，基于功能安全的嵌入式軟件開發(fā)和測試已成為汽車行業(yè)非常重要的流程標(biāo)準(zhǔn)。本文基于ISO 26262標(biāo)準(zhǔn)，對(duì)滿足功能安全ASIL等級(jí)的汽車嵌入式軟件單元驗(yàn)證技術(shù)進(jìn)行詳細(xì)介紹，從而提高軟件質(zhì)量，減少軟件安全隱患，對(duì)汽車嵌入式軟件開發(fā)和測試工作具有一定的指導(dǎo)意義。

1 研究背景

隨著汽車使用場景的增加和輔助駕駛功能的擴(kuò)展，汽車嵌入式軟件的集成度和復(fù)雜性也隨之增加，愈加龐大的軟件系統(tǒng)意味著存在更多難以發(fā)現(xiàn)的安全風(fēng)險(xiǎn)。傳統(tǒng)的軟件開發(fā)和測試流程難以滿足現(xiàn)階段對(duì)汽車軟件安全性的要求[1-3]。ISO 26262《道路車輛功能安全》國際標(biāo)準(zhǔn)是為滿足道路車輛上特定電子電器系統(tǒng)的需求而編寫，適用于道路車輛上特定的由電子、電氣和軟件組件組成的安全相關(guān)系統(tǒng)在安全生命周期內(nèi)的所有活動(dòng)，目前已成為非常前沿的汽車安全相關(guān)標(biāo)準(zhǔn)。其主要基于汽車電子行業(yè)公認(rèn)的“V模型”，強(qiáng)調(diào)通過各開發(fā)階段的測試和驗(yàn)證來降低風(fēng)險(xiǎn)[4-5]。

軟件單元驗(yàn)證作為軟件測試的第一道關(guān)卡，能夠盡早發(fā)現(xiàn)代碼漏洞、降低開發(fā)成本、縮短開發(fā)周期，能有效提高軟件質(zhì)量，是軟件測試中最重要的部分。基于功能安全的軟件單元驗(yàn)證是為了證明軟件最小單元滿足軟件設(shè)計(jì)，以及安全措施得到實(shí)施，并滿足根據(jù)所需ASIL等級(jí)分配的軟件要求而開展的活動(dòng)，兼顧軟件安全要求和非安全要求。為了保證驗(yàn)證的充分性和完整性，功能安全要求通過評(píng)審、分析和測試等組合方法對(duì)軟件進(jìn)行單元驗(yàn)證。

本文基于ISO 26262《道路車輛功能安全》國際標(biāo)準(zhǔn)第6部分第9章節(jié)“Software unit verification”中的要求，對(duì)符合功能安全的軟件單元驗(yàn)證技術(shù)進(jìn)行詳細(xì)研究，對(duì)汽車軟件開發(fā)和測試從業(yè)人員具有一定的參考意義。

2 軟件單元驗(yàn)證流程

軟件單元驗(yàn)證流程如圖1所示。按照靜態(tài)測試在先、動(dòng)態(tài)測試在后的準(zhǔn)則進(jìn)行，每一步都需要有上一步的輸出資料作為輸入，且上一步未評(píng)審?fù)ㄟ^不可進(jìn)入下一步，保證驗(yàn)證過程可靠且閉環(huán)。開始前，需要有《軟件單元設(shè)計(jì)規(guī)范》 《軟件接口規(guī)范》 《軟件開發(fā)環(huán)境文檔》等文檔作為驗(yàn)證過程的需求輸入。需要注意的是，功能安全側(cè)重于對(duì)活動(dòng)過程的檢查和確認(rèn)，因此對(duì)重要步驟的審查是非常有必要的。

圖1 軟件單元驗(yàn)證流程圖

2.1 編制和評(píng)審軟件單元測試計(jì)劃

測試負(fù)責(zé)人根據(jù)各模塊ASIL等級(jí)要求對(duì)單元測試的各項(xiàng)工作內(nèi)容編制單元測試計(jì)劃，規(guī)定時(shí)間進(jìn)度要求，確認(rèn)測試的范圍、方法、測試用例設(shè)計(jì)方法、覆蓋率要求等，輸出《軟件單元測試計(jì)劃》。測試小組內(nèi)部對(duì)《軟件單元測試計(jì)劃》內(nèi)的各項(xiàng)工作安排進(jìn)行評(píng)審，評(píng)審?fù)ㄟ^則開始靜態(tài)測試，若評(píng)審不通過，則修改計(jì)劃再次評(píng)審直到通過。

2.2 執(zhí)行和評(píng)審靜態(tài)測試

根據(jù)要求對(duì)模型或代碼執(zhí)行靜態(tài)測試，確認(rèn)對(duì)建模規(guī)范、編碼規(guī)范、軟件質(zhì)量度量以及相關(guān)文檔的符合性，記錄測試執(zhí)行結(jié)果并輸出《軟件單元驗(yàn)證靜態(tài)代碼分析報(bào)告》。對(duì)于需要修改的缺陷執(zhí)行缺陷修正，對(duì)于不需要修改的缺陷進(jìn)行分析說明。根據(jù)測試結(jié)果評(píng)審靜態(tài)測試是否通過，評(píng)審?fù)ㄟ^則進(jìn)行動(dòng)態(tài)測試，若評(píng)審不通過，通知開發(fā)組修改代碼直到再次評(píng)審?fù)ㄟ^。

2.3 編制和評(píng)審軟件單元測試說明

測試工程師依據(jù)《軟件詳細(xì)設(shè)計(jì)說明》 《軟件單元驗(yàn)證測試策略》和ASIL等級(jí)要求編寫用例的ID、名稱、設(shè)計(jì)方法、預(yù)置條件、執(zhí)行步驟、預(yù)期結(jié)果、判斷準(zhǔn)則，輸出《軟件單元測試說明》，根據(jù)追溯一致性要求需要建立軟件詳細(xì)設(shè)計(jì)與軟件單元測試用例的追溯關(guān)系。評(píng)審小組評(píng)審?fù)ㄟ^，則開始執(zhí)行單元測試，若評(píng)審不通過，測試組修改測試用例直至再次評(píng)審?fù)ㄟ^。

2.4 執(zhí)行單元測試

測試工程師搭建測試環(huán)境并執(zhí)行軟件單元測試，測試覆蓋率需達(dá)到要求。若覆蓋率未達(dá)標(biāo)，測試發(fā)現(xiàn)缺陷，需按照《問題解決管理過程規(guī)范》流程執(zhí)行分析、處理。對(duì)測試用例未通過的情形，測試工程師根據(jù)策略執(zhí)行回歸測試并記錄結(jié)果。對(duì)不能通過測試驗(yàn)證的非功能需求，進(jìn)行評(píng)審或采用其他方法驗(yàn)證。依據(jù)測試記錄和結(jié)果輸出《軟件單元測試記錄》。

2.5 編制和評(píng)審軟件單元測試報(bào)告

測試工程師依據(jù)軟件單元測試記錄和結(jié)果，編制《軟件單元測試報(bào)告》。報(bào)告內(nèi)容主要包括：測試目標(biāo)、測試結(jié)果、結(jié)果分析、測試結(jié)論和意見。評(píng)審小組評(píng)審《軟件單元測試報(bào)告》，評(píng)審內(nèi)容主要包括：從技術(shù)角度檢查靜態(tài)驗(yàn)證、測試用例的執(zhí)行情況；確認(rèn)測試執(zhí)行符合策略要求；確保建立追溯關(guān)系的一致性。評(píng)審?fù)ㄟ^則結(jié)束軟件單元驗(yàn)證活動(dòng)。

3 軟件單元驗(yàn)證方法

表1列出了目前常用的軟件單元驗(yàn)證方法，大致可分為評(píng)審、分析、測試3大類，分別對(duì)應(yīng)1a-1c、1d-1i和1j-1n。標(biāo)準(zhǔn)要求通過這些方法的適當(dāng)組合，對(duì)軟件單元設(shè)計(jì)和已實(shí)現(xiàn)的軟件單元進(jìn)行驗(yàn)證，來證明軟件的功能和特性滿足軟件安全要求。不同ASIL等級(jí)對(duì)不同方法的推薦度不一樣，其中“++”為特別推薦，“+”為推薦，“o”為不推薦。為滿足單元驗(yàn)證的完整性和充分性，通常會(huì)在不同大類中選擇所有無重復(fù)項(xiàng)目的“++”項(xiàng)進(jìn)行組合測試。注意，如果代碼保留了模型特性，可以通過在模型層面執(zhí)行驗(yàn)證來替代在源碼層面執(zhí)行驗(yàn)證，但需要證明該模型具有足夠的置信度。

表1 軟件單元驗(yàn)證方法

以ASIL B等級(jí)為例，可選擇檢查+靜態(tài)代碼分析+基于需求的測試+接口測試方法進(jìn)行組合驗(yàn)證。

3.1 檢查

對(duì)開發(fā)文檔、代碼和設(shè)計(jì)的一致性、代碼執(zhí)行標(biāo)準(zhǔn)的情況、代碼邏輯表達(dá)的正確性、代碼結(jié)構(gòu)的合理性以及代碼的可讀性等進(jìn)行檢查。將所有與文檔和代碼相關(guān)的檢查項(xiàng)列舉在《軟件單元驗(yàn)證檢查審查單》中，根據(jù)檢查結(jié)果給予“通過”“建議”和“不通過”，審查通過率高于90%判定為通過。

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

在不運(yùn)行應(yīng)用程序的情況下,對(duì)軟件的源代碼的語義、結(jié)構(gòu)和行為進(jìn)行分析,由此找出程序中的不規(guī)范、不合理或者可能造成程序運(yùn)行異常的代碼。靜態(tài)代碼分析可借助軟件對(duì)源代碼進(jìn)行靜態(tài)分析。圖2為HelixQAC軟件對(duì)某代碼進(jìn)行靜態(tài)分析的結(jié)果示意圖，編碼規(guī)范遵守MISRA C++。

圖2 HelixQAC靜態(tài)分析結(jié)果

3.3 基于需求的測試

基于需求的測試是根據(jù)單元設(shè)計(jì)文檔提取明確要求進(jìn)行的測試活動(dòng)。通過分析各接口具有的意義、值的范圍及算法，確認(rèn)需求的輸入值和預(yù)期值，對(duì)單元代碼進(jìn)行測試，從而實(shí)現(xiàn)基于設(shè)計(jì)需求的單元測試。

3.4 接口測試

根據(jù)所測單元代碼被調(diào)用的輸入?yún)?shù)與該單元的形式參數(shù)在個(gè)數(shù)、屬性、量綱、順序上是否一致等方面設(shè)計(jì)測試用例進(jìn)行測試。

基于需求的測試和接口測試范圍存在重疊，通常以基于需求的測試為主，接口測試進(jìn)行查缺補(bǔ)漏。此過程需要根據(jù)軟件詳細(xì)設(shè)計(jì)文檔、安全需求文檔和接口文檔進(jìn)行測試用例設(shè)計(jì)，保證測試用例對(duì)功能、安全需求和接口的100%覆蓋。圖3為VectorCAST軟件對(duì)某源代碼進(jìn)行單元測試的結(jié)果示意圖，測試結(jié)果和預(yù)期結(jié)果一致，測試通過。

圖3 VectorCAST單元測試結(jié)果

4 軟件單元測試用例得出方法

標(biāo)準(zhǔn)要求使用表2列出的軟件單元測試用例得出方法。

表2 軟件單元測試用例得出方法

1） 需求分析法。根據(jù)《軟件詳細(xì)設(shè)計(jì)文檔》中的功能描述來設(shè)計(jì)測試用例，每一個(gè)測試用例用來檢驗(yàn)一個(gè)或者多個(gè)測試需求。每個(gè)測試用例需要與測試需求編號(hào)一一對(duì)應(yīng)形成追溯關(guān)系，需求覆蓋率需要達(dá)到100%。所有功能安全等級(jí)均要求使用此方法。

2） 等價(jià)類劃分法。根據(jù)被測函數(shù)的輸入、輸出范圍劃分有效等價(jià)類和無效等價(jià)類。針對(duì)每一個(gè)等價(jià)類設(shè)計(jì)至少一個(gè)有效等價(jià)類和一個(gè)無效等價(jià)類測試用例來確保被測程序單元的處理是完整的。此方法適用于具有取值范圍或值為個(gè)數(shù)的函數(shù)輸入單元。

3） 邊界值分析法。邊界值分析法使用與等價(jià)類劃分法相同的劃分，但是邊界值分析假定錯(cuò)誤更多地存在于兩個(gè)劃分的邊界上，需相應(yīng)地為邊界上及兩側(cè)的情況設(shè)計(jì)測試用例。此方法適用于對(duì)接口、接近邊界的值與邊界交叉的值較為敏感的函數(shù)單元。

4） 錯(cuò)誤推測法。根據(jù)以往測試經(jīng)驗(yàn)和其他一些測試技術(shù)，猜測錯(cuò)誤的類型及在特定的軟件中錯(cuò)誤發(fā)生的位置，并設(shè)計(jì)測試用例去發(fā)現(xiàn)它們。此方法適用于存在易錯(cuò)代碼的函數(shù)單元，通?；诮?jīng)驗(yàn)學(xué)習(xí)和專家判斷中收集的數(shù)據(jù)。

5 軟件單元層面結(jié)構(gòu)覆蓋率度量

對(duì)單元測試完整性的另一個(gè)重要評(píng)估標(biāo)準(zhǔn)是軟件單元層面的結(jié)構(gòu)覆蓋率要求，結(jié)構(gòu)覆蓋率分析可以發(fā)現(xiàn)測試用例的不足、需求的缺陷、無效代碼或非預(yù)期功能，因此標(biāo)準(zhǔn)要求按照表3列出的度量對(duì)結(jié)構(gòu)覆蓋率進(jìn)行測試。

表3 軟件單元層面結(jié)構(gòu)覆蓋率度量

1） 語句覆蓋率是指被測試到的語句數(shù)量/可執(zhí)行的語句總數(shù)×100%。

2） 分支覆蓋率是指被測試到的分支數(shù)量/總分支總數(shù)×100%。

3） MC/DC（修改條件/決策覆蓋率） 要求在一個(gè)程序中每一種輸入輸出至少出現(xiàn)一次，每一個(gè)判定中的每一個(gè)條件必須產(chǎn)生所有輸出結(jié)果至少一次，每一個(gè)判定必須產(chǎn)生所有可能的輸出結(jié)果至少一次，并且每一個(gè)判定中的每一個(gè)條件都能獨(dú)立影響一個(gè)判定結(jié)果，因此MC/DC是最可靠的覆蓋率。但由于其時(shí)間成本過高，目前只在功能安全要求最高的ASIL D中實(shí)施。實(shí)際進(jìn)行軟件單元測試用例設(shè)計(jì)時(shí)，可以將測試用例導(dǎo)出方法與MC/DC標(biāo)準(zhǔn)相結(jié)合，提高測試效率、測試力度和測試充分性。

當(dāng)軟件只需要滿足ASIL B等級(jí)時(shí)，選擇語句覆蓋和分支覆蓋并滿足覆蓋率要求即可。圖4為VectorCAST軟件對(duì)某源代碼進(jìn)行單元測試的覆蓋率統(tǒng)計(jì)結(jié)果。需要注意的是，無理由的覆蓋率無目標(biāo)值或低目標(biāo)值會(huì)被認(rèn)為不滿足功能安全要求。

圖4 VectorCAST單元測試覆蓋率統(tǒng)計(jì)結(jié)果

對(duì)于可接受的死代碼（用于調(diào)試的代碼） 或不同軟件配置的代碼區(qū)段，可以給出接受所達(dá)到的覆蓋率水平的理由，或使用補(bǔ)充方法（代碼走審查） 驗(yàn)證未被覆蓋的代碼。如果認(rèn)為已實(shí)現(xiàn)的結(jié)構(gòu)覆蓋率不充分，需要定義額外的測試用例或提供基于其他方法可補(bǔ)充覆蓋率以達(dá)到要求的理由，此部分證據(jù)可在《軟件單元驗(yàn)證測試報(bào)告》中提供。

6 結(jié)論

功能安全是當(dāng)下汽車軟件行業(yè)的主流趨勢，根據(jù)功能安全開發(fā)流程對(duì)汽車軟件進(jìn)行開發(fā)和測試可以大大提高軟件的質(zhì)量，減少軟件安全隱患，提升汽車核心競爭力。本文基于ISO 26262標(biāo)準(zhǔn)結(jié)合不同功能安全等級(jí)從軟件單元驗(yàn)證流程、軟件單元驗(yàn)證方法的選擇、軟件單元測試用例得出方法的選擇和使用以及軟件單元測試結(jié)構(gòu)覆蓋率度量4方面對(duì)滿足功能安全的汽車嵌入式軟件單元驗(yàn)證技術(shù)進(jìn)行了詳細(xì)闡述，對(duì)汽車嵌入式軟件開發(fā)和測試行業(yè)具有一定的指導(dǎo)意義。

審核編輯：湯梓紅