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

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

1  先編一個(gè)需求

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

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

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]

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

為了簡(jiǎn)單起見(jiàn)，我們先不管第二條需求了，只看第一條。下面我把這個(gè)系統(tǒng)需求寫(xiě)成軟件需求（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.

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

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.

好了，這就是個(gè)最簡(jiǎn)單的需求例子。根據(jù)這個(gè)需求，你寫(xiě)了幾行代碼來(lái)實(shí)現(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é)可能會(huì)說(shuō)，你有病啊寫(xiě)成這樣，第一個(gè)if語(yǔ)句寫(xiě)完了直接寫(xiě)else不就完了嘛。對(duì)， 但是我也不知道客戶以后會(huì)怎么改這個(gè)需求，也許會(huì)對(duì)其他速度段增加新的狀態(tài)，所以我就先寫(xiě)個(gè)else if在這里，方便以后擴(kuò)展。

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

2  單元測(cè)試

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

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

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

就我寫(xiě)的這段，估計(jì)啊會(huì)報(bào)出一個(gè)warning, 因?yàn)?“else” 這個(gè)分枝事實(shí)上是無(wú)法觸發(fā)的，而MISRA的其中一個(gè)規(guī)則就是所有代碼都必須可觸發(fā)，所謂“Accessible”。當(dāng)然啦，這里我是有意為之，所以可以注釋一下就放過(guò)去了。

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

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

1. 分析待測(cè)單元有哪些輸入信號(hào)和輸出信號(hào)

2. 編寫(xiě)一系列的輸入信號(hào)值，并同時(shí)寫(xiě)出這些輸入信號(hào)值所對(duì)應(yīng)的正確的輸出信號(hào)值。我們把這個(gè)叫做“測(cè)試集”。

3. 以測(cè)試集中的輸入信號(hào)值為輸入，運(yùn)行單元代碼。如果輸出信號(hào)的值和測(cè)試集中的正確輸出信號(hào)值相同，則功能測(cè)試通過(guò)。

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

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

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

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

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

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

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

3  軟件集成測(cè)試

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

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

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

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

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

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

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

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

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

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

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

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

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

和軟件集成測(cè)試一樣，HIL test也是改變?cè)嫉腃AN信號(hào)（例子中的WheelSpdRaw）來(lái)進(jìn)行測(cè)試，只不過(guò)，這一次不是直接改變WheelSpdRaw在內(nèi)存中的數(shù)值，而是通過(guò)HIL test 臺(tái)架真的向ECU通過(guò)CAN 發(fā)送真實(shí)的WheelSpdRaw信號(hào)。

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

比如為了測(cè)試需求ACC-Req 001，HIL test case 可以寫(xiě)成：

•  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的情況都覆蓋到。事實(shí)上這個(gè)測(cè)試用例也可以用來(lái)測(cè)試ACC-Req 002， 這就是“一對(duì)多”的情況。