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

　　測試自動駕駛的代碼與測試普通互聯(lián)網(wǎng)產(chǎn)品的代碼不同,。互聯(lián)網(wǎng)產(chǎn)品的代碼只要達(dá)到了目標(biāo)功能,，就可以發(fā)布,。比如手機(jī)APP，只要用戶用起來沒有障礙,，就是好代碼,。

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

　　2018年Uber測試車事故現(xiàn)場

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

　　其實,，測試代碼不過是為了兩個目標(biāo)：

　　1. 找到潛在的問題。

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

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

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

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

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

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

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

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

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