自動駕駛的測試是一個非常復雜的系統，我們用一篇文章，由小到大的逐個展開來和大家一起梳理下。

在梳理之前我們先拋出一個問題：自動駕駛的測試需要達到什么量級？

根據國際一般標準統計，人類司機駕駛一小時的死亡概率約為1/10^6，全世界每年因道路交通事故死亡人數約有125萬。自動駕駛汽車如果要發展，其死亡概率必然要遠低于這個標準。根據調查，目前社會可以接受的自動駕駛一小時的死亡率須不高于1/10^9。因此，如果要將死亡率降到1/10^9，每更新一次軟件，司機必須駕駛10^9小時，才能保證功能的可靠性。顯然，這種實車測試的方法并不可取。

真實的測試體系往往利用了分層思想，結合多種不同成本和覆蓋角度的測試手段，讓我們可以用可控的時間和成本，近似達成類似實車測試的效果。不同測試方法的成本是不同的，合理迭代次數也是有區別的。一個擁有合理測試體系的項目，模塊邏輯測試必須規避60%以上的潛在問題，仿真功能性能測試則要解決30%的剩余潛在問題，而留給實車魯棒性測試最多10%。在各自手段內盡可能的發現潛在問題，控制后道測試手段的問題量，如果搭配合理，則在保證極高覆蓋度的同時，成本也會進入可控范圍。比如如果仿真測試體系完備，則規劃開發幾乎無須上車驗證，就可以減少大量的外圍支持資源。

不同測試方法的對比

多層次的測試手段搭配也并非沒有代價，構建一個專項測試系統往往存在搭建周期長，初期成本高的問題。無論是零部件測試中的CAE,DV,PV測試，還是軟件里的靜態，集成，仿真測試，常有為了追趕進度而繞過一些測試工序的情況發生。

其實這是一筆經濟賬，當我們省略了某一前道測試工序時，如果后道高成本的測試工序解決前道工序遺留問題時所耗費的資源，要高于設立前道流程的花費，整個測試體系就會變得得不償失，反之亦然。

合理的測試層次也是一個平衡過程。

但一般而言，在一個延續性和成熟度較強的研發體系內，更多梯次且相互正交的測試體系配合高效的流轉往往會達成更高的效率。

真正有效的測試，往往是使用特定的測試工具和特定的測試用例，審核被測對象特定維度的問題。任何一種測試系統，只要其針對某一類潛在問題，成本低于其他手段，覆蓋問題范圍又高于其他手段，則就是一個好的測試系統，并無所謂其屬于哪種類型的測試系統，那都是后期被人為強行劃分出來的概念。在測試的設計中，務實非常重要。

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

另外，測試Pipeline往往也是訓練Pipeline的一部分。過去測試體系的工作主要是杜絕+由于人的失誤所導致的潛在產品隱患。

最為我們所熟知的就是測試驅動開發（Test-DrivenDevelopment，TDD），其要求在編寫某個功能的代碼之前先編寫測試代碼，然后只編寫使測試通過的功能代碼，通過測試來推動開發進行。

而現在自動駕駛正在走向自監督過程，我們看到更多機器與機器之間的互動。其中也包括機器與機器之間的測試反饋和開發調整，也就是我們非常熟悉的深度學習。對人而言，測試是為了保證產品和目標一致。對機器而言，訓練也是為了達成類似的目的。

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

自動駕駛的常用測試手段

從不同合作模式來看，可以分為黑盒、白盒以及灰盒測試。

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

從不同領域專項來看，不同的領域有各自特有的問題及其對應的測試維度。

從軟件代碼出發會有靜態測試、動態測試等：靜態測試會分析程序的語句結構、編程規范等是否有錯誤和不妥,常用工具包括QAC/Converity等，占整個測試體系的比重較小，一般是軟件測試的第一道，與之類似的是codereview其會組織相關專家對代碼的靜態設計做出評估；而動態測試則會比對運行程序后的結果與預期，分析運行效率和健壯性，目前自動駕駛絕大部分軟件測試科目都屬于動態測試范疇，比如性能測試及各類在環測試。

