簡介中信建投證券于2021年8月14日發(fā)布的中國汽研601965深度研究報告聚焦智能駕駛測評這一稀缺賽道認為公司是攻守兼?zhèn)涞膬?yōu)質(zhì)標(biāo)的適合關(guān)注汽車服務(wù)、智能網(wǎng)聯(lián)檢測領(lǐng)域的投資者與行業(yè)研究人員研讀。資源為單份PDF文件大小4.89MB排版清晰包含公司業(yè)務(wù)拆解、汽車前裝檢測行業(yè)格局、智能汽車檢測市場空間測算、投資評價及盈利預(yù)測等核心模塊。已有169人學(xué)習(xí)下載內(nèi)容不僅覆蓋傳統(tǒng)檢測業(yè)務(wù)的穩(wěn)健增長邏輯還重點剖析了技術(shù)、產(chǎn)品、消費、政策四重催化下智能化檢測的增量空間并給出2021-2023年歸母凈利潤及EPS預(yù)測同時提示了滲透率不及預(yù)期等風(fēng)險。對理解第三方檢測機構(gòu)在智能駕駛產(chǎn)業(yè)鏈中的卡位價值具有直接參考意義。1. 智能駕駛測評為什么成了關(guān)鍵瓶頸一份研報背后的技術(shù)機會智能駕駛測評是這個行業(yè)里少數(shù)“聽起來只是測試、實際上決定能不能量產(chǎn)”的方向。某券商2021年的一份行業(yè)深度報告把一家汽車技術(shù)研究機構(gòu)的智能駕駛測評能力單獨拎出來講并在標(biāo)題里用了“稀缺”二字——這個判斷放到現(xiàn)在依然成立很多團隊能做出會跑的智能駕駛系統(tǒng)卻很難拿出讓人信服的證據(jù)證明它在各種場景下足夠安全、可批量交付。這篇筆記不聊投資只聊技術(shù)落地智能駕駛測評到底是什么、怎么搭、參數(shù)怎么設(shè)、坑在哪以及它值不值得作為方向投入。2. 智能駕駛測評體系怎么拆標(biāo)準、場地與四層測試任務(wù)2.1 法規(guī)標(biāo)準是測評的第一層地基智能駕駛測評不是“自己覺得測過了就算數(shù)”它有一套從法規(guī)到行業(yè)認可的規(guī)則體系。早期大部分主動安全功能是車企自愿做測多測少全看良心現(xiàn)在各國都在把AEB自動緊急制動、LKA車道保持輔助這類基礎(chǔ)ADAS功能納入新車評價規(guī)程甚至強制性準入范圍沒有第三方測評報告車型連上市銷售這關(guān)都過不去。這就是測評能力成為稀缺資源的第一層原因它已經(jīng)從“加分項”變成了“及格線”。對剛接觸這個方向的人來說建議先理清三類標(biāo)準強制性法規(guī)管的是底線重點看AEB、車道偏離預(yù)警、盲區(qū)監(jiān)測等基礎(chǔ)功能在特定車速和場景下是否觸發(fā)判據(jù)是“有沒有”和“何時觸發(fā)”。第三方評價規(guī)程在法規(guī)之上做更嚴格的安全星級評價增加了更多場景類型、更細的通過條件考的是“表現(xiàn)好不好”。功能安全與預(yù)期功能安全標(biāo)準前者面向電子電氣系統(tǒng)失效后者面向系統(tǒng)在規(guī)范使用下仍可能出現(xiàn)的性能局限。嚴格來說ISO 26262和ISO 21448這兩類標(biāo)準是測評體系的“元規(guī)則”它們決定了測評活動本身的流程合規(guī)性。標(biāo)準是不斷演進的黑匣子別指望背下來關(guān)鍵是建立一條追蹤機制。我一般會在團隊里維護一份標(biāo)準條款與測試用例的映射表每條標(biāo)準落到具體場景、具體判據(jù)標(biāo)準一更新就回頭逐條核對映射關(guān)系。這個動作本身不復(fù)雜但沒有它測評體系很快就會變成“測了什么不知道、為什么這么測也不知道”的狀態(tài)。2.2 四層測試任務(wù)法規(guī)測試、功能測試、場景測試與預(yù)期功能安全實際工程里我不會把測評簡單理解成“拉一臺車出去跑”而是拆成四個遞進的層次層級測什么典型手段核心判據(jù)法規(guī)測試法規(guī)要求的主動安全功能封閉場地 標(biāo)準場景是否觸發(fā)、是否在要求區(qū)間內(nèi)響應(yīng)功能測試功能定義范圍內(nèi)的性能封閉場地 仿真響應(yīng)時間、控制精度、誤報率場景測試真實交通中的泛化能力場景庫 道路采集 仿真回放場景覆蓋率、危險事件率預(yù)期功能安全測試系統(tǒng)性能邊界之外的風(fēng)險邊界掃掠 故障注入 統(tǒng)計分析殘余風(fēng)險是否可接受法規(guī)測試解決“合不合法”功能測試解決“做沒做到”場景測試解決“遇到?jīng)]見過的交通情況怎么辦”預(yù)期功能安全測試解決“系統(tǒng)自己都不知道自己不行的時候怎么辦”。最后一個最常見但最容易被忽略——很多系統(tǒng)在傳感器視野、算法性能邊界之外悄悄失效沒有預(yù)期功能安全的視角單靠堆場景永遠測不完。四層測試必須配套使用不能互相替代。法規(guī)測試過了不代表場景測試能過場景測試跑得再好也不代表預(yù)期功能安全風(fēng)險已閉環(huán)。建議新團隊先做1到2層把測試基礎(chǔ)設(shè)施跑通再逐步向上疊加。2.3 測評中心的角色為什么說它是“攻守兼?zhèn)洹钡耐度搿肮ナ丶鎮(zhèn)洹边@個詞雖然不是技術(shù)參數(shù)但放在測評方向上其實很貼切?！肮ァ钡囊幻嬖谟谡l先建起高置信度的測評體系誰就有能力定義行業(yè)測試標(biāo)準、承接第三方檢測業(yè)務(wù)形成進入壁壘研發(fā)團隊也能用這套體系反過來拷問算法逼著感知、規(guī)控模塊往更難的場景迭代。“守”的一面在于不管智能駕駛走純視覺還是多傳感器、依賴高精地圖還是無圖方案最終都要用同一套測評方法來驗收測評是技術(shù)路線分叉時仍然存在的確定性需求。這也是為什么不少整車廠和供應(yīng)商寧可花大價錢自建測試團隊而不是全部委托給外部機構(gòu)——外部報告解決“能不能賣”內(nèi)部測評解決“怎么改”。兩條線一次投入兩頭受益。對于想切入這個方向的工程師來說意味著兩類機會一類是進第三方檢測機構(gòu)把單點場景做成標(biāo)準化產(chǎn)品另一類是在主機廠內(nèi)部從零搭建測評能力直接服務(wù)研發(fā)迭代這兩條路都值得投入。3. 從零搭建一套可用的測評環(huán)境真值系統(tǒng)、場景庫與最小閉環(huán)3.1 測試車輛改造真值系統(tǒng)、數(shù)據(jù)采集與時間同步把普通測試車改造成“能用來評測智能駕駛的車”最難的部分不是裝傳感器而是讓所有傳感器說實話。測評依賴真值也就是“那一刻真實世界到底是什么狀態(tài)”如果沒有高精度真值系統(tǒng)被測系統(tǒng)的輸出根本無從比對。我的常見做法是分三步走。第一步裝組合慣導(dǎo)也就是RTK差分定位加慣性測量單元用來輸出厘米級位置、速度、姿態(tài)和精確時間基準第二步同步采集CAN總線信號、攝像頭視頻、激光雷達點云和毫米波雷達目標(biāo)列表覆蓋感知和決策執(zhí)行兩側(cè)的關(guān)鍵數(shù)據(jù)第三步給所有傳感器統(tǒng)一打硬件時間戳這是最容易被輕視的一步。很多數(shù)據(jù)采集方案里視頻流有自己的時間戳CAN信號有自己的時間戳兩套時間體系差幾百毫秒很常見問題當(dāng)時看不出來一但拿去做場景回放就全亂了。時間同步的工程實現(xiàn)上首選方案是讓所有采集設(shè)備跟隨同一個時鐘源。差分GPS接收機輸出PPS脈沖或者用PTP精確時間協(xié)議把統(tǒng)一時間同步到網(wǎng)內(nèi)各設(shè)備確保各傳感器幀級對齊。做數(shù)據(jù)回放時還要再校驗一次同步偏移方法很簡單找一個急剎車片段對比CAN里的車速驟降時刻與視頻里剎車燈點亮?xí)r刻兩者差應(yīng)小于一個視頻幀。這套環(huán)境涉及不少硬件安裝和標(biāo)定工作很難一次到位。新團隊建議先用一臺車、一條固定環(huán)線、一套采集配置跑通全流程再擴展到多車多路線不要一上來就鋪開。3.2 場景庫建設(shè)從自然駕駛數(shù)據(jù)到可復(fù)現(xiàn)的測試用例測評的第二塊地基是場景庫。場景庫不是把路測數(shù)據(jù)存起來就行它的核心目標(biāo)是把真實交通里發(fā)生的事變成可復(fù)現(xiàn)、可參數(shù)化、可批量執(zhí)行的測試用例。場景來源通常有這么幾個自然駕駛數(shù)據(jù)里的典型行為片段前車急剎、鄰車切入、行人橫穿、交通事故數(shù)據(jù)里的高風(fēng)險片段、法規(guī)標(biāo)準要求的固定場景、以及針對被測系統(tǒng)弱點的對抗生成場景。其中自然駕駛數(shù)據(jù)的利用效率最高但也是最難做清理的——一段幾十公里的數(shù)據(jù)里可能只有幾秒鐘是真正有價值的場景。場景需要參數(shù)化。拿最常見的切入場景cut-in舉例不能只記“旁邊車道有車插進來”而要拆成目標(biāo)車切入時的縱向相對距離、橫向跨越速度、相對車速、自車車速、車道類型、路面附著狀態(tài)等一組參數(shù)。這樣同一個邏輯場景就能派生出幾十上百條具體用例覆蓋不同難度邊界。我個人會按“功能場景—邏輯場景—具體場景”三層來組織場景庫功能場景描述事件類別邏輯場景定義參數(shù)取值范圍具體場景給出每一組確定參數(shù)值。每次路測發(fā)現(xiàn)的新危險事件就把它沉淀為一條新的邏輯場景逐步擴大覆蓋邊界。這是一項需要長期積累的工作但也是測評能力最深的護城河。3.3 最小可用的自動化測評閉環(huán)示例測評體系的“骨架”確定后還要跑通一個最小的自動化閉環(huán)讀數(shù)據(jù)、識別場景事件、算指標(biāo)、出報告。下面給一個精簡但能直接改用的示例演示cut-in場景下“系統(tǒng)響應(yīng)時間”的評估邏輯。from dataclasses import dataclass import json dataclass class FrameData: ts: float # 本幀時間戳統(tǒng)一為UTC毫秒 ego_speed: float # 自車速度m/s ego_acc: float # 自車縱向加速度m/s2制動為負 target_lat: float # 目標(biāo)車橫向位置m自車中心線為0 target_lon: float # 目標(biāo)車縱向相對距離m自車位置為0 target_rel_v: float # 目標(biāo)相對速度m/s正為接近 def load_frames(data_dir: str, start: int 1, end: int 400): frames [] for i in range(start, end 1): with open(f{data_dir}/{i:04d}.json, r, encodingutf-8) as f: raw json.load(f) frames.append(FrameData(**raw)) return frames def is_cut_in(frame: FrameData) - bool: # 典型切入事件目標(biāo)橫向位置位于本車道邊界附近且有接近趨勢 return abs(frame.target_lat) 0.3 and frame.target_rel_v 0.5 def evaluate_cut_in_response(frames): event_start None response_time -1 for frame in frames: if is_cut_in(frame): if event_start is None: event_start frame.ts # 事件發(fā)生時刻首次越線 continue if event_start is not None and frame.ego_acc -1.0: response_time frame.ts - event_start # 系統(tǒng)開始明顯制動 break max_deceleration min(f.ego_acc for f in frames) return { cut_in_detected: event_start is not None, response_time_ms: response_time, max_deceleration_m2s: max_deceleration, } if __name__ __main__: frames load_frames(./data/cut_in_case) result evaluate_cut_in_response(frames) print(json.dumps(result, ensure_asciiFalse, indent2))代碼的邏輯不復(fù)雜逐幀讀入數(shù)據(jù)先判斷是否出現(xiàn)切入事件再找系統(tǒng)開始明顯制動的時刻兩者相減得到響應(yīng)時間。參數(shù)上注意三個地方target_lat的閾值0.3米表示目標(biāo)車已經(jīng)進入本車道邊界太小容易漏檢太大會把鄰道正常行駛也算進來target_rel_v的0.5米/秒用于過濾靜止干擾物制動判定閾值-1.0米/秒2不是隨意定的它對應(yīng)大多數(shù)人能感知到的平緩制動下限低于這個值可能是傳感器噪聲或輕微波動容易誤判。這是最簡的規(guī)則版本。實際生產(chǎn)中會替換掉硬編碼閾值事件識別交給基于目標(biāo)跟蹤的算法制動判定結(jié)合AEB觸發(fā)信號和加速度曲線斜率。但接口設(shè)計可以沿用這個思路——數(shù)據(jù)幀結(jié)構(gòu)統(tǒng)一、評價邏輯與采集格式解耦、結(jié)果輸出成標(biāo)準JSON后續(xù)換算法、換傳感器都只改局部模塊。4. 測評指標(biāo)怎么定從“能剎住”到“敢說安全”的五個關(guān)鍵指標(biāo)4.1 功能指標(biāo)觸發(fā)條件、響應(yīng)時間與控制質(zhì)量功能指標(biāo)的難點不是“有沒有指標(biāo)”而是“指標(biāo)之間會打架”。比如AEB測試只盯著“觸發(fā)距離夠不夠遠”系統(tǒng)就可能提前緩剎結(jié)果在密集車流里經(jīng)常被后車追尾只盯著“響應(yīng)時間夠不夠快”系統(tǒng)又可能頻繁誤觸發(fā)搞得駕乘體驗一塌糊涂。所以功能指標(biāo)要一組一組看不能單點考核。我常用的一組最小功能指標(biāo)是觸發(fā)條件邊界記錄系統(tǒng)觸發(fā)時的本車速度、目標(biāo)相對速度、TTC碰撞時間閾值。重點看閾值附近的表現(xiàn)通常要求臨界區(qū)內(nèi)的觸發(fā)一致性不能同一參數(shù)狀態(tài)時而觸發(fā)時而不觸發(fā)。響應(yīng)時間從事件發(fā)生到系統(tǒng)輸出控制指令的時間差。cut-in場景一般看100毫秒級差異AEB場景對響應(yīng)穩(wěn)定性要求更高跑同一場景多次時響應(yīng)時間方差不能過大。控制質(zhì)量不只問“剎沒剎住”還要看減速度曲線平滑度、橫向偏移峰值、駕駛員主觀體驗。用“最大減速度變化率”來量化粗暴程度減速度變化率超過一定閾值就觸發(fā)舒適性告警。這三類指標(biāo)的權(quán)重隨場景而變化法規(guī)測試最看重觸發(fā)條件邊界因為那是底線用戶日常體驗最看重控制質(zhì)量和誤觸發(fā)率安全評價則把響應(yīng)時間放到第一位。建議在測試規(guī)范里明確寫明每類場景的指標(biāo)優(yōu)先序才能避免開發(fā)團隊和測試團隊各說各話。4.2 場景指標(biāo)場景覆蓋率與邊界參數(shù)密度場景指標(biāo)回答的問題是我們測過的這些內(nèi)容能不能代表真實世界。兩個指標(biāo)我每次匯報時都會帶上一個是場景類型覆蓋率另一個是邊界參數(shù)密度。場景類型覆蓋率指場景庫中已覆蓋的場景類型占目標(biāo)場景清單的比例。目標(biāo)場景清單從哪里來從標(biāo)準要求加真實事故形態(tài)加路采數(shù)據(jù)聚類結(jié)果三方匯總。注意覆蓋率不等于數(shù)量同一個cut-in場景參數(shù)稍微變一變就能湊出上千條用例但那只覆蓋了一個事件類別對提升覆蓋率沒有幫助。邊界參數(shù)密度指在參數(shù)空間的邊緣區(qū)域布置的測試用例數(shù)量。算法往往在參數(shù)邊界附近失效比如目標(biāo)車切入時橫向距離剛好貼近車道線、相對速度介于“系統(tǒng)認為安全”和“實際危險”的臨界值。邊界參數(shù)密度越高越容易暴露潛在失效。我會用二維參數(shù)網(wǎng)格來審視場景庫以相對距離為橫軸、相對速度為縱軸觀察用例在網(wǎng)格中的分布凡是邊緣區(qū)域稀疏的就針對性補測試用例。4.3 統(tǒng)計指標(biāo)接管率、風(fēng)險事件率與置信區(qū)間路測積累到一定里程后就要用統(tǒng)計指標(biāo)來判斷系統(tǒng)整體表現(xiàn)。最?？吹氖敲壳Ч锝庸艽螖?shù)和危險事件率。接管次數(shù)統(tǒng)計的是系統(tǒng)請求駕駛員接管或駕駛員因不信任而主動接管的次數(shù)危險事件率則統(tǒng)計路測中出現(xiàn)的近距離切入、急剎、偏離車道等風(fēng)險事件。這里有個容易翻車的細節(jié)統(tǒng)計指標(biāo)必須有明確的定義邊界否則數(shù)據(jù)之間完全不可比。比如接管要區(qū)分“系統(tǒng)請求的被動接管”和“駕駛員主動接管”兩者含義完全不同再比如危險事件必須明確定義TTC閾值和事件持續(xù)時間不然同一段路測數(shù)據(jù)兩個人能統(tǒng)計出兩個結(jié)果。另一個是置信區(qū)間問題。路測里程再長抽樣偏差始終存在。1000公里合法里程里零接管并不代表每千公里接管率真的為零樣本量不足時這個結(jié)論非常脆弱。我一般會先設(shè)定可接受的失效率上限再反推所需的最低測試里程而不是跑完多少算多少。這也是測評報告里最容易被外部專家質(zhì)疑的地方提前算清楚才能站得住腳。5. 智能駕駛測評避坑指南五個讓人翻車的常見問題5.1 場景復(fù)現(xiàn)不了先查傳感器時間同步現(xiàn)象同一個測試場景同一套軟件版本上午跑一遍系統(tǒng)觸發(fā)了AEB下午再跑一遍相同場景系統(tǒng)沒反應(yīng)。換了駕駛員、換了測試車也無規(guī)律完全沒有復(fù)現(xiàn)性。原因最初懷疑是算法問題查了很久才發(fā)現(xiàn)是時間同步漂移。車載攝像頭時間戳來自系統(tǒng)時鐘CAN信號時間戳來自CAN網(wǎng)關(guān)兩套時間相差約600毫秒?；胤艜r事件檢測模塊先看到的是晚到的目標(biāo)信息導(dǎo)致場景狀態(tài)和實際車輛狀態(tài)錯位觸發(fā)邏輯時好時壞。解決從采集源頭統(tǒng)一所有傳感器的時間基準用差分GPS或PTP做硬件同步并在數(shù)據(jù)回放前加“同步校驗”步驟。日常排障建議把時間戳對齊檢查做成自動化腳本每次回放前先計算視頻關(guān)鍵事件與CAN信號關(guān)鍵事件的時間偏移超過閾值直接拒絕回放。5.2 結(jié)果不穩(wěn)定把道路測試當(dāng)臺架測試用現(xiàn)象同一版本軟件上周路測表現(xiàn)優(yōu)秀這周換了一條路、換了個時段指標(biāo)直接下滑一截。開發(fā)團隊拿著報告找測試團隊理論雙方各執(zhí)一詞。原因道路測試的環(huán)境變量太多交通流密度、日照角度、路面狀態(tài)、隨機目標(biāo)物都會影響智能駕駛表現(xiàn)。拿道路測試數(shù)據(jù)做“版本好壞”的判斷本質(zhì)上是在拿隨機樣本做統(tǒng)計推斷樣本量不夠時結(jié)果必然不穩(wěn)定。解決把“評審版本”和“抽樣驗證”分開。版本通過與否以仿真回歸測試為基準——固定場景庫、固定參數(shù)、固定評價邏輯保證可復(fù)現(xiàn)道路測試只做抽樣驗證和未知場景發(fā)現(xiàn)。道路測試報告里必須記錄交通流密度、天氣、光照、時間段并注明該批次結(jié)果不對應(yīng)版本結(jié)論。5.3 場景參數(shù)太隨意測出來好看、上路不好用現(xiàn)象某系統(tǒng)在內(nèi)部所有cut-in測試中都表現(xiàn)良好一到開放道路就頻繁出現(xiàn)“反應(yīng)太晚”的抱怨。測試團隊一開始覺得是用戶故意刁難后來才發(fā)現(xiàn)真實路況的cut-in參數(shù)比測試場景激進得多。原因場景參數(shù)是按“理想情況”設(shè)計的比如目標(biāo)車緩緩切入、橫向距離剛好壓線、相對速度卻遠低于真實博弈場景中的速度。這種參數(shù)下系統(tǒng)有充足時間響應(yīng)測試自然全過但也完全沒有暴露性能邊界。解決參數(shù)必須從真實路采數(shù)據(jù)里提取分布不要憑直覺填表。把路測數(shù)據(jù)中所有cut-in事件的橫向距離、縱向距離、相對速度做分位數(shù)統(tǒng)計取5%到95%分位范圍作為測試參數(shù)矩陣。同時定期用新采集數(shù)據(jù)校準參數(shù)分布防止場景庫逐漸偏離真實路況。5.4 標(biāo)注口徑不統(tǒng)一同一指標(biāo)橫跳的源頭現(xiàn)象同一批點云數(shù)據(jù)兩個月后再標(biāo)注一遍目標(biāo)物數(shù)量、類別分布和之前差異很大。用新舊標(biāo)注分別評測同一套感知算法AEB誤觸發(fā)率指標(biāo)一個高一個低不知道系統(tǒng)真實水平是什么。原因不同標(biāo)注員對“遮擋目標(biāo)”“遠距離小目標(biāo)”“部分可見目標(biāo)”的處理標(biāo)準不一致。有的人只要點云夠幾個點就標(biāo)有的人要求目標(biāo)輪廓完整才算數(shù)。沒有統(tǒng)一標(biāo)注規(guī)范數(shù)據(jù)質(zhì)量完全取決于執(zhí)行者個人尺度和當(dāng)日狀態(tài)。解決先定分類樹明確每個目標(biāo)類別的邊界和最小標(biāo)注要求再跑一致性檢驗用同一批數(shù)據(jù)進行重復(fù)標(biāo)注計算標(biāo)注一致率不一致的樣本強制復(fù)審。關(guān)鍵數(shù)據(jù)集的標(biāo)注規(guī)范要凍結(jié)版本數(shù)據(jù)更新時標(biāo)注規(guī)范本身不能隨意改這樣才能保證前后指標(biāo)可比。5.5 只看功能通過率漏了預(yù)期功能安全評估現(xiàn)象某系統(tǒng)在所有標(biāo)準法規(guī)測試、功能測試中全部通過AEB觸發(fā)距離、響應(yīng)時間都在目標(biāo)范圍內(nèi)但在一個普通雨夜場景中系統(tǒng)對路面積水反光產(chǎn)生誤識別出現(xiàn)一次不必要的緊急制動。原因測試矩陣覆蓋了“系統(tǒng)應(yīng)該會做什么”但沒有覆蓋“系統(tǒng)在什么條件下不知道自己做不到”。雨夜反光導(dǎo)致傳感器產(chǎn)生虛假目標(biāo)感知模塊置信度不夠高卻仍然輸出了危險目標(biāo)規(guī)控模塊按正常邏輯觸發(fā)制動整套鏈路“功能正?！钡w行為錯誤。解決引入預(yù)期功能安全視角給感知、決策、執(zhí)行各環(huán)節(jié)建立性能邊界清單專門設(shè)計“邊界掃掠”用例。比如把傳感器退化條件雨霧、逆光、低對比度和場景條件做成交叉矩陣逐格掃過找出“看起來正常、實際不可信”的盲區(qū)。這類測試更應(yīng)該納入版本準入條件因為它暴露的正是真實路測中最危險的那類事故。6. 把測評沉淀成能力一份可復(fù)現(xiàn)測試規(guī)范的最小樣本測評做到最后拼的不是某一次測試做得多漂亮而是能不能讓測試結(jié)果長期穩(wěn)定可信。我的習(xí)慣是每接手一個項目第一件事先沉淀一份可復(fù)現(xiàn)的測試規(guī)范讓后來者拿著文檔就能復(fù)現(xiàn)結(jié)果而不是依賴某個測試工程師的經(jīng)驗。一份最小可用規(guī)范至少包含這幾個部分模塊要寫清楚的內(nèi)容示例測試目的本次測試要回答什么問題驗證V2.3版本在雨天cut-in場景下的響應(yīng)表現(xiàn)前置條件車輛狀態(tài)、軟件版本、場地、氣象封閉場地濕滑路面軟件版本V2.3.1場景矩陣場景編號、參數(shù)組合、來源CutIn_023相對距離8-12m相對速度15-20km/h數(shù)據(jù)記錄記錄哪些信號、采樣率、格式CAN、視頻、點云全部帶統(tǒng)一時間戳通過判據(jù)每個指標(biāo)的合格線響應(yīng)時間≤600ms無危險事件回歸觸發(fā)什么條件下需要重跑感知、規(guī)控算法變更后全量重跑制定規(guī)范時的關(guān)鍵原則是一切判據(jù)要寫在執(zhí)行之前不允許在跑完數(shù)據(jù)之后再“根據(jù)數(shù)據(jù)表現(xiàn)”調(diào)整閾值否則指標(biāo)會不斷向系統(tǒng)能力妥協(xié)測評就失去了拷問系統(tǒng)的意義。我在團隊里定死了一條規(guī)矩測試參數(shù)和判據(jù)變更必須走評審流程禁止個人在執(zhí)行過程中臨時修改。還有一條重要經(jīng)驗把每次回歸測試的輸入和輸出連同軟件版本一起歸檔。三個月后有人質(zhì)疑某個指標(biāo)是當(dāng)時“測錯了”時能快速調(diào)出當(dāng)時的數(shù)據(jù)包、場景參數(shù)和軟件版本號直接重跑驗證最有說服力。數(shù)據(jù)閉環(huán)的鏈路我也一直在維護路測發(fā)現(xiàn)異常片段 → 沉淀為場景用例 → 加入回歸場景庫 → 新版軟件必須重跑。這個循環(huán)跑得越順暢測評能力的護城河越深我自己在這上面的投入也最值得。希望幫到你。本文還有配套的精品資源點擊獲取