這篇文章簡單聊一聊汽車ECU軟件的測試。無論你是從事汽車軟件工程的哪一個職位，都應(yīng)該對軟件測試的基本概念和流程有一定的了解。所以我想感興趣的同學(xué)應(yīng)該會不少吧。
我們就以ISO26262軟件部分描述的V型開發(fā)流程為線索，舉一個實際例子來說明。

圖2. V型開發(fā)流程

1  先編一個需求

假設(shè)現(xiàn)在我寫了一個系統(tǒng)級的需求（System Requirement），也就是圖1里的“Technical Safety Concept”:

(這里多說一句和測試無關(guān)的話，所有的Techincal Safety Concept都是系統(tǒng)級需求，不是軟件需求，面試的時候別搞混了)

System Requirement

The Adaptive Cruise Control (ACC) function shall only be active when the ego-vehicle is traveling between 30kph and 120 kph.[ACC-SysReq 001]

once ACC deactivated, it cannot resume automatically.[ACC-SysReq 002]

這家車企比較慫，它的自適應(yīng)巡航功能只能在30公里到120公里每小時之間激活，并且一旦退出后不可再自動激活。

為了簡單起見，我們先不管第二條需求了，只看第一條。下面我把這個系統(tǒng)需求寫成軟件需求（Software Requirement）：

Software Requirement

The signal ACC Active State shall be set to READY if the following conditions are fulfilled[ACC-Req 001]:

•  Safe Vehicle Speed is greater or equal to 30kph AND

•  Safe Vehicle Speed is less than or equal to 120kph.

The signal ACC Active State shall be set to SUPPRESSED if the following conditions are fulfilled[ACC-Req 002]:

•  Safe Vehicle Speed is less than 30kph OR

•  Safe Vehicle Speed is greater than 120kph.

再接下來軟件設(shè)計文檔里， 也就是圖2的Architectual Design里可以寫：

Design Requirement

Acc_ActSt shall equal to READY if:

•  SafeVehSpd is greater or equal to 30kph AND

•  SafeVehSpd is less than or equal to 120kph.

Acc_ActSt shall equal to SUPPRESSEDif:

•  SafeVehSpd is less than 30kph OR

•  SafeVehSpd is greater than 120kph.

好了，這就是個最簡單的需求例子。根據(jù)這個需求，你寫了幾行代碼來實現(xiàn)。我們假設(shè)用C代碼，在原有的C文件acc.c中加入了：

if((SafeVehSpd >= 30) && (SafeVehSpd <= 120)){
Acc_ActSt = READY;
}
else if((SafeVehSpd < 30) || (SafeVehSpd > 120)){
Acc_ActSt = SUPPRESSED;
}
else{
}

有同學(xué)可能會說，你有病啊寫成這樣，第一個if語句寫完了直接寫else不就完了嘛。對， 但是我也不知道客戶以后會怎么改這個需求，也許會對其他速度段增加新的狀態(tài)，所以我就先寫個else if在這里，方便以后擴(kuò)展。

到這一步，"V"模型的左半邊你就做完了，現(xiàn)在我們開始來測試。

2  單元測試

寫完代碼編譯成功以后，先開始進(jìn)行單元測試，也就是圖中的“Software Unit Verification”。顧名思義，就是把你這個新編寫或者修改過的單元（單獨的C文件，在本例中是acc.c)與整個工程隔離開，單獨測試其輸入輸出。

圖3. 單元測試只關(guān)心某個具體的軟件單元

汽車行業(yè)呢，首先就是做MISRA 規(guī)則測試。MISRA 測試是靜態(tài)測試的一種，用來檢驗代碼是否符合一系列具體的編程規(guī)則。這里我們假設(shè)用的測試工具是QAC。

就我寫的這段，估計啊會報出一個warning, 因為 “else” 這個分枝事實上是無法觸發(fā)的，而MISRA的其中一個規(guī)則就是所有代碼都必須可觸發(fā)，所謂“Accessible”。當(dāng)然啦，這里我是有意為之，所以可以注釋一下就放過去了。

下一個步驟是動態(tài)測試，這里我們假設(shè)選用的工具是Polyspace。Polyspace可以幫助判斷算法在計算過程中，會不會產(chǎn)生諸如數(shù)組index超范圍、overflow、被除數(shù)是零之類的bug 。我們這個例子中只有邏輯判斷，所以其實不需要做動態(tài)測試。

接下來進(jìn)行功能測試。在功能測試中，我們要：

1. 分析待測單元有哪些輸入信號和輸出信號

2. 編寫一系列的輸入信號值，并同時寫出這些輸入信號值所對應(yīng)的正確的輸出信號值。我們把這個叫做“測試集”。

3. 以測試集中的輸入信號值為輸入，運行單元代碼。如果輸出信號的值和測試集中的正確輸出信號值相同，則功能測試通過。

編寫測試集的一個基本原則是要把所有的代碼都覆蓋到，并且盡量測試所有判斷邏輯。上面所示的例子非常簡單，只有一個輸入變量 SafeVehSpd 和一個輸出變量 Acc_ActSt。

我們需要把輸入變量按判斷邏輯分成若干個Equivalent Class 。在這個例子中，（假設(shè) SafeVehSpd 是 Unsigned int 型, 速度范圍的上限是500 kph）輸入信號SafeVehSpd 就可以分成三個 Equivalent Class:

