自動駕駛層次測試體系（單元測試/整合測試/SIL/HIL/VIL/RIL/LABCAR/實車等）

智慧駕駛的測試是一個非常復雜的系統，我們用一篇文章，由小到大的逐個展開來和大家一起梳理下。在梳理之前我們先丟擲一個問題，自動駕駛的測試量需要達到什麽量級？根據國際一般標準統計，人類司機駕駛一小時的死亡機率約為10^6 分之一，全世界每年因道路交通事故死亡人數約有125萬。自動駕駛汽車如果要發展，其死亡機率必然要遠低於這個標準。根據調查，目前社會可以接受的自動駕駛一小時的死亡率須不高於10^9分之一。因此，如果要將死亡率降到10^9分之一，每更新一次軟體，司機必須駕駛10^9小時，才能保證數據的效度。而駕駛10^9小時，裏程將近250億公裏，需要300萬輛車每天不間斷的行駛一年時間，采整合本高達千億。

顯然，這種全部進行實車測試的方法並不可取。真實的測試體系往往利用了分層思想，結合多種不同成本和覆蓋的測試手段，讓我們可以用可控的時間和成本，近似達成類似實車測試的效果。如下圖所示，不同測試方法的成本與效率都是不同的，允許叠代的次數也是有區別的。如果一個計畫，軟體在環的測試數量在千萬級別，則硬體在環測試約在萬余級別，而實車路測只有百余級別。在各自手段內可以提前發掘的潛在問題規模逐級降低，而成本卻會逐級提升。如果搭配合理，則在保證極高覆蓋度的同時，成本也會進入可控範圍。比如如果仿真測試體系完備，則規劃開發幾乎無須上車驗證，就可以減少大量的外圍支持資源。

不同測試方法的成本與效率

多層次的測試手段搭配也並非沒有代價，構建一個專項測試系統往往搭建周期長，初期成本高。無論是零部件測試中的CAE,DV,PV測試，還是軟體裏的靜態，整合，仿真測試，常有為了追趕進度而繞過一些測試工序的情況發生。其實這是一筆經濟賬，當我們出於一些原因跳過了某一低成本的前道測試工序時，如果後道高成本的測試工序解決遺留問題耗費的資源高於設立前道流程的花費，就會變得得不償失，反之亦然。合理的測試層次也是一個平衡過程。但一般而言，在一個延續性和成熟度較強的研發體系內，更多梯次且相互正交的測試體系配合高效的流轉往往會達成更高的效率。

另一個測試常見的問題是執行「過於完美」的設計。如下圖所示, 教科書式的把測試看成全用例，全手段的大工程其實不是非常可取，理論不錯，實際的成本和收益並不高。真正有效的測試，往往是特定的工具，特定的測試用例稽核被測物件特定維度的問題。任何一種測試系統，只要其針對某一類潛在問題，成本低於其他手段，覆蓋問題範圍又高於其他手段，則就是一個好的測試系統，並無所謂其屬於哪種型別的測試系統，那都是後期被人為強行劃分出來的概念。測試的設計往往沒有那麽多章法，務實非常重要。

工程實踐過程中的測試過程

另外，測試Pipeline往往也是訓練Pipeline的一部份。過去測試體系的工作主要是杜絕由於人的失誤所導致的潛在產品隱患。最為我們所熟知的就是測試驅動開發（Test-Driven Development，TDD）要求在編寫某個功能的程式碼之前先編寫測試程式碼，然後只編寫使測試透過的功能程式碼，透過測試來推動開發進行。而現在自動駕駛正在走向自監督過程，我們看到更多機器與機器之間的互動。其中也包括機器與機器之間的測試反饋和開發調整，也就是我們非常熟悉的深度學習。測試是對人的真值，也可以是對機器的真值。

最後，需要特別註意測試的自動化率和可重復性。測試以及訓練Pipeline的呼叫一般是所有Pipeline中最高頻的，因此對應Pipeline的自動化率和無人值守比例的要求也是所有數據管道中最高的，其很大程度上影響著研發成本。構建測試系統內核時，還需要特別註意對Repeatable（可重復）的要求，越靠近內部要求越高。如果測試無法復現其過去的實驗結果，對後續評估會構成很大影響。如果由於多執行緒等原因確實無法完全保持可重復性，也需要多次實驗後確認其變異數與穩定性。

以上就是測試的一些基本思想，緊接著我們詳細看下，目前智慧駕駛有哪些典型的測試過程。如下圖所示，個人認為可以從不同合作模式、不同領域專向以及不同技術斷面三個方面進行系統性的梳理。

