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

　　測試自動駕駛的代碼與測試普通互聯(lián)網(wǎng)產(chǎn)品的代碼不同?；ヂ?lián)網(wǎng)產(chǎn)品的代碼只要達(dá)到了目標(biāo)功能，就可以發(fā)布。比如手機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模型。

　　測試的方式也分為很多種，除了可以在本地跑代碼，自動駕駛最重要的就是仿真。一個強大的仿真平臺可以在一定程度上代替路測。通過仿真技術(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)，做到“防患于未然”。