a. [0, 30）
b. [30, 120]
c. (120,500]

于是在這三個Equivalent Class里隨機(jī)各取一個值，就能測試所有代碼邏輯了。但是實際測試中，我們往往還進(jìn)一步要求進(jìn)行邊界測試, 也就取每個Equivalent Class的兩端的值來進(jìn)行測試。這就涉及到精度問題了。假設(shè)這段代碼是定點運算，車速數(shù)值由10bit 表示，前述車速上限是500， 于是車速的精度就是 500/（2^10） = 0.48828125。

所以嚴(yán)格來說，測試集需要測試的輸入變量SafeVehSpd的值有6個，分別是 0 ，29.5117188 ，30 ， 120 ， 120.48828125 ， 500 。

當(dāng)然，現(xiàn)在很多工具支持自動生成測試集，所以不用程序員費勁巴力的去算這些破玩意兒了。

需要說明的是，就算進(jìn)行了完善的功能測試，也并不能保證功能就沒有bug....因為實際工程中中各種輸入信號的組合是無窮無盡的，再加上時序等等因素，功能測試不可能窮盡所有的實際情況，我們只是盡力而為。
汽車行業(yè)比較流行的單元測試工具有Cantata、VectorCAST 等等。

3  軟件集成測試

單元測試完成以后，就要把測試好的軟件單元放到整個工程里來測試。這一步對應(yīng)了圖1中的“software verification and integration"。

圖4.集成測試關(guān)注整個系統(tǒng)的輸入輸出

在單元測試中，我們通過直接改變SafeVehSpd 的值來進(jìn)行測試。而事實上，SafeVehSpd 數(shù)值的源頭，來自CAN 總線上的車輪輪速數(shù)據(jù)。

假設(shè)如圖3所示，從輪速傳感器，由CAN總線傳來的原始車輪輪速信號WheelSpdRaw 先經(jīng)過通信接口模塊 COM_IF.c處理 ，再經(jīng)過車速計算模塊VehSpd.c計算以后 ,才得到信號SafeVehSpd 。那么在集成測試中，我們需要通過更改WheelSpdRaw這個信號的數(shù)值來對acc.c中的代碼進(jìn)行測試。這是為了驗證acc.c模塊和其他模塊的接口是否正確以及各個模塊之間是否有沖突。

進(jìn)行軟件集成測試的時候，圖示的三個模塊其實合并在了一起形成了一個“黑盒”，我們只關(guān)心最初的輸入信號WheelSpdRaw 和最終的輸出信號Acc_ActSt 之間的邏輯。

在實際工程中，COM_IF.c、VehSpd.c 和 Acc.c 三個模塊很可能是由三個工程師在同時并行開發(fā)的，這就可能導(dǎo)致任何一個模塊單獨進(jìn)行集成測試都通過不了。這時候就需要由項目經(jīng)理或者product owner提前進(jìn)行溝通協(xié)調(diào)，確保所有功能都更新以后，三個模塊一起進(jìn)行集成測試。

軟件集成測試流行的工具和單元測試一樣， 也是Cantata之流。

軟件單元測試和軟件集成測試都可以被稱為軟件在環(huán)測試（Software in the loop , SIL)。

4  硬件在環(huán)測試（HIL）

軟件在環(huán)測試完成以后，下一個步驟就是硬件在環(huán)測試（Hardware in the loop, HIL），對應(yīng)了圖1中的 “Testing of embedded software”。有一些企業(yè)在HIL之前還會進(jìn)行一次PIL （Processor in the loop）測試，這里就不討論了。

HIL test也是集成測試的一種。前面說的軟件集成測試，是運行在PC 仿真環(huán)境中的，而實際ECU無論是算力、內(nèi)存、各種硬件性能等等方面和PC環(huán)境都有很大的不同，所以相同的功能還要繼續(xù)在實際硬件環(huán)境中再測試一遍。

也就是說，HIL test與軟件集成測試最大的不同在于，前者運行于實際硬件中，而后者只是運行在計算機(jī)仿真環(huán)境下。

硬件在環(huán)測試的主要工具是實際的零部件。比如測試ACC功能的話可以是ADAS控制器，或者是集成了ACC功能的毫米波雷達(dá)、攝像頭等。除此之外還要有一個實驗臺架提供必要的運行環(huán)境、電力供應(yīng)和總線接口。
常用的HIL test工具比如dspace的那些死貴死貴的測試環(huán)境，dspace control desk。

和軟件集成測試一樣，HIL test也是改變原始的CAN信號（例子中的WheelSpdRaw）來進(jìn)行測試，只不過，這一次不是直接改變WheelSpdRaw在內(nèi)存中的數(shù)值，而是通過HIL test 臺架真的向ECU通過CAN 發(fā)送真實的WheelSpdRaw信號。

HIL test的測試集，也就是測試用例（test case）需要和軟件需求 Software Requirement 嚴(yán)格對應(yīng)，可以是一對一，一對多或者多對一都可以。所有的 HIL test case 都必須根據(jù)一條對應(yīng)的Software Requirement 寫出，但是條件就沒有單元測試時候那么苛刻了。

比如為了測試需求ACC-Req 001，HIL test case 可以寫成：

•  Turn ECU on;
•  Set all wheel speed at 0;
•  Turn ACC function on;
•  Observe ACC status to be SUPPRESSED;
•  Gradually increase all wheel speed to 31 kph;
•  Observe ACC status change to READY after 30 kph;
•  Gradually increase all wheel speed to 121 kph;
•  Observe ACC status change to SUPPRESSED;
•  Gradually decrease all wheel speed to 119 kph;
•  Observe ACC status change to READY below 120 kph;
•  Gradually decrease all wheel speed to 29 kph;
•  Observe ACC status change to SUPPRESSED;
•  Turn ECU off.

需要把trigger和recover的情況都覆蓋到。事實上這個測試用例也可以用來測試ACC-Req 002， 這就是“一對多”的情況。