最近經常聽到這樣一個問題：“到底測試到什么程度，才能上路？”

　　測試自動駕駛的代碼與測試普通互聯網產品的代碼不同。互聯網產品的代碼只要達到了目標功能，就可以發布。比如手機APP，只要用戶用起來沒有障礙，就是好代碼。

　　而無人車不同。代碼中存在的問題，不只是一個bug這么簡單。代碼中的問題，只有一小部分是“known unknown”，也就是可以預料到的問題。大多數是“unknown unknown”，也就是無法預料的問題。問題如果不被及時發現，帶到了路測上，就會對公共安全造成威脅。

　　2018年Uber測試車事故現場

　　理論上講，測試的環節越周密、越仔細越好。而現實中，我們往往沒有足夠的時間或資源去做所有的測試，或是測試所用的工具還不夠成熟。因此，工程師們往往要決定，在有限的條件下，應該作何取舍。

　　其實，測試代碼不過是為了兩個目標：

　　1. 找到潛在的問題。

　　2. 有效挖出問題的根源。

　　針對第一個目標，我們首先要看測試的各個級別是否覆蓋全面。自動駕駛的測試多種多樣。首先，工程師要盡到自己份內的測試職責。從最初的幾名工程師聚在一起做設計審核（design review），到基本的單元測試（unit test），再到部件測試（component-level test），工程師至少要保證自己寫的那幾行代碼不出問題。

　　基礎的測試完成之后，下一步就是保證代碼與其他部件可以兼容。比如，做激光雷達模型的工程師要保證自己的代碼不會影響到其他傳感器。這時就需要把整個stack跑一遍，或是hardware in the loop，將其他硬件系統也一起測試，看看是否有兼容問題，做到“持續集成”（continuous integraTIon）。具體方法可以參考V&V模型。

　　測試的方式也分為很多種，除了可以在本地跑代碼，自動駕駛最重要的就是仿真。一個強大的仿真平臺可以在一定程度上代替路測。通過仿真技術，不但可以對已有的駕駛數據（log）重演，也可以打造全新的場景，自己定義各項參數（parameter），從而讓有限的數據在短時間內發揮其最大效用。

　　仿真測試之后，可以把代碼放在車上，在封閉環境里測試（closed course），最終才可以去開放道路上測試。

　　測試的途徑多種多樣，但總體上來講，越底層的測試，成本越低。如果等到上路測試才發現問題，那成本就很高了。

　　原因很簡單：越底層的測試，越容易查出問題的根源。越是上層的測試，涉及的部分越廣，一旦找到問題，排查起來就很難。

　　因此，底層的測試設計尤為重要。一個測試對象可以是一個新開發的駕駛行為，也可以是對已有功能的改進。如果是對已有功能的改進，就要將所有的細節量化為指標（metrics），指標一旦有變動，或是“退化”（regression），比如將騎自行車的人探測為行人，就要分析其原因。從而做到讓每一個潛在問題都“有根可循”。

　　如果是開發新的駕駛功能，就可以利用仿真平臺打造所需場景，預估有可能發生的問題，再針對每一個潛在的問題設計所對應的指標，做到“防患于未然”。