隨著項目進展，最近又開始承擔一部分測試驗證工作?？吹轿宜镜臏y試能力和流程，忍不住深深嘆了口氣。

0.前言

回想起上次寫關于測試的內容，起因還是蔚來的兩位工程師在工作中發生事故，為兩位同事感到悲傷和惋惜而動筆。時間就像駕車時的后視鏡，越走越遠，但也時刻提醒我們前路的方向。自我進入汽車行業之日起，我的工作角色不斷變化，從測試到系統再到架構，但總繞不開“測試”這兩個字。

最近有感而發：系統工程師的歸宿就是測試。這句話看似玩笑，卻并不是空穴來風?？v觀ASPICE開發流程，系統需求設計和系統測試是處在V模型的兩端，分別處于ASPICE SYS.1和SYS.5的位置。從開發的角度來說，功能的需求提出者，一定需要對功能的表現去負責，因為只有提出者才能最清晰的知道期望的產品形態。所以每個系統工程師應該必備一身的測試技能。

圖1 ASPICE Overview?（來源于ASPICE）

1.測試閉環

是的，以上討論的測試是基于ECU的系統測試。這個意義上的系統測試，一般是供應商的系統工程師在交付產品時進行的，ECU的軟件以及硬件都已經成形，供應商在仿真環境或對手件在線的情況下完成的測試；或者主機廠的系統工程師在驗收產品時，將零部件裝車進行的系統級測試。在實際研發過程中，這種系統測試其實已經到了研發的結束階段，多用來驗證復雜工況下產品的性能。本人以前在主機廠做測試和系統時，主要就是負責這種系統測試。

那我們在車載ECU開發過程中，完整的測試閉環是怎么樣的呢？

從軟件出發，各模塊的工程師應該對模塊進行自測。比如感知、定位、規控等應用模塊，以及中間件的更新，需要在提交前進行自測并提交報告。在模塊自測通過后，軟件部門leader有責任進行集成測試。完備的集成測試應該包括功能層面、性能層面、基礎通訊、魯棒性等，這部分可以通過流水線實現。每次軟件釋放后，需要注意生成的版本號，便于進行問題排查。

以上的測試都是跑在仿真環境中的，接下來將軟件版本刷入經過DV/PV實驗的ECU板子中，驗證軟件在硬件中的表現。這個環節普遍是問題最多的，而且不易定位是軟件問題還是硬件問題，往往需要工程師的經驗來分析解決。

當然，目前市面上有很多自動化測試設備能夠幫助我們進行迭代測試，這類測試設備養活了一部分企業。國外的Vector是此中翹楚，近年來國內的昆易電子也發展的很不錯。當年我第一個使用的HIL測試臺架就是昆易的，說來有趣，本來是測試ECU，結果變成了“免費”幫供應商測試他們的臺架.....嘿嘿，當然那已經是幾年以前了，現在國產廠商發展的都十分不錯。最近也接觸了北匯的測試設備以及培訓，他們在吉利系內部承接了很多項目。

到最后，就可以將ECU放入整車環境中進行測試了。這里的整車環境可以是通過多個對手件接入臺架組成的仿真環境，也可以是實車環境。實車環境更為逼真，趨近于客戶使用，但在車上畢竟測試環境較為惡劣，工作效率也比較低。一般是在量產關鍵節點多個ECU一起裝車后，由主機廠專業測試工程師去進行路試，然后上報各ECU的問題，由不同責任人處理。

圖2?V模型測試流程?（來源于北匯信息）

以上這一大段，其實就是描述的MIL-SIL-HIL-VIL的測試鏈路。在老東家負責系統的時候，當時還帶了幾個應屆生做ADAS產品測試，曾經反復思考過，應該如何做測試，做哪些測試，我們需要哪些工具和環境，如何做到快速迭代驗證?，F在想來，還是要結合現狀，每個公司的需求不同，擁有的資源不同，研發目標不同，能夠提供的測試條件自然不同。

2.自動駕駛中的測試

在自動駕駛領域，測試更需要專業和細致，就像是進入了“硬核”模式。目前我司的一款在研高配車型，裝配12*Camera，3*Lidar，5Radar，12Uss，1*高精度定位盒子，接入域控制器?？紤]一下，我們這款車上有那么多的傳感器，你能想象測試的復雜性嗎？但這正是挑戰的魅力所在，對不對？在如此復雜的網絡拓撲的情況下，如何做到精確快速穩定全面的檢出問題，定位問題，是需要持續思考的。

圖3?智能汽車傳感器?（來源于網絡）

自動駕駛領域的測試與普通軟硬件測試存在著顯著的差異，這些差異主要源于自動駕駛系統的復雜性、多樣性以及其對安全性的特殊需求。

3.思考

到了我司，重算法重開發，現階段沒有專業的測試團隊，也沒有完善的測試流程，測試問題的閉環鏈路有待完善。往往是算法工程師去車上簡單驗證后就可以合入主線，而他人提報的問題，僅在本地驗證后就能夠關閉，等等這些問題很容易在后續的開發中埋下伏筆。有時候，實車測試和仿真測試的結果是南轅北轍。

系統工程師是項目開發中的關鍵角色，他們不僅需要具備深厚的系統知識，對架構和設計有深入的了解，還需要具備一系列的測試能力來確保系統的質量和可靠性。作為系統工程師的我們，更應該保持冷靜，記錄、分析、跟蹤問題。以下是從我司實際情況角度出發考慮的一些建議。

測試工具和自動化: 隨著軟硬件的復雜性增加，手動測試的效率和準確性都將受到挑戰。因此，借助自動化測試工具，如Vector的CANoe、CANalyzer等工具，可以大大提高測試效率。此外，編寫完善的自動化測試腳本和測試用例也是至關重要的。

持續集成和持續測試: 通過建立持續集成和持續測試（CI/CD）的環境，可以確保軟件在每次更改后都能快速得到驗證，從而盡早發現和修復問題。

故障注入和魯棒性測試: 為了確保ECU在各種異常和故障情況下的穩定運行，可以進行故障注入測試，模擬各種可能的硬件故障、通訊中斷等情況。

模擬環境與實際環境的差異: 在仿真環境中，測試的條件是可控的，而實車測試的條件則更加復雜多變。為了橋接這兩者之間的差距，可以考慮使用更為逼真的仿真工具，如IPG CarMaker等。

文檔和跟蹤: 記錄測試過程、測試結果和問題跟蹤是至關重要的?？梢钥紤]使用問題跟蹤工具如JIRA，并且定義清楚問題關閉的條件和責任人，確保每個問題都被妥善處理。

團隊培訓和知識分享: 定期組織團隊內部的技術分享和培訓，可以確保團隊成員對測試方法和工具的了解都保持在最新的狀態。

安全和法規考慮: 隨著全球汽車行業對功能安全和相關法規要求的越來越高，ISO 26262等標準對車載軟件的測試提出了更為嚴格的要求。考慮這些因素，會使得測試更為嚴格，但也更具有挑戰性。比如NOP功能需要考慮R79的法規要求，而ACC/LCC等功能很早之前已經有了完善的法規定義。

寫到這里，其實是想說，我們在測試上還有很長的路要走。但也請記住，每一次的進步都是為了更好的未來。最后，預祝大家十一快樂，開車別忘了測...哦，是帶上安全帶！

編輯：黃飛

?