自動駕駛的常用測試手段

從不同合作模式來看，可以分為黑盒、白盒以及灰盒測試。白盒測試會檢查內部結構每一條通路是否按照設計正常工作。一般用於產品提供方內部的管理。而黑盒測試一般不考慮內部結構，僅檢查產品功能是否按照合約提出的技術要求實作了，一般用於被提供方的內部管理。灰盒測試介於上述兩種測試程度之間，在測試外部功能的基礎上，會對關鍵鏈路進行確認，一般用於提供方的釋出測試或者被提供方的驗收測試，具體程度視具體合作而定。

從不同領域專項來看，不同的領域有各自特有的問題及其對應的測試維度。從軟體程式碼出發會有靜態測試、動態測試等。靜態測試會分析程式的語句結構、編程規範等是否有錯誤和不妥,常用工具包括QAC/Converity等，占整個測試體系的比重較小，一般是軟體測試的第一道。與之類似的是code review其會組織相關專家對程式碼的靜態設計做出評估。而動態測試則會比對運行程式後的結果與預期，分析執行效率和健壯性，目前自動駕駛絕大部份軟體測試科目都屬於動態測試範疇，比如效能測試以及各類在環測試。

從不同技術斷面出發，是所有劃分模式中最復雜也是最重要的。首先解釋下設定斷面的意義。當我們面臨一個復雜多因素混合作用的系統問題時，透過設定斷面，可以隔離影響變量，將復雜性簡化到一個可被測試的程度，同時可以將原本序列的問題排查任務轉化成並列任務，縮短計畫進度。

如下圖所示，最底層的是單元測試、模組測試和模組整合測試。在研發平台上（X86），將軟體函式、單個或多個模組的輸入輸出作為斷面，核心在於驗證程式碼邏輯的正確性。透過VectorCast、GTest等工具將大量的錯誤輸入和少量的正確輸入註入被測物件，確認反饋符合預期，這個過程一般是開環的。模組級別的測試一般也被稱為模型在環測試Model-in-the-Loop (MIL) 除了考慮部份正確性外，還會有一些模型效能指標比如感知模組的辨識精度等。

軟體邏輯層面的測試方法

一個在X86上穩定執行的軟體，在嵌入式環境下可能出現堆疊溢位，排程混亂，時間戳不穩定，系統呼叫支持不到位，記憶體讀取異常，執行阻塞等一系列問題。為了排查這種差異。如下圖所示，在軟體邏輯層面之上可以繼續引入目標硬體這個維度，也就是處理器在環測試Processor-in-the-Loop (PIL)，其是將部份程式碼放置於目標處理器上，驗證程式碼功能正確性的同時，確認其效能是否達到要求。比如，軟體最長耗時，系統呼叫可靠性等。軟體在環測試一般評估正確性，而硬體在環測試一般評估穩定性。

PIL測試方法

如下圖所示，以上所有的測試一般都是開環的，並不會驗證與環境物件的互動。當我們在軟硬體的維度上增加環境閉環這個概念之後，就產生了軟體在環測試SIL (Software-in-the-Loop)和硬體在環測試HIL (Hardware-in-the-Loop)的概念。引入環境要素後，還會同時引入場景庫作為測試用例。測試過程除了驗證基本邏輯外，還會評估一部份智慧駕駛的執行服務指標。

SIL測試不考慮目標硬體，可以在伺服器上大量部署，成本較低，核心用於驗證智駕功能的閉環執行正確性。可以劃分為使用語意級仿真系統進行的局部閉環測試，以及使用環境渲染級別仿真系統進行的軟體全功能閉環測試。

HIL測試區別於SIL需要考慮目標硬體，一般不會大量部署，因為成本較高，其結果相比SIL更接近真實狀態，可以額外評估軟體在目標硬體上的整體效能（執行排程，記憶體呼叫，算力呼叫）是否符合預期。HIL測試通常將一個被測控制器和一系列模擬裝置做硬線（PWM、UART、CAN、GPIO等）連線，將記錄或模擬的原始數據反向構建成真實訊號輸入，來完成對目標硬體的測試工作。在實踐過程中，個人認為，切勿執著於全功能長周期工作的HIL台架，20台輕量級HIL台架（PIL台架）的價格可能還不及1台全功能HIL台架。效果上兩者對比差距卻並不大。一部份物理IO，一部份功能模擬往往更為科學，HIL台架一般僅用於短周期的閉環測試，長周期測試往往會有較大誤差。

