基于功能安全的汽車嵌入式軟件單元驗證技術研究

肖 蕾， 盧 倩， 冉毅德， 覃高峰

（上汽通用五菱汽車股份有限公司， 廣西 柳州 545007）

1 研究背景

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

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

本文基于ISO 26262《道路車輛功能安全》國際標準第6部分第9章節“Software unit verification”中的要求，對符合功能安全的軟件單元驗證技術進行詳細研究，對汽車軟件開發和測試從業人員具有一定的參考意義。

2 軟件單元驗證流程

軟件單元驗證流程如圖1所示。按照靜態測試在先、動態測試在后的準則進行，每一步都需要有上一步的輸出資料作為輸入，且上一步未評審通過不可進入下一步，保證驗證過程可靠且閉環。開始前，需要有《軟件單元設計規范》 《軟件接口規范》 《軟件開發環境文檔》等文檔作為驗證過程的需求輸入。需要注意的是，功能安全側重于對活動過程的檢查和確認，因此對重要步驟的審查是非常有必要的。

圖1 軟件單元驗證流程圖

2.1 編制和評審軟件單元測試計劃

測試負責人根據各模塊ASIL等級要求對單元測試的各項工作內容編制單元測試計劃，規定時間進度要求，確認測試的范圍、方法、測試用例設計方法、覆蓋率要求等，輸出《軟件單元測試計劃》。測試小組內部對《軟件單元測試計劃》內的各項工作安排進行評審，評審通過則開始靜態測試，若評審不通過，則修改計劃再次評審直到通過。

2.2 執行和評審靜態測試

根據要求對模型或代碼執行靜態測試，確認對建模規范、編碼規范、軟件質量度量以及相關文檔的符合性，記錄測試執行結果并輸出《軟件單元驗證靜態代碼分析報告》。對于需要修改的缺陷執行缺陷修正，對于不需要修改的缺陷進行分析說明。根據測試結果評審靜態測試是否通過，評審通過則進行動態測試，若評審不通過，通知開發組修改代碼直到再次評審通過。

2.3 編制和評審軟件單元測試說明

測試工程師依據《軟件詳細設計說明》 《軟件單元驗證測試策略》和ASIL等級要求編寫用例的ID、名稱、設計方法、預置條件、執行步驟、預期結果、判斷準則，輸出《軟件單元測試說明》，根據追溯一致性要求需要建立軟件詳細設計與軟件單元測試用例的追溯關系。評審小組評審通過，則開始執行單元測試，若評審不通過，測試組修改測試用例直至再次評審通過。

2.4 執行單元測試

測試工程師搭建測試環境并執行軟件單元測試，測試覆蓋率需達到要求。若覆蓋率未達標，測試發現缺陷，需按照《問題解決管理過程規范》流程執行分析、處理。對測試用例未通過的情形，測試工程師根據策略執行回歸測試并記錄結果。對不能通過測試驗證的非功能需求，進行評審或采用其他方法驗證。依據測試記錄和結果輸出《軟件單元測試記錄》。

2.5 編制和評審軟件單元測試報告

測試工程師依據軟件單元測試記錄和結果，編制《軟件單元測試報告》。報告內容主要包括：測試目標、測試結果、結果分析、測試結論和意見。評審小組評審《軟件單元測試報告》，評審內容主要包括：從技術角度檢查靜態驗證、測試用例的執行情況；確認測試執行符合策略要求；確保建立追溯關系的一致性。評審通過則結束軟件單元驗證活動。

3 軟件單元驗證方法

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

熒光淬滅常數可以通過Stern-Volner(SV)方程：I0/I =1 +KSV[Q],其中KSV是熒光淬滅常數,[Q]是被檢測物的濃度,I0和I分別是起始和加入懸浮物后懸浮液的熒光強度.對于2,4,6-三硝基苯酚,在低濃度范圍內配合物的SV曲線是線性的(R=0.991),且KSV為1.56×104(圖7),數值已與文獻報道的有機聚合物相當,鄭和根課題組鋅配合物的KSV為2.4×104[8],鎘配合物的KSV為6.4×103[9].高淬滅常數以及低檢測線可以很容易的檢測痕量的2,4,6-三硝基苯酚.

表1 軟件單元驗證方法

