基于Testbed的車載ECU軟件集成測試方法研究

01 車載軟件集成測試

1.1 軟件集成測試概述

集成測試可以脫離外部物理環境來驗證代碼內部功能邏輯，其測試對象為軟件的功能模塊（函數單元），目的是檢驗軟件模塊實現的正確性以及模塊之間交互的正確性。執行集成測試需要動態運行代碼，監測函數模塊之間的調用關系、控制流、數據流等，主要測試指標包括函數覆蓋率、調用覆蓋率、語句覆蓋率和分支覆蓋率等[6]。其中，函數調用覆蓋率（Function Coverage）是已執行的軟件函數的百分比，調用覆蓋率（Call Coverage）是文件中函數調用次數的百分比。

1.2 基于需求的集成測試方案

結構覆蓋率只能表明軟件有無死循環、不可達代碼以及分支進入條件錯誤等結構性問題，若要發現與具體使用場景相關的功能問題，需開展更深層次的測試。根據《道路車輛 功能安全 第6部分：產品開發 硬件層面》（ISO 26262-6－2018）（下文簡稱“標準”）相關要求，軟件集成測試包含基于需求的測試、接口測試和故障注入測試等[7]。

本文在傳統結構覆蓋率基礎上設計了一種新的測試方案，即基于需求的集成測試。該方案同時關注代碼結構覆蓋率和需求覆蓋率，完整測試過程如下：

1.基于需求的功能劃分

基于需求的集成測試，首先要根據軟件架構設計說明書劃分功能層級。車載軟件迭代速度快，效率優先，所以適合用廣度優先自頂向下集成測試法[8]，自然地做到逐步求精，在測試初期，測試者就看到系統功能的整體框架。

2.確定集成路徑深度

為避免因路徑深度不同導致的多個入口函數的產生，需要根據所劃分的功能模塊和集成策略確定每個功能模塊的入口函數。如果選擇自頂向下的測試策略，那么入口函數則選擇功能模塊的頂層函數。

3.設計測試用例

基于需求的集成測試，所有測試用例必須能完整覆蓋軟件需求中的功能項，并且測試用例與功能項（測試需求）之間必須建立追溯關系。

4.設計測試參數

測試用例設計完成后，要通過對代碼中全局變量和函數實參賦值來動態運行。所以，合理設計參數后，用例可以沿著不同的調用路徑執行代碼，最終實現全路徑覆蓋。

5.分析代碼執行路徑

測試用例執行完成后，需要通過分析數據判斷軟件需求是否被驗證。除了函數覆蓋率及調用覆蓋率，基于需求的集成測試還需通過函數語句的被執行次數來驗證測試用例是否執行了期望的調用路徑。

02 應用案例

本章節以乘用車拖車控制器為例，驗證基于需求的軟件集成測試方案，測試工具為LDRA Testbed。拖車控制器安裝在前車上，用于控制電動拖車鉤伸縮、后車燈光等。其主要功能包括信號傳遞、電源管理、拖車鉤控制、燈光控制、剎車控制、倒車輔助等。

2.1 基于需求的功能劃分

本文將拖車控制器軟件功能劃分為四個層級，如圖1所示。拖車模式功能項作為頂層功能模塊，在此基礎上合并需求中的獨立條目，劃分第二層級的小功能項：模式連接檢測、拖車燈狀態檢測、拖車鉤堵轉報保護、拖車鉤防夾；第三層級以同類型的多個操作項作為一個任務集合；第四層級參照實車測試，以能夠組成一個獨立可觀測的行為作為最小顆粒度功能。本文選擇燈光控制相關的五個功能場景開展測試，并且將根據上述功能層級劃分情況設計具體的測試用例。

圖1  拖車控制器軟件功能層級劃分圖

2.2 確定集成路徑深度

依據功能劃分層級，本案例設計最大集成深度為四層。若調用路徑超過四層，則在調用路徑頂部及中間各設置一個入口函數，疊加測試。

1.分析任務調用關系