SIL和HIL測試方法

完成了單控制器的測試後，智慧駕駛測試會繼續進入整車級別，如下圖所示，首先我們要介紹的是整車在環測試VIL（Vehicle-in-Loop）或者說實車虛擬註入測試，即透過在軟體內部配置斷面測試介面，在封閉測試場內的實車測試環境下，遮蔽部份真實感知輸入，從而在測試場內的空曠區域模擬任何形式的道路環境。比如在路上添加並不存在的車輛，或是模擬一個交叉口的訊號燈切換。由於其他測試要素均為真實內容，因此測試可信度高，且可以充分利用封閉測試場的環境資源。

VIL測試方法

進一步往下，是道路在環測試RIL（Road-in-Loop）或者說假人假車參與測試。除了環境參與者和司機之外，其他全部都是真實要素。在常規汽車測試體系中，此種測試手段也是常規操作，但不同於過去人工遙控和擺放的實施手段，目前已經出現了自動化測試方案，由於最新的假人假車裝備同樣配置了必要的傳感器，執行器與通訊裝置，可以接入雲端集中指揮排程。因此雲端的測試用例可以同步到封閉測試場內被智慧假人和假車「表演」出來。大大提升完成一次測試的效率。

RIL測試方法

相比控制器級別的測試，整車級測試更關系體驗下指標，比如接管率，系統穩定性，系統魯棒性等指標。除了VIL和RIL之外，整車級別測試還有LabCar測試以及大規模實車測試，這部份內容更多和傳統整車其他傳統測試流程一起進行。

LABCAR測試台架

單個智駕控制器測試完成後，需要給到整車部門，在整個電子電氣架構中進行測試，這個測試就被稱為LABCAR測試，LABCAR測試也可以理解為幾個控制器組成的硬體在環（HIL）測試。透過模擬外圍傳感器與執行器資訊來檢測整個電子電氣系統是否工作正常，同時LABCAR還可以人為註入故障（短路，斷路等）來檢測非正常情況下反應是否符合預期。

整車測試相對於系統測試往往關註的並非單個功能，而是可能導致綜合影響的共性維度。比如整車異響效能測試。在很多相關問題上，涉事零部件往往在單體台架試驗、系統級台架試驗上，均無法復現，僅僅只有在整車狀態下的某些特殊工況下才會出現。

整車測試的一般做法就是真實路試。首先是汽車的六大基本效能，包括動力性、經濟性、制軔性、操穩性、透過性，都有標準客觀試驗做定量解析，平順性可能涉及工程師校調，隨風格會有些許差異。另外會在各種極端環境下做綜合測試（高原，高寒，高溫），常說的「冬天去黑河，夏天去海南」，就是這麽來的。一般來說所有測試的試驗條件會比正常用車條件苛刻的多，從而可以有效提升測試效率。當然還包括剛才說到的NVH效能，耐久效能等只有在整車環境下才可以進行的測試。總的來說，整車測試的核心邏輯和零部件測試類似。由於測試需要配備牌照，保險，司機以及大量其他人力和保障資源，時間和經濟成本都很高。因此整車測試往往較為精煉且被嚴格計劃。實驗工況數量和測試次數會被精密計算，一般根據理論外加經驗估計得到。

大規模實車測試

整車測試的另一個目的就是獲得政府認可公告。中國有針對乘用車的強制檢驗標準，大概40余項，對於可以在市場售賣的車輛而言，這些試驗是必須透過的。隨著智慧駕駛技術的逐步落地，智慧駕駛往往也會加入整車級測試科目當中。核心原因不同於傳統路側。由於真實交通中存在中千變萬化的情況，而在駕駛模擬器或者受控場地測試中只能復現很小的一部份，因此評價的結果存在著與真實情況有偏差可能性。因此，需要采用大規模路試（Field Operational Tests, FOT）來對整個交通環境進行長期影響分析。在FOT中，車輛除了配備需要評價的ADAS系統外，還需要裝備網路攝影機、眼球追蹤儀等裝置對駕駛員的行為等數據進行采集，並且這些裝置需要進行適當的隱藏，避免讓駕駛員感覺被監視，盡量讓駕駛員按照日常行駛狀態行駛。當然目前這種方法已經更多的被數據閉環和眾包的方式所代替。

以上就是和智慧駕駛系統相關的所有測試手段的介紹，個人往往很難接觸到所有這些任務，但是理解完全域，對於個人理解自己的測試任務在研發中的意義是有指導性的。

如果對智慧駕駛感興趣，歡迎關註我~~