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

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

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

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

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

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

1. 找到潛在的問題。

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

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

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

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

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

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

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

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

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