為了將基于需求的功能模塊映射到程序中，需要明確任務調用關系。拖車控制器軟件中主要包含兩個并行線程：人機交互（Human-Machine Interaction, HMI）任務線程和燈光線程。其中，HMI任務線程負責拖車模式判斷和燈光同步，燈光線程負責燈光自檢。具體運行過程如圖2所示，HMI任務線程通過掃描接口連接事件判斷是否進入拖車模式，并在獲取到進入拖車模式事件后發出“進入拖車模式標志位”；燈光線程掃描到該標志位后立即開始燈光自檢任務，并在自檢完成后發出“燈光自檢完成標志位”；當HMI任務線程掃描到該標志，則進入燈光同步任務。

圖2  拖車控制器模塊功能任務交互

兩個線程獨立運行，通過在同一全局變量數據流上獲取不同時段的值，形成任務優先次序。由于函數之間沒有直接調用關系，所以這里依據線程將拖車控制器劃分為兩大功能模塊，并分別使HMIMain和LightMain作為兩個模塊的入口函數，如圖3所示。

圖3  頂層任務調用關系

2.設計模塊執行路徑

測試用例覆蓋的代碼范圍為測試路徑，在測試初期需要對測試路徑進行設計，并在測試用例執行結束后基于期望結果驗證路徑的準確性。拖車控制器軟件包括與硬件相關的驅動層程序以及與控制邏輯相關的應用層程序。本節測試路徑設計將按照2.1章節中劃分的功能模塊，對應用層程序進行集成測試，這里將與硬件相關的信號獲取函數與信號值設置函數全部打樁處理。

燈光同步任務與轉向燈、制動燈、位置燈、后霧燈和倒車燈等5個燈光模塊相關，且均被拖車燈光事件掃描函數ScanTrailerLightEvent調用。所以本文將ScanTrailerLightEvent函數作為燈光同步的公共入口函數，測試某個燈光模塊時將其余四個模塊被調函數全部打樁。以后霧燈燈光同步模塊測試為例，為了層層調用相關函數執行測試，在Testbed軟件中對掃描后霧燈光事件函數ScanTrailerLightBFogLightEvent、打開拖車燈動作函數OpenTrailerLight以及燈光控制邏輯函數CtrlTrailerLight均不打樁，最終通過ExecuteCMD函數調用不同參數來實現燈光點亮和熄滅。通過分析確定了后霧燈模塊主要的調用路徑，同時也是功能是否被成功實現的觀測路徑，如圖4所示。

圖4  后霧燈同步模塊函數調用關系

2.3 設計測試用例

本節根據標準中推薦的用例設計方法，設計拖車控制器軟件功能測試用例[9]，如表1所示。

表1  軟件集成測試的用例設計方法

注：ASIL（汽車安全完整性等級, Automotive Safety Integrity Level）；“++”表示該方法強烈推薦用于已識別的ASIL等級；“+”表示該方法推薦用于已識別的ASIL等級。

按照表1用例設計方法，對每個功能需求進行層次性的場景分解，直至將所有功能需求用條目化方式羅列出來。軟件需求中后霧燈燈光同步的控制邏輯如圖5所示。

圖5  后霧燈燈光同步邏輯

通過分析后霧燈同步的軟件需求，形成5條測試需求（tr）：

tr1：燈光自檢未完成，不能進入燈光同步；

tr2：燈光自檢完成，拖車控制器收到左車身控制器的后霧燈點亮報文，控制拖車后霧燈點亮；

tr3：燈光自檢完成，拖車控制器收到左車身控制器的后霧燈熄滅報文，控制拖車后霧燈熄滅；

tr4：燈光自檢完成，拖車控制器收到來自左車身控制器的后霧燈無效報文，保持上一狀態；

tr5：燈光自檢完成，拖車控制器未收到來自左車身控制器的后霧燈報文，控制后霧燈保持上一狀態。

設計5條測試用例（tc），分別驗證以上5條測試需求：

tc1：驗證首次自檢未完成不能執行燈光同步；

tc2：驗證正常點亮后霧燈；

tc3：驗證正常熄滅后霧燈；

tc4：驗證點亮狀態收到無效報文保持點亮；

tc5：驗證點亮狀態左域控制器掉線，控制后霧燈保持點亮。

以上5條用例，覆蓋了后霧燈燈光同步的所有測試需求，對需求的覆蓋率100%。其中tc5屬于故障注入測試。軟件需求項分別與測試需求、測試用例之間形成一對一、一對多的關系，所建立的測試用例追溯關系如表2所示。