從不同技術斷面出發，是所有劃分模式中最復雜也是最重要的。

首先解釋下設置斷面的意義。當我們面臨一個復雜多因素混合作用的系統問題時，通過設置斷面，可以隔離影響變量，將復雜性簡化到一個可被測試的程度，同時可以將原本串行的問題排查任務轉化成并行任務，縮短項目進度。

如下圖所示，最底層的是單元測試、模塊測試和模塊集成測試。在研發平臺上（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測試不考慮目標硬件，可以在服務器上大量部署，成本較低，核心用于驗證智駕功能的閉環運行正確性。可以劃分為使用語義級仿真系統進行的局部閉環測試，以及使用環境渲染級別仿真系統進行的軟件全功能閉環測試。

SIL是目前最有潛力的測試手段之一，因此我們做一個簡單展開。單元測試、模塊測試等方法雖然自動化率高，但不能直接發現智駕系統的功能性問題。而硬件在環測試、實車測試等雖然問題發現更為直觀，但成本較高。而SIL在這些方法之間取得了不錯的平衡，是一種性價比很高的手段。SIL系統從內部看核心要確保可重復性。如果測試無法復現其過去的實驗結果，對后續評估會構成很大影響。如果由于多線程等原因確實無法完全保持可重復性，也需要多次實驗后確認其方差與穩定性。從整個測試體系看，越靠近內部（比如單元測試），則越容易控制可重復性，而越靠近外部（比如實車測試），就越難控制。從SIL系統的外部看核心是自動化率和大規模并行部署的能力，作為整個測試體系當中綜合分析來說規模最大的測試手段。減少人工和提高并發部署能力可以有效降低測試成本，并提高測試效率。SIL系統在智能駕駛的閉環體系下，除了測試，也開始為規劃的迭代訓練服務。我們在仿真測試中進行的安全評估、功能評估、法規要求評估、舒適性評估等所使用的指標和用例，其實也都是規控訓練過程中的一種“損失函數”。

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

SIL和HIL測試方法

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

VIL測試方法

另一種VIL的全新形態是實車交通環境在環測試（VTEHIL），在室內場地構建模擬的周邊環境變化以及車輛移動，來進行智能駕駛車的測試。由于環境完全受控，不受到氣候變化影響，可實現24小時連續測試，并且可以高效且完整模擬極端工況。

VTEHIL測試方法

進一步往下，是道路在環測試RIL（Road-in-Loop）或者說封閉場地測試。除了環境參與者和司機之外，其他全部都是真實要素。

在常規汽車測試體系中，此種測試手段也是常規操作，但不同于過去人工遙控和擺放的實施手段，目前已經出現了自動化測試方案，由于最新的假人假車裝備同樣配置了必要的傳感器，執行器與通信設備，可以接入云端集中指揮調度。因此云端的測試用例可以同步到封閉測試場內被智能假人和假車“表演”出來。大大提升完成一次測試的效率。

RIL測試方法

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

LABCAR測試臺架

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

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

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

大規模實車測試

大規模開放道路測試對于智能駕駛系統來說也是必須的，原因和傳統路測略有不同。由于真實交通中更加千變萬化，而駕駛模擬器或者受控場地測試只能復現很小一部分，評價的結果可能與真實情況有偏差。因此需要大規模路試來對智能駕駛汽車在整個交通環境中的運行進行驗證。在開放道路測試中，功能數據、行為數據、環境數據都要同步采集。功能數據往往來源于智駕系統本身。行為數據核心是監控司機反應，來源于額外安裝的內部攝像頭、眼球追蹤儀、生理檢測設備。而環境數據會同時來源于車輛自身的環境傳感器以及一些額外安裝的性能更高的傳感設備，比如激光、INS或者高清相機。當然目前這種方法已經更多的被數據閉環的方式所代替

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