以ASIL B等級為例，可選擇檢查+靜態代碼分析+基于需求的測試+接口測試方法進行組合驗證。

3.1 檢查

對開發文檔、代碼和設計的一致性、代碼執行標準的情況、代碼邏輯表達的正確性、代碼結構的合理性以及代碼的可讀性等進行檢查。將所有與文檔和代碼相關的檢查項列舉在《軟件單元驗證檢查審查單》中，根據檢查結果給予“通過”“建議”和“不通過”，審查通過率高于90%判定為通過。

3.2 靜態代碼分析

在不運行應用程序的情況下,對軟件的源代碼的語義、結構和行為進行分析,由此找出程序中的不規范、不合理或者可能造成程序運行異常的代碼。靜態代碼分析可借助軟件對源代碼進行靜態分析。圖2為HelixQAC軟件對某代碼進行靜態分析的結果示意圖，編碼規范遵守MISRA C++。

圖2 HelixQAC靜態分析結果

3.3 基于需求的測試

基于需求的測試是根據單元設計文檔提取明確要求進行的測試活動。通過分析各接口具有的意義、值的范圍及算法，確認需求的輸入值和預期值，對單元代碼進行測試，從而實現基于設計需求的單元測試。

3.4 接口測試

根據所測單元代碼被調用的輸入參數與該單元的形式參數在個數、屬性、量綱、順序上是否一致等方面設計測試用例進行測試。

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

圖3 VectorCAST單元測試結果

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

標準要求使用表2列出的軟件單元測試用例得出方法。

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

1） 需求分析法。根據《軟件詳細設計文檔》中的功能描述來設計測試用例，每一個測試用例用來檢驗一個或者多個測試需求。每個測試用例需要與測試需求編號一一對應形成追溯關系，需求覆蓋率需要達到100%。所有功能安全等級均要求使用此方法。

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

3） 邊界值分析法。邊界值分析法使用與等價類劃分法相同的劃分，但是邊界值分析假定錯誤更多地存在于兩個劃分的邊界上，需相應地為邊界上及兩側的情況設計測試用例。此方法適用于對接口、接近邊界的值與邊界交叉的值較為敏感的函數單元。

4） 錯誤推測法。根據以往測試經驗和其他一些測試技術，猜測錯誤的類型及在特定的軟件中錯誤發生的位置，并設計測試用例去發現它們。此方法適用于存在易錯代碼的函數單元，通常基于經驗學習和專家判斷中收集的數據。

5 軟件單元層面結構覆蓋率度量

對單元測試完整性的另一個重要評估標準是軟件單元層面的結構覆蓋率要求，結構覆蓋率分析可以發現測試用例的不足、需求的缺陷、無效代碼或非預期功能，因此標準要求按照表3列出的度量對結構覆蓋率進行測試。

表3 軟件單元層面結構覆蓋率度量

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

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

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

當軟件只需要滿足ASIL B等級時，選擇語句覆蓋和分支覆蓋并滿足覆蓋率要求即可。圖4為VectorCAST軟件對某源代碼進行單元測試的覆蓋率統計結果。需要注意的是，無理由的覆蓋率無目標值或低目標值會被認為不滿足功能安全要求。

圖4 VectorCAST單元測試覆蓋率統計結果

對于可接受的死代碼（用于調試的代碼） 或不同軟件配置的代碼區段，可以給出接受所達到的覆蓋率水平的理由，或使用補充方法（代碼走審查） 驗證未被覆蓋的代碼。如果認為已實現的結構覆蓋率不充分，需要定義額外的測試用例或提供基于其他方法可補充覆蓋率以達到要求的理由，此部分證據可在《軟件單元驗證測試報告》中提供。

6 結論

功能安全是當下汽車軟件行業的主流趨勢，根據功能安全開發流程對汽車軟件進行開發和測試可以大大提高軟件的質量，減少軟件安全隱患，提升汽車核心競爭力。本文基于ISO 26262標準結合不同功能安全等級從軟件單元驗證流程、軟件單元驗證方法的選擇、軟件單元測試用例得出方法的選擇和使用以及軟件單元測試結構覆蓋率度量4方面對滿足功能安全的汽車嵌入式軟件單元驗證技術進行了詳細闡述，對汽車嵌入式軟件開發和測試行業具有一定的指導意義。