表2  測試用例追溯關系

2.4 設計測試參數

本節將詳細介紹在Testbed軟件中如何設計tc5用例的參數：

步驟1：點亮后霧燈；

步驟2：設置左域控制器斷線故障；

步驟3：發送熄滅后霧燈指令。

根據以上步驟，需要同一測試用例連續運行兩次：第一次左域控制器信號正常，向拖車控制器發送點亮指令（Light_On）；第二次左域控制器信號故障，向拖車控制器發送熄滅指令（Light_ Off）。具體參數設計如表3所示。

表3  tc5對應參數列表

完成測試用例參數設計后，于Testbed軟件中進行相關配置：新建測試用例，設置用例重復執行次數“Number of Repetitions=2”；在“Variable I/O View”界面輸入全局變量的值；在樁函數管理界面中輸入信號采集函數SigMgrGetSig的返回值和函數實參的值。完成以上參數設置，一個可執行的測試用例則設計完成。

2.5 用例執行及執行路徑的分析

用例參數設置完成后，從入口函數開始執行。根據本章2.2節中設定的路徑，選定ExecuteCMD函數作為最終觀測點。測試結果同時關注兩個條件，即結構覆蓋率完整和用例執行路徑正確。

2.5.1 結構覆蓋率分析

如圖4所示，后霧燈同步模塊涉及5個函數（置灰部分），其中ExecuteCMD函數位于驅動程序中，其余4個分布在LightTrailer.c文件中。

僅執行用例tc5之后，整個LightTrailer.c文件的調用覆蓋率為6%，調用次數為12，同一個函數在不同位置被重復調用，算多次調用；函數覆蓋率為12%，被調用的函數個數為4，即除了Excute-CMD以外其余4個函數都被調用。

通過調用覆蓋率、函數覆蓋率可以證明函數之間接口可以正常調用，沒有出現函數異常調用。當LightTrailer.c中所有功能執行完成后，調用覆蓋率和函數覆蓋率預期為100%。

2.5.2 需求覆蓋率分析

測試需求tr5是驗證點亮狀態后左域控制器掉線，控制后霧燈保持點亮。需要測試用例tc5連續運行兩次，兩次運行的執行路徑如圖6所示。

圖6  用例tc5執行路徑

用例執行第一次，左域控制器非掉線狀態，正常點亮后霧燈，所有函數均被調用。用例執行第二次，左域控制器掉線狀態，執行Scan Trailer- LightBFogLightEvent函數后因為故障，保持上一狀態。所以ScanTrailerLightEvent、ScanTrailerLight- BFogLightEvent函數預期執行2次，實際路徑追溯結果如圖7和圖8所示。

圖7  函數ScanTrailerLightEvent執行次數

圖8  函數ScanTrailerLightBFogLightEvent執行次數

CtrlTrailerLight函數的語句覆蓋報告如圖9所示，其實際執行次數為1次，符合預期結果。其中拖車后霧燈驅動開啟指令ExecuteCMD（0x2- 407010100000000）語句執行1次，拖車后霧燈驅動關閉指令ExecuteCMD （0x2407010000000000）語句執行0次。這表明左車身控制器斷線以后，控制后霧燈保持點亮，所以用例tc5執行結果符合預期，測試需求tr5驗證通過。當所有用例執行完成后，后霧燈燈光同步的控制邏輯這條軟件需求覆蓋率應該達到100%。

圖9  燈光控制邏輯執行結果

03 結束語

本文使用Testbed工具對拖車控制器軟件進行了基于需求的軟件集成測試。通過對軟件架構設計說明進行分析，完成了對功能模塊的拆解。進一步將功能模塊映射到軟件程序中，確定了測

試的期望路徑、入口函數和觀測點，完成對軟件代碼的模塊劃分。同時，在Testbed工具中建立測試用例，結合功能模塊合理設計參數，在代碼層面上實現了故障注入測試功能項的驗證。該方法不借助硬件環境，在軟件開發早期階段可以完成核心邏輯功能的測試，極大提升了軟件迭代效率，保障了項目交付進度。