在汽車行業對軟件開發重視的當下，不少從其他行業加入的，那熟悉ECU軟件測試流程就是必要的了，另外對于一直在行業深耕的開發或測試人員，梳理一下測試流程也是有必要的。
接下來我們以常用的V模型開發流程為線索，列舉實例來說明。
       01.
       需求編寫
       假如現在我寫了一個系統需求，也就是圖1中的“Technical Safety Concept”:(PS：所有的Techincal Safety Concept都是系統級需求，不是軟件需求)系統需求：自適應巡航功能只能在30公里到120公里每小時之間激活.[ACC-SysReq 001]；并且一旦退出后不可再自動激活[ACC-       SysReq 002]。簡單起見，我們先看第一條需求，并把這條系統需求寫成軟件需求：
       軟件需求：
       當以下條件滿足時，ACC功能狀態設置為READY[ACC-Req 001]:

車速大于或等于30kph AND
       車速小于或等于120kph.
       當滿足以下條件時，ACC功能狀態設置為SUPPRESSED[ACC-Req 002]:
       車速小于30kph OR
       車速大于120kph.
       在軟件設計文檔中， 也就是圖1V模型中的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.
       到這里，以上就是一個最簡單的需求demo。根據這個需求，你通過幾行代碼來實現。假設使用C來寫，在原有的C文件acc.c中加入了：
       if((SafeVehSpd>=30)&&(SafeVehSpd<=120)){ Acc_ActSt=READY; }elseif((SafeVehSpd<30)||(SafeVehSpd>120)){ Acc_ActSt=SUPPRESSED; }else{ }有同學可能會好奇，第一個if語句寫完了直接寫else不就完了嘛。
       是的， 但是目前我也不知道客戶后面會怎么改這個需求，可能會對其他速度段增加新的狀態，所以就先寫個else if在這里，方便以后擴展。
       到這，V模型的左半邊我們就做完了，現在我們開始來測試。
       02.單元測試
       寫完代碼并編譯成功后，先進行代碼的單元測試，圖1 V模型中的“Software Unit Verification”。顧名思義，就是把新編寫或者修改過的單元（單獨的C文件，在本例中是上述的acc.c)與整個軟件工程隔離，單獨測試其輸入輸出。
       汽車上的代碼開發通常首先要做MISRA-C規則測試。MISRA-C測試是一種代碼靜態測試，用來檢驗編碼是否符合一系列預先設定的編程規則。這里我們假設用的測試工具是QAC。
       就我寫的這段代碼，估計會報出一個warning, 因為 “else” 這個分枝實際上是無法觸發的，而MISRA-C的其中一個規則就是所有代碼都必須可觸發，所謂“Accessible”。當然啦，這里我是有意為之，所以可以注釋一下就放過去了。
       下一個步還可以進行Polyspace測試，Polyspace也是一種靜態測試工具，其可以進一步幫助判斷算法運算過程中，會不會產生諸如數組索引越界、被除數為零之類的bug 。上述例子中只有邏輯判斷，所以其實不需要做Polyspace測試。
       接下來進行功能測試。在功能測試中，我們需要：
       梳理待測單元的輸入和輸出信號
       設計一系列的輸入信號值，并同時列舉對應的正確輸出信號值。我們把這個叫做“測試集”。
       輸入測試集中的輸入信號值，運行單元代碼。如果輸出信號的值和測試集中的正確輸出信號值相同，則功能測試通過。
       編寫測試集的基本原則之一為測試需覆蓋所有代碼，并且盡量測試所有判斷邏輯。上述例子非常簡單，只有一個輸入變量和一個輸出變量，分別為 SafeVehSpd 和Acc_ActSt。
       我們需要把輸入信號按判斷邏輯分成若干個Equivalent Class 。在上述例子中，將輸入信號(假設 SafeVehSpd的類型為Unsigned int, 速度上限為500 kph)SafeVehSpd分成三個Equivalent Class，分別為:
       1. [0, 30）
       2. [30, 120]
       3. (120,500]
       于是這三個Equivalent Class里隨機各取一個值，就能測試所有代碼邏輯了。但實際測試中，往往還需進一步進行邊界測試, 也就取每個Equivalent Class的兩端的值來進行測試。這就涉及到精度問題了。假設這段代碼是定點運算，車速數值由10bit表示，前述車速上限為500，車速的精度就是 500/（2^10）= 0.48828125。
       所以嚴格來說，測試集需要測試的輸入變量SafeVehSpd的值有6個，分別是 0 ，29.5117188 ，30 ， 120 ， 120.48828125 ， 500 。
       當然，現在很多工具支持自動生成測試集，所以不用程序員費勁的去算這些破玩意兒。
       需要說明的是，就算進行了完善的功能測試，也并不能保證功能就沒有bug，因為實際工程中輸入信號的組合是無窮無盡的，再加上時序等因素，功能測試不可能窮盡所有的實際情況，我們只是盡力而為。
       汽車行業比較流行的單元測試工具有VectorCAST、Cantata等。
       03.軟件集成測試
       完成單元測試后，就要把測試好的軟件單元集成到整個軟件工程里來測試。這一步對應圖1中的“software verification and integration"。
       在單元測試中，我們通過直接改變SafeVehSpd 的值來進行測試。實際上，SafeVehSpd來自CAN總線上的車輪輪速數據。
       假設如圖3所示，獲取CAN總線上傳來的原始輪速信號WheelSpdRaw， 經過通信接口模塊COM_IF.c處理 以及車速計算模塊VehSpd.c計算后 ,得到信號SafeVehSpd 。那么在集成測試中，我們通過改變WheelSpdRaw的數值來對acc.c中的代碼進行測試。為了其目的是為了驗證acc.c模塊與其他模塊的接口是否正確，以及各模塊之間是否有沖突。
       進行軟件集成測試的時候，圖3的三個模塊其實合并在了一起形成了一個“黑盒”，我們只關心最初的輸入信號WheelSpdRaw 和最終的輸出信號Acc_ActSt 之間的邏輯。
       在實際工程中，COM_IF.c、VehSpd.c 和 Acc.c 三個模塊很可能是由三個工程師維護的，這就可能導致任何一個模塊單獨進行集成測試都通過不了。這時候就需要由項目經理或者product owner提前進行溝通協調，確保所有功能都更新以后，三個模塊一起進行集成測試。
       軟件集成測試流行的工具和單元測試一樣， 也是Cantata之類的。
       軟件單元測試和軟件集成測試都可以被稱為軟件在環測試（Software in the loop , SIL)。
       04.硬件在環測試(HIL)
       完成SIL測試后，下面就是硬件在環測試了（Hardware in the loop, HIL），對應了圖1中的 “Testing of embedded software”。有一些企業在硬件在環測試前之還會進行PIL測試（Processor in the loop），這里就不討論了。
       HIL測試也是一種集成測試。前面討論的軟件集成測試，是在PC 仿真環境執行的，而實際ECU無論是負載、內存、硬件等方面和PC環境有很大的不同，所以相同的功能需要在實際硬件中再測試一遍。也就是說，HIL測試與軟件集成測試最大的不同在于，前者運行于實際硬件中，而后者只是運行在計算機仿真環境下。硬件在環測試的主要工具是實際的零部件。比如測試ACC功能的話可以是ADAS控制器，或者是集成了ACC功能的毫米波雷達、攝像頭等。除此之外還要有一個實驗臺架提供必要的運行環境、電力供應和總線接口。常用的HIL測試工具比如dspace的測試環境，dspace control desk。和軟件集成測試一樣，HIL測試也是通過改變原始的CAN信號（上述中的WheelSpdRaw）來進行測試，只不過，這一次不是直接改變WheelSpdRaw在內存中的數值，而是通過HIL測試臺架真的向ECU通過CAN發送真實的WheelSpdRaw信號。HIL測試的測試集，也就是測試用例需要和軟件需求Software Requirement 嚴格對應，可以是一對一，一對多或者多對一都可以。所有的 HIL測試用例都必須根據一條對應的Software Requirement 寫出，但是條件就沒有單元測試時候那么苛刻了。比如為了測試需求ACC-Req 001，HIL測試用例可以寫成：
       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，這就是“一對多”的情況。05.實車測試
       實車測試就很好理解了，在所有前述測試都通過以后，工程師上車來實際測試相關功能。這對應了圖1中的“System and item integration and testing”。實車測試用例需要根據系統需求來制定。對于本文的例子，可以寫成：1.著車后打開ACC功能，保持車輛靜止。觀察儀表盤，ACC 功能未啟動。2. 將汽車加速至30kph，再次打開ACC 功能， 觀察儀表盤，ACC啟動。將汽車減速至29kph，觀察儀表盤，ACC 功能退出。3. 將汽車加速至110 kph， 打開ACC 功能， 觀察儀表盤， ACC 啟動。將汽車加速到121kph，觀察儀表盤，ACC 功能退出。

本文由培訓無憂網長沙牛耳教育課程顧問老師整理發布，希望能夠對想參加長沙軟件測試培訓的學生有所幫助。更多軟件測試培訓課程信息可關注培訓無憂網電腦IT培訓或添加老師微信：15033336050

      注：尊重原創文章,轉載請注明出處和鏈接 http://m.dedgn.cn/news-id-11360.html 違者必究！部分文章來源于網絡由培訓無憂網編輯部人員整理發布,內容真實性請自行核實或聯系我們，了解更多相關資訊請關注軟件測試頻道查看更多，了解相關專業課程信息您可在線咨詢也可免費申請試課。關注官方微信了解更多：150 3333 6050