簡(jiǎn)介本資源是一套面向自動(dòng)駕駛算法工程師與仿真測(cè)試開(kāi)發(fā)者的PreScan C自動(dòng)化測(cè)試實(shí)戰(zhàn)教程聚焦于通過(guò)C腳本高效構(gòu)建、執(zhí)行與驗(yàn)證仿真測(cè)試用例解決手動(dòng)調(diào)試耗時(shí)長(zhǎng)、場(chǎng)景復(fù)現(xiàn)難、模塊驗(yàn)證不系統(tǒng)等工程痛點(diǎn)。資源包共1729個(gè)文件以1367個(gè)HTML文檔含Doxygen生成的API參考手冊(cè)如prescan__api__scenario_8h.html、prescan__api__cameraparameters_8h.html等、190張PNG示意圖及169個(gè)JS交互腳本為主完整呈現(xiàn)模塊測(cè)試Demo代碼邏輯、API調(diào)用鏈路與測(cè)試結(jié)果可視化流程壓縮包僅3.67MB輕量易部署。已有1695人學(xué)習(xí)下載內(nèi)容覆蓋傳感器建模、車輛動(dòng)力學(xué)控制、多模塊協(xié)同觸發(fā)等典型測(cè)試場(chǎng)景提供可直接運(yùn)行的C腳本模板、標(biāo)準(zhǔn)化測(cè)試流程定義方法及仿真數(shù)據(jù)解析范例助力開(kāi)發(fā)者快速掌握PreScan底層接口調(diào)用與自動(dòng)化測(cè)試體系搭建能力。 做自動(dòng)駕駛仿真測(cè)試的朋友應(yīng)該都有過(guò)這種經(jīng)歷在PreScan里手動(dòng)拖場(chǎng)景、擺放傳感器、調(diào)參數(shù)、點(diǎn)運(yùn)行然后瞪大眼睛盯著仿真窗口看結(jié)果。單跑一兩個(gè)場(chǎng)景還好一旦進(jìn)入版本回歸或者算法迭代階段幾十上百個(gè)用例全靠手點(diǎn)那基本就是災(zāi)難現(xiàn)場(chǎng)。我之前負(fù)責(zé)過(guò)一個(gè)AEB系統(tǒng)的功能驗(yàn)證光場(chǎng)景矩陣就排了三十多組每組還要換車速、換距離、換天氣手動(dòng)跑完全部流程至少得一周而且中間稍微點(diǎn)錯(cuò)一步就得推倒重來(lái)。后來(lái)我把整套流程搬到了C腳本自動(dòng)化測(cè)試上用PreScan搭建場(chǎng)景把待測(cè)模塊編譯成C代碼再通過(guò)外部C程序統(tǒng)一調(diào)度仿真、注入控制指令、采集傳感器輸出、自動(dòng)斷言測(cè)試結(jié)果。跑完三十組場(chǎng)景從一周壓縮到了幾個(gè)小時(shí)而且全部是無(wú)人值守。這篇文章就是想把這條路線完整地拆開(kāi)講清楚從環(huán)境準(zhǔn)備、通信機(jī)制到模塊測(cè)試Demo、模塊調(diào)用方式再到CI集成和一堆實(shí)際踩坑經(jīng)驗(yàn)。內(nèi)容適合正在做PreScan二次開(kāi)發(fā)或仿真測(cè)試自動(dòng)化又對(duì)C有一定基礎(chǔ)的工程師參考。1. 為什么我最終選了C這條路線做PreScan自動(dòng)化測(cè)試先說(shuō)結(jié)論P(yáng)reScan本身并不是一個(gè)只能靠GUI點(diǎn)點(diǎn)點(diǎn)的工具它背后有一套完整的腳本化和代碼化能力。只是國(guó)內(nèi)很多教程停留在“怎么搭場(chǎng)景、怎么出動(dòng)畫(huà)”的層面很少有人把“用代碼驅(qū)動(dòng)PreScan做測(cè)試”這條路走通。我當(dāng)年也是對(duì)比了好幾條路才定下來(lái)用C這里把當(dāng)時(shí)的技術(shù)選型邏輯說(shuō)清楚。1.1 三條主流路線的對(duì)比第一條路線是MATLAB/Simulink腳本。PreScan和MATLAB/Simulink是深度綁定的場(chǎng)景里的傳感器、車輛動(dòng)力學(xué)、V2X通信都通過(guò)Simulink模型流轉(zhuǎn)。很多測(cè)試腳本也是用.m文件寫(xiě)的好處是跟模型貼合緊密改參數(shù)方便壞處也明顯跑自動(dòng)化測(cè)試的機(jī)器必須裝完整版MATLAB和SimulinkLicense成本高而且.m腳本跑起來(lái)偏慢模型大了之后每一步都在跟MATLAB解釋器打交道。第二條路線是Python API。PreScan在較新版本里提供了Python接口可以加載實(shí)驗(yàn)、改場(chǎng)景參數(shù)、啟動(dòng)仿真。對(duì)于快速寫(xiě)測(cè)試腳本來(lái)說(shuō)Python確實(shí)舒服團(tuán)隊(duì)里會(huì)的人也更多。但它的問(wèn)題在于一旦你的測(cè)試對(duì)象是編譯后的C模型比如從Simulink生成的代碼或者你要跟其他C測(cè)試框架、CI系統(tǒng)做深度集成Python API這層就有點(diǎn)隔靴搔癢最后還得回到C/C層去處理。第三條路線就是C編譯模型加外部測(cè)試程序。PreScan 8.x之后的版本支持把Simulink模型編譯成C/C代碼生成獨(dú)立可執(zhí)行的仿真程序。你的場(chǎng)景、傳感器模型、控制算法全都編譯進(jìn)去了運(yùn)行時(shí)可以完全不依賴MATLAB環(huán)境。外部再寫(xiě)一個(gè)C測(cè)試控制端通過(guò)UDP、TCP或者共享內(nèi)存跟仿真程序通信該發(fā)指令發(fā)指令該收數(shù)據(jù)收數(shù)據(jù)該斷言斷言。這條路的優(yōu)點(diǎn)是性能好、可部署性極強(qiáng)、跟Jenkins這類CI系統(tǒng)打通非常順而且代碼風(fēng)格跟量產(chǎn)車上的C代碼鏈路是一致的你測(cè)的東西和最終上車的東西之間鴻溝最小。1.2 我選擇C的幾個(gè)實(shí)際考量性能只是其中一個(gè)因素真正讓我定下來(lái)的是下面這幾點(diǎn)第一回歸測(cè)試的體量根本不支持每次全量啟動(dòng)MATLAB。我們的場(chǎng)景庫(kù)大概有四五百條用例如果每條用例都從MATLAB冷啟動(dòng)光啟動(dòng)就吃掉大部分時(shí)間。編譯成C exe之后每條用例的啟動(dòng)時(shí)間可以壓到幾秒鐘而且是脫離GUI跑的穩(wěn)定性高很多。第二測(cè)試斷言邏輯需要跨語(yǔ)言復(fù)用。我們團(tuán)隊(duì)有從感知到規(guī)控多個(gè)模塊的測(cè)試大家的日志格式、斷言標(biāo)準(zhǔn)、上報(bào)方式都是C統(tǒng)一的測(cè)試端也用C最省事。你說(shuō)用Python寫(xiě)斷言也行但最終嵌入到已有的C測(cè)試框架里還是有轉(zhuǎn)換成本。第三也是最重要的一點(diǎn)無(wú)人值守時(shí)GUI模式根本不可靠。仿真跑著跑著彈出一個(gè)錯(cuò)誤對(duì)話框整個(gè)任務(wù)掛在那里等人工點(diǎn)確定這在CI里就是災(zāi)難。C編譯產(chǎn)物配合命令行參數(shù)和靜默模式是完全不需要界面交互的天然適合自動(dòng)化。當(dāng)然這條路的前期學(xué)習(xí)曲線確實(shí)比MATLAB腳本要高不少你要同時(shí)熟悉PreScan的編譯流程、Visual Studio的工程配置、還有進(jìn)程間通信。但整套東西一旦搭好收益是幾何級(jí)別的后面所有場(chǎng)景都可以往這個(gè)框架里疊。2. 環(huán)境準(zhǔn)備Visual Studio版本匹配和C Runtime坑PreScan用C做自動(dòng)化測(cè)試第一步要過(guò)的不是代碼關(guān)而是環(huán)境關(guān)。這個(gè)環(huán)境坑攔住了不少人而且網(wǎng)上資料相對(duì)零散我在這里把關(guān)鍵點(diǎn)集中講一遍。2.1 版本匹配是第一優(yōu)先級(jí)PreScan每個(gè)大版本對(duì)Visual Studio的版本要求是明確的不能隨便拿一個(gè)VS就開(kāi)干。比如PreScan 8.x系列不同小版本對(duì)應(yīng)的VS從2015到2017、2019都有PreScan 2020之后對(duì)VS2019支持更完整。我當(dāng)前主力環(huán)境是PreScan 2021.1配Visual Studio 2019社區(qū)版這個(gè)組合在C編譯和仿真運(yùn)行時(shí)表現(xiàn)最穩(wěn)定。版本不匹配的典型癥狀是編譯報(bào)一堆莫名其妙的錯(cuò)誤或者編譯產(chǎn)物在另外一臺(tái)機(jī)器上運(yùn)行時(shí)提示找不到vcruntime140.dll、msvcp140.dll。這類問(wèn)題十有八九是VS工具集版本和PreScan編譯產(chǎn)物依賴的Runtime不一致導(dǎo)致的。建議安裝順序先裝Visual Studio確認(rèn)C桌面開(kāi)發(fā)工作負(fù)載和對(duì)應(yīng)Windows SDK都裝好再裝PreScan。PreScan安裝過(guò)程中會(huì)檢測(cè)VS環(huán)境如果檢測(cè)不到說(shuō)明你的VS版本不對(duì)或者組件不完整。提示Visual Studio社區(qū)版足夠用不需要企業(yè)版。重點(diǎn)是把“使用C的桌面開(kāi)發(fā)”工作負(fù)載選上里面有MSBuild、Windows SDK、標(biāo)準(zhǔn)庫(kù)頭文件這些核心組件。2.2 Visual C Redistributable的隱性依賴PreScan編譯出來(lái)的exe在部署到其他測(cè)試機(jī)器上時(shí)目標(biāo)機(jī)器上必須裝對(duì)應(yīng)版本的Visual C Redistributable。我做自動(dòng)化測(cè)試時(shí)會(huì)準(zhǔn)備一臺(tái)干凈的“跑批機(jī)器”上面不裝VS只裝Runtime。曾經(jīng)在這臺(tái)機(jī)器上跑編譯出來(lái)的仿真程序啟動(dòng)就報(bào)“0xc000007b”錯(cuò)誤查了半天是x86和x64的Runtime版本混了。后來(lái)我統(tǒng)一裝了VS2015-2022合并版Redistributable x64微軟官方提供聚合包才徹底解決。這條經(jīng)驗(yàn)也適用于團(tuán)隊(duì)內(nèi)部共享測(cè)試機(jī)。凡是跑PreScan C自動(dòng)化測(cè)試的機(jī)器第一步就是確認(rèn)Runtime版本其次才是確認(rèn)PreScan裝沒(méi)裝。2.3 工具鏈進(jìn)PATH換臺(tái)機(jī)器就“命令找不到”的坑如果你用命令行方式啟動(dòng)仿真程序自動(dòng)化測(cè)試必須走命令行相關(guān)工具鏈必須加進(jìn)系統(tǒng)的PATH環(huán)境變量。這個(gè)坑我以前沒(méi)注意換了一臺(tái)新機(jī)器部署腳本后腳本里調(diào)用某個(gè)DLL或者exe時(shí)系統(tǒng)提示“無(wú)法識(shí)別”跟網(wǎng)上常說(shuō)的“npm無(wú)法識(shí)別為cmdlet、函數(shù)、腳本文件或可運(yùn)行程序的名稱”是一個(gè)道理——不是工具不存在是路徑?jīng)]進(jìn)PATH或者當(dāng)前終端會(huì)話沒(méi)有重新加載環(huán)境變量。我的做法是在測(cè)試機(jī)上建一個(gè)prescan_env.bat里面把所有需要的路徑一次性設(shè)置好每次跑CI任務(wù)前先調(diào)用它set PRESCAN_HOMEC:\Program Files\PreScan set VS_MSBUILDC:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\MSBuild.exe set PATH%PRESCAN_HOME%;%VS_MSBUILD%;%PATH%這樣一來(lái)無(wú)論是Jenkins還是手動(dòng)跑批每次都能拿到干凈的構(gòu)建環(huán)境不會(huì)因?yàn)槟骋淮问謩?dòng)配置遺漏導(dǎo)致整個(gè)流水線掛掉。2.4 VS工程的核心配置項(xiàng)當(dāng)你開(kāi)始新建C測(cè)試工程有幾個(gè)配置項(xiàng)需要特別注意平臺(tái)選x64PreScan編譯產(chǎn)物的位數(shù)必須跟測(cè)試程序一致32位和64位混用會(huì)導(dǎo)致內(nèi)存映射失敗附加包含目錄要指向PreScan安裝目錄下的Application和Data相關(guān)路徑因?yàn)槔锩嬗行╊^文件比如傳感器數(shù)據(jù)結(jié)構(gòu)在編譯時(shí)要用附加庫(kù)目錄指向PreScan安裝目錄下的庫(kù)文件位置如果你的測(cè)試程序要調(diào)PreScan的API比如修改場(chǎng)景參數(shù)還需要把對(duì)應(yīng)的.lib加入鏈接器輸入。這些配置在不同版本里路徑稍有差異核心原則是以你安裝的PreScan目錄下的實(shí)際頭文件和庫(kù)文件路徑為準(zhǔn)不要在VS里寫(xiě)死某個(gè)舊版本路徑否則升級(jí)PreScan后整個(gè)工程編譯不過(guò)去。3. PreScan與C之間的信息通道TCP、UDP和共享內(nèi)存怎么選環(huán)境搭好之后接下來(lái)要解決的是數(shù)據(jù)怎么從PreScan仿真程序里出來(lái)進(jìn)到我們的C測(cè)試程序里。這是整個(gè)自動(dòng)化測(cè)試體系的地基。3.1 PreScan的數(shù)據(jù)出口PreScan場(chǎng)景里的攝像頭、激光雷達(dá)、毫米波雷達(dá)、GPS/IMU這些傳感器數(shù)據(jù)都會(huì)進(jìn)到Simulink模型里。如果你想讓外部C程序讀取這些數(shù)據(jù)通常有兩條路一條是在Simulink模型里放置PreScan自帶的外部通信模塊比如TCP/UDP Sender把傳感器原始輸出或后處理結(jié)果直接發(fā)到指定端口另一條是通過(guò)PreScan與Simulink之間的共享內(nèi)存接口把數(shù)據(jù)寫(xiě)到一塊約定的內(nèi)存區(qū)C程序直接映射這塊內(nèi)存來(lái)讀。我在項(xiàng)目里一般都走外部通信模塊這條路因?yàn)樗庇^、可控而且天然支持跨機(jī)器部署比如一臺(tái)機(jī)器跑仿真另一臺(tái)機(jī)器跑測(cè)試控制端。共享內(nèi)存在單機(jī)高性能場(chǎng)景下效率極高但跨機(jī)器就無(wú)能為力了。3.2 三種通道的對(duì)比和選型邏輯通道類型實(shí)時(shí)性跨機(jī)器支持復(fù)雜度適合場(chǎng)景UDP高但有丟包風(fēng)險(xiǎn)支持低傳感器數(shù)據(jù)量大的廣播場(chǎng)景單機(jī)或局域網(wǎng)內(nèi)跑批TCP中可靠傳輸支持中控制指令、調(diào)試日志、需要對(duì)包做可靠校驗(yàn)的場(chǎng)景共享內(nèi)存最高納秒級(jí)不支持中單機(jī)跑大規(guī)模傳感器數(shù)據(jù)如激光雷達(dá)點(diǎn)云時(shí)的首選我慣用的組合是傳感器數(shù)據(jù)走UDP或共享內(nèi)存控制指令走TCP。原因很簡(jiǎn)單傳感器數(shù)據(jù)量往往很大激光雷達(dá)一幀幾千個(gè)點(diǎn)攝像頭一幀幾十萬(wàn)字節(jié)用TCP保證可靠性但會(huì)拖累吞吐控制指令量小但絕對(duì)不能丟所以走TCP讓協(xié)議棧來(lái)保證可靠性。3.3 數(shù)據(jù)格式設(shè)計(jì)字節(jié)對(duì)齊和字節(jié)序的教訓(xùn)通信通道定了之后數(shù)據(jù)格式是另一個(gè)大坑。PreScan的輸出是float或double數(shù)組比如雷達(dá)輸出目標(biāo)距離、相對(duì)速度、方位角攝像頭輸出車道線系數(shù)IMU輸出加速度和角速度。C這邊要把這些值映射成結(jié)構(gòu)體。這里有一個(gè)很多人會(huì)踩的坑結(jié)構(gòu)體字節(jié)對(duì)齊。默認(rèn)情況下C編譯器會(huì)在結(jié)構(gòu)體成員之間插入填充字節(jié)如果PreScan發(fā)送端是多字節(jié)連續(xù)buffer而你的C接收端是帶對(duì)齊的結(jié)構(gòu)體兩邊對(duì)不上數(shù)據(jù)解析就是錯(cuò)亂的。我曾經(jīng)因?yàn)槁┝?pragma pack雷達(dá)目標(biāo)的速度值讀出來(lái)全是不合理數(shù)字排查了半天才意識(shí)到是結(jié)構(gòu)體對(duì)齊問(wèn)題。所以我在定義通信協(xié)議結(jié)構(gòu)體時(shí)一律這么做#pragma pack(push, 1) struct RadarTarget { float range; // 目標(biāo)距離單位米 float velocity; // 相對(duì)速度單位m/s float azimuth; // 方位角單位弧度 int targetId; // 目標(biāo)ID unsigned char status; // 狀態(tài)標(biāo)志位 }; #pragma pack(pop)字節(jié)序問(wèn)題相對(duì)少見(jiàn)因?yàn)镻reScan和C測(cè)試程序通常跑在同架構(gòu)的Windows機(jī)器上只要不跨平臺(tái)都不會(huì)遇到大小端不一致的問(wèn)題。但如果你的場(chǎng)景里有嵌入式設(shè)備或者Linux機(jī)器就一定記得在協(xié)議里寫(xiě)明字節(jié)序并加一個(gè)magic number做校驗(yàn)。3.4 一個(gè)簡(jiǎn)單的UDP接收端示例下面這是我在測(cè)試程序里實(shí)際用過(guò)的UDP接收代碼骨架主要負(fù)責(zé)接收PreScan發(fā)出的仿真狀態(tài)和傳感器數(shù)據(jù)#include winsock2.h #pragma comment(lib, ws2_32.lib) #include cstdio #include cstring #pragma pack(push, 1) struct SimStatus { double simTime; // 仿真時(shí)間單位秒 float egoSpeed; // 自車速度 float egoSteerAngle; // 自車轉(zhuǎn)向角 int frameId; // 幀序號(hào) }; #pragma pack(pop) int main() { WSADATA wsaData; WSAStartup(MAKEWORD(2, 2), wsaData); SOCKET sock socket(AF_INET, SOCK_DGRAM, 0); sockaddr_in localAddr{}; localAddr.sin_family AF_INET; localAddr.sin_port htons(5600); localAddr.sin_addr.s_addr htonl(INADDR_ANY); bind(sock, (sockaddr*)localAddr, sizeof(localAddr)); char buf[256]; SimStatus status; while (true) { int len recvfrom(sock, buf, sizeof(buf), 0, nullptr, nullptr); if (len sizeof(SimStatus)) { memcpy(status, buf, sizeof(SimStatus)); printf(t%.3f v%.2f steer%.4f frame%d\n, status.simTime, status.egoSpeed, status.egoSteerAngle, status.frameId); } } return 0; }這個(gè)示例的核心價(jià)值不在于代碼本身而在于演示了“PreScan發(fā)送、C接收”這種解耦關(guān)系。測(cè)試程序只需要關(guān)心端口號(hào)和結(jié)構(gòu)體定義完全不需要理解PreScan內(nèi)部怎么跑這是自動(dòng)化測(cè)試可以穩(wěn)定運(yùn)行的前提。4. 模塊測(cè)試Demo搭一個(gè)車道保持模塊的C測(cè)試用例環(huán)境通了、通信方式定了現(xiàn)在進(jìn)入正題怎么測(cè)一個(gè)具體模塊。我拿車道保持Lane Keeping Assist模塊舉例演示從PreScan場(chǎng)景到C測(cè)試用例的完整鏈路。4.1 場(chǎng)景側(cè)的準(zhǔn)備在PreScan GUI里搭一個(gè)直道場(chǎng)景道路畫(huà)三條車道線自車起始位置在中間車道初始橫向偏移給一點(diǎn)比如0.3米這樣LKA模塊有糾偏的必要。車速設(shè)成80km/h仿真時(shí)長(zhǎng)15秒。傳感器用前視攝像頭放在車頭擋風(fēng)玻璃位置檢測(cè)車道線輸出車道橫向偏移量、車道曲率和航向角偏差。這些量會(huì)進(jìn)Simulink模型。在Simulink模型里把攝像頭輸出接到一個(gè)LKA控制算法可以是PreScan自帶的模板也可以是你自己開(kāi)發(fā)的Simulink模塊算法輸出目標(biāo)方向盤(pán)轉(zhuǎn)角接到車輛的轉(zhuǎn)向執(zhí)行器。為了讓C測(cè)試程序能控制測(cè)試流程我在模型里加了一個(gè)外部接口輸入端口外部控制允許標(biāo)志位1表示允許LKA介入輸出端口LKA激活狀態(tài)、目標(biāo)轉(zhuǎn)角、實(shí)際轉(zhuǎn)角、橫向偏移量。這樣就把待測(cè)模塊的邊界定義清楚了輸入端是外部使能信號(hào)輸出端是模塊行為和效果指標(biāo)。4.2 編譯成C仿真程序Simulink模型擺好后在PreScan里選擇編譯生成C代碼。這個(gè)過(guò)程PreScan會(huì)調(diào)用VS的編譯器把整個(gè)模型編譯成一個(gè)可執(zhí)行的仿真程序或者動(dòng)態(tài)庫(kù)。編譯時(shí)間取決于模型復(fù)雜度這個(gè)例子大約兩分鐘。編譯完成后你會(huì)得到一個(gè)帶命令行參數(shù)的exe。啟動(dòng)時(shí)指定實(shí)驗(yàn)文件名ExSimulationRun.exe -experiment LaneKeepingDemo.pb后面可以跟-silent這種參數(shù)表示靜默運(yùn)行不彈GUI。我從這以后所有自動(dòng)化測(cè)試都默認(rèn)加靜默模式杜絕了彈窗掛任務(wù)的問(wèn)題。4.3 C測(cè)試控制程序的完整結(jié)構(gòu)測(cè)試控制程序要做的事情很清晰啟動(dòng)仿真進(jìn)程、建立通信、按測(cè)試步驟注入指令、讀取狀態(tài)并斷言、最后結(jié)束仿真生成報(bào)告。核心代碼框架大致是這樣// LKA_module_test.cpp #include windows.h #include tlhelp32.h #include winsock2.h #pragma comment(lib, ws2_32.lib) #include cstdio #include thread #include chrono // 與PreScan模型中的外部接口定義保持一致 #pragma pack(push, 1) struct ModuleInput { int enableFlag; // 1允許LKA介入 int reserved[7]; }; struct ModuleOutput { double simTime; float lkaActive; // LKA是否激活 float targetSteer; // 目標(biāo)轉(zhuǎn)角 float actualSteer; // 實(shí)際轉(zhuǎn)角 float lateralOffset; // 橫向偏移量 int frameId; }; #pragma pack(pop) int main() { // 1. 啟動(dòng)PreScan仿真進(jìn)程 STARTUPINFO si{sizeof(si)}; PROCESS_INFORMATION pi; char cmdLine[] SimulationRun.exe -experiment LaneKeepingDemo.pb -silent; if (!CreateProcess(nullptr, cmdLine, nullptr, nullptr, FALSE, 0, nullptr, nullptr, si, pi)) { printf(Failed to start Prescan simulation.\n); return -1; } CloseHandle(pi.hThread); // 2. 建立TCP連接控制通道 // 這里用socket連接仿真程序的9999端口代碼略 // 3. 等待仿真就緒讀取初始輸出 bool simReady false; for (int i 0; i 50; i) { // 嘗試讀取ModuleOutput若simTime 0則認(rèn)為就緒 // 如果讀到有效數(shù)據(jù)simReady true; break; std::this_thread::sleep_for(std::chrono::milliseconds(200)); } if (!simReady) { printf(Simulation not ready in time.\n); TerminateProcess(pi.hProcess, -1); return -2; } // 4. 注入使能信號(hào)讓LKA開(kāi)始工作 ModuleInput input{}; input.enableFlag 1; // 發(fā)送到仿真程序代碼略 // 5. 持續(xù)監(jiān)控輸出執(zhí)行斷言 bool passed true; for (int frame 0; frame 750; frame) { // 15s * 50Hz ModuleOutput out{}; // 從TCP讀取輸出數(shù)據(jù)代碼略 // 橫向偏移量應(yīng)逐漸收斂到0附近 if (frame 100 frame 700) { if (out.lateralOffset 0.5f || out.lateralOffset -0.5f) { passed false; printf(FAIL at frame %d, lateralOffset %.3f\n, frame, out.lateralOffset); break; } } std::this_thread::sleep_for(std::chrono::milliseconds(20)); } // 6. 清理并輸出結(jié)果 input.enableFlag 0; // 發(fā)送停止信號(hào) TerminateProcess(pi.hProcess, -1); printf(Test %s\n, passed ? PASS : FAIL); return passed ? 0 : 1; }代碼不算復(fù)雜但有幾個(gè)關(guān)鍵點(diǎn)值得展開(kāi)說(shuō)。4.4 斷言設(shè)計(jì)別只盯著單個(gè)數(shù)據(jù)點(diǎn)初學(xué)者寫(xiě)斷言最容易犯的錯(cuò)是在某個(gè)時(shí)間點(diǎn)采集一個(gè)值如果小于閾值就算通過(guò)。這在仿真測(cè)試?yán)锖懿豢孔V因?yàn)閭鞲衅饔性肼暱刂扑惴ǖ捻憫?yīng)有動(dòng)態(tài)過(guò)程單個(gè)點(diǎn)的瞬時(shí)值可能毫無(wú)意義。我寫(xiě)斷言的思路是分三層第一層模塊行為斷言。比如LKA被激活后目標(biāo)轉(zhuǎn)角不能突跳超過(guò)某個(gè)限值比如0.3弧度這能抓到控制指令抖振和異常突變。第二層控制效果斷言。比如橫向偏移量應(yīng)該在3秒內(nèi)收斂到±0.3米以內(nèi)而不是一開(kāi)始就必須小于某個(gè)值。這稱為“時(shí)間窗口閾值”的斷言方式更能反映控制系統(tǒng)收斂性。第三層穩(wěn)定性斷言。在最后5秒內(nèi)橫向偏移量的方差不能超過(guò)某個(gè)值避免出現(xiàn)持續(xù)震蕩卻恰好沒(méi)越界的情況。如果只做第一層和第二層某些不穩(wěn)的模塊也可能蒙混過(guò)關(guān)把第三層加進(jìn)去整個(gè)測(cè)試的嚴(yán)謹(jǐn)度就上來(lái)了。5. 模塊調(diào)用教程共享內(nèi)存與單一實(shí)例管理器標(biāo)題里還特別提到了“模塊調(diào)用教程”這個(gè)“模塊調(diào)用”在PreScan的語(yǔ)境里其實(shí)包含兩種含義我把兩種都講清楚。5.1 含義一C測(cè)試程序調(diào)用PreScan編譯產(chǎn)物的API這是最常見(jiàn)的一種也是我在前一章展示的方式PreScan把Simulink模型編譯成exe或DLLC測(cè)試程序通過(guò)進(jìn)程間通信UDP/TCP/共享內(nèi)存調(diào)用它。這種調(diào)用的本質(zhì)是外部程序跟仿真程序之間的數(shù)據(jù)交換核心是接口協(xié)議要穩(wěn)定。這里有個(gè)深坑如果你每次測(cè)試都啟動(dòng)一個(gè)新的PreScan仿真進(jìn)程啟動(dòng)開(kāi)銷是很大的。一個(gè)復(fù)雜場(chǎng)景從進(jìn)程創(chuàng)建到仿真就緒可能要10到30秒。如果跑幾百個(gè)用例光啟動(dòng)就浪費(fèi)大量的時(shí)間。所以模塊調(diào)用的一個(gè)重要設(shè)計(jì)模式是“復(fù)用常駐進(jìn)程”啟動(dòng)一個(gè)仿真進(jìn)程后不要急著銷毀而是讓它運(yùn)行在一個(gè)待命場(chǎng)景里測(cè)試程序通過(guò)命令通道給它下發(fā)場(chǎng)景切換指令、參數(shù)修改指令一個(gè)仿真進(jìn)程服務(wù)多個(gè)測(cè)試用例每個(gè)用例之間只做場(chǎng)景重置和數(shù)據(jù)清空。這類似于你在服務(wù)器端開(kāi)了一個(gè)worker進(jìn)程客戶端不斷發(fā)任務(wù)給它處理而不是來(lái)一個(gè)任務(wù)就fork一個(gè)新進(jìn)程。PreScan社區(qū)把這種機(jī)制叫做單一實(shí)例管理器Single Instance Manager實(shí)際用起來(lái)非常簡(jiǎn)單在PreScan編譯產(chǎn)物的啟動(dòng)參數(shù)里加一個(gè)-single它就會(huì)監(jiān)聽(tīng)指定的端口接收后續(xù)的測(cè)試請(qǐng)求。5.2 含義二把自定義C模塊掛載到PreScan模型中另一種“模塊調(diào)用”是指你自己寫(xiě)了一個(gè)C算法模塊想把它作為PreScan模型的一部分參與仿真而不是通過(guò)外部通信端口跟PreScan交互。這種情況在PreScan里的標(biāo)準(zhǔn)做法是S-Function。你在Simulink里添加S-Function模塊通過(guò)mex命令編譯C源碼生成對(duì)應(yīng)的可執(zhí)行文件然后在PreScan模型里實(shí)例化它。編譯后的S-Function會(huì)和PreScan傳感器模型、車輛動(dòng)力學(xué)模型一起參與整個(gè)仿真鏈路數(shù)據(jù)走的是Simulink內(nèi)部信號(hào)線不是外部網(wǎng)絡(luò)。S-Function方法適合把已有C算法嵌入到“仿真在環(huán)”的調(diào)試過(guò)程中但如果你只是想在外部控制PreScan跑測(cè)試不必走這條路。我自己的體會(huì)是S-Function更適合算法開(kāi)發(fā)階段的快速驗(yàn)證而外部C測(cè)試程序更適合系統(tǒng)級(jí)的自動(dòng)化回歸兩者最好不要混在一起否則調(diào)試起來(lái)定位問(wèn)題會(huì)很別扭。5.3 共享內(nèi)存調(diào)用的完整實(shí)現(xiàn)片段對(duì)于性能要求極高的模塊調(diào)用比如激光雷達(dá)點(diǎn)云處理UDP和TCP都不夠看共享內(nèi)存是唯一靠譜的選擇。我給出Windows下共享內(nèi)存的典型實(shí)現(xiàn)這段代碼也可以直接復(fù)用到你的測(cè)試框架里。服務(wù)端PreScan側(cè)通常由PreScan的共享內(nèi)存發(fā)送模塊完成// 創(chuàng)建共享內(nèi)存區(qū) HANDLE hMapFile CreateFileMapping( INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE, 0, sizeof(LidarFrame), LPrescanLidarMemory); LPVOID pBuf MapViewOfFile( hMapFile, FILE_MAP_ALL_ACCESS, 0, 0, 0); auto* pLidar static_castLidarFrame*(pBuf); // PreScan側(cè)持續(xù)寫(xiě)入點(diǎn)云數(shù)據(jù)客戶端C測(cè)試程序側(cè)HANDLE hMapFile OpenFileMapping( FILE_MAP_ALL_ACCESS, FALSE, LPrescanLidarMemory); if (hMapFile nullptr) { printf(OpenFileMapping failed, error%d\n, GetLastError()); return -1; } LPVOID pBuf MapViewOfFile( hMapFile, FILE_MAP_ALL_ACCESS, 0, 0, 0); auto* pLidar static_castLidarFrame*(pBuf); // 循環(huán)讀取點(diǎn)云數(shù)據(jù) for (int i 0; i pLidar-pointCount; i) { // 處理pLidar-points[i] }共享內(nèi)存需要注意兩個(gè)細(xì)節(jié)一是進(jìn)程同步不能一邊寫(xiě)一邊讀最好用互斥體或事件來(lái)協(xié)調(diào)讀寫(xiě)時(shí)機(jī)二是句柄釋放每次測(cè)試結(jié)束后要調(diào)用UnmapViewOfFile和CloseHandle否則句柄泄漏多了之后長(zhǎng)時(shí)間跑批會(huì)出現(xiàn)內(nèi)存映射失敗表現(xiàn)為“OpenFileMapping失敗錯(cuò)誤碼5拒絕訪問(wèn)”或者“錯(cuò)誤碼8存儲(chǔ)空間不足”。5.4 為什么不要讓模塊調(diào)用變成“每次新建進(jìn)程”我在項(xiàng)目里吃過(guò)這個(gè)虧。早期為了圖省事每條測(cè)試用例都用CreateProcess啟動(dòng)一個(gè)新的PreScan仿真進(jìn)程跑完立即殺掉。結(jié)果一天跑下來(lái)機(jī)器的句柄數(shù)和內(nèi)存碎片暴漲從下午開(kāi)始就頻繁出現(xiàn)仿真啟動(dòng)失敗或者共享內(nèi)存無(wú)法創(chuàng)建。后來(lái)我把架構(gòu)改成“常駐仿真進(jìn)程端口分發(fā)測(cè)試請(qǐng)求”的模式一組用例只啟動(dòng)一個(gè)仿真進(jìn)程用例之間通過(guò)協(xié)議切換場(chǎng)景問(wèn)題直接消失。這個(gè)經(jīng)驗(yàn)很重要PreScan仿真程序雖然支持命令行啟動(dòng)但它不是為“一秒啟動(dòng)、一秒銷毀”的短生命周期場(chǎng)景設(shè)計(jì)的。它的資源初始化包括加載場(chǎng)景、初始化傳感器模型、分配顯存、初始化通信端口這些都需要時(shí)間。設(shè)計(jì)自動(dòng)化測(cè)試框架時(shí)把“仿真進(jìn)程生命周期”和“測(cè)試用例生命周期”徹底解耦是保持長(zhǎng)時(shí)間穩(wěn)定運(yùn)行的關(guān)鍵。6. 自動(dòng)化測(cè)試框架從單條用例到批量回歸和CI集成單個(gè)測(cè)試用例跑通之后接下來(lái)就是把它擴(kuò)展成一套能支撐幾百條用例的自動(dòng)化框架。這一步做得不好前面所有功夫都會(huì)白費(fèi)。6.1 測(cè)試用例的標(biāo)準(zhǔn)化流程我定義了一套標(biāo)準(zhǔn)流程每條用例都必須遵循preStart準(zhǔn)備場(chǎng)景文件、參數(shù)配置檢查端口和共享內(nèi)存是否可用start啟動(dòng)仿真進(jìn)程等待就緒信號(hào)run執(zhí)行測(cè)試步驟持續(xù)采集數(shù)據(jù)check根據(jù)斷言規(guī)則判定pass/failstop關(guān)閉仿真保存日志和現(xiàn)場(chǎng)數(shù)據(jù)record把結(jié)果寫(xiě)入?yún)R總報(bào)告。整套流程用Python寫(xiě)了一個(gè)調(diào)度器因?yàn)镻ython在文件處理、流程編排和Jenkins集成方面確實(shí)順手。調(diào)度器的邏輯很簡(jiǎn)單遍歷用例清單對(duì)每條用例調(diào)用對(duì)應(yīng)的C測(cè)試exe傳參指定場(chǎng)景和用例ID然后檢查返回值。測(cè)試exe返回0表示通過(guò)非0表示失敗調(diào)度器只負(fù)責(zé)記錄和匯總。我不建議把斷言邏輯寫(xiě)在調(diào)度器里這會(huì)讓責(zé)任邊界模糊排查問(wèn)題的時(shí)候會(huì)互相甩鍋。6.2 日志規(guī)范讓失敗可追溯自動(dòng)化測(cè)試最讓人頭疼的是“這條用例失敗了但為什么失敗”如果日志里什么都沒(méi)有那就只能重新手動(dòng)跑一遍場(chǎng)景那自動(dòng)化就失去了意義。我在設(shè)計(jì)日志時(shí)定了幾個(gè)硬性要求每條用例一個(gè)獨(dú)立目錄按時(shí)間和用例ID命名仿真程序的控制臺(tái)輸出必須重定向到日志文件C測(cè)試程序的每個(gè)關(guān)鍵步驟都要打點(diǎn)包括啟動(dòng)時(shí)間、就緒時(shí)間、注入指令時(shí)間、斷言判定時(shí)間失敗時(shí)必須把當(dāng)時(shí)的輸入數(shù)據(jù)和輸出數(shù)據(jù)快照保存下來(lái)。日志格式我用JSON每行一個(gè)事件方便后續(xù)用腳本做統(tǒng)計(jì)分析{time: 12.345, event: assert, module: LKA, param: lateralOffset, value: 0.312, threshold: 0.5, pass: true} {time: 13.201, event: assert, module: LKA, param: lateralOffset, value: 0.537, threshold: 0.5, pass: false}這樣的日志出問(wèn)題之后直接拉出來(lái)看能快速定位是哪個(gè)時(shí)刻哪個(gè)參數(shù)越界不需要開(kāi)GUI復(fù)現(xiàn)。6.3 靜默模式與超時(shí)看門(mén)狗前面提到過(guò)非預(yù)期彈窗會(huì)導(dǎo)致自動(dòng)化測(cè)試掛死。除了強(qiáng)制使用靜默模式之外我還給調(diào)度器加了一個(gè)超時(shí)看門(mén)狗如果某條用例運(yùn)行時(shí)間超過(guò)設(shè)定上限通常是正常耗時(shí)的1.5倍調(diào)度器直接殺掉對(duì)應(yīng)進(jìn)程把這條用例標(biāo)記為fail然后繼續(xù)跑下一條?？撮T(mén)狗的粒度要分兩層第一層是單條用例超時(shí)第二層是總跑批時(shí)間超時(shí)。有一次我跑一個(gè)大型場(chǎng)景矩陣某條特殊場(chǎng)景導(dǎo)致仿真卡死如果沒(méi)有超時(shí)看門(mén)狗整個(gè)流水線會(huì)卡在那里直到Jenkins的全局超時(shí)把它殺掉白白浪費(fèi)幾個(gè)小時(shí)。加了看門(mén)狗之后單條用例卡住只影響這一條流水線整體的“不中斷能力”才是自動(dòng)化測(cè)試能不能真正落地的關(guān)鍵。6.4 Jenkins集成端到端的持續(xù)回歸CI集成的最終目標(biāo)是代碼提交后自動(dòng)觸發(fā)PreScan回歸測(cè)試跑完出報(bào)告結(jié)果回傳到開(kāi)發(fā)人員。我用的Jenkins流水線大致是這樣pipeline { agent { label prescan-win } stages { stage(Checkout) { steps { checkout scm } } stage(Build C Test) { steps { bat %VS_MSBUILD% prescan_test.sln /p:ConfigurationRelease /p:Platformx64 } } stage(Run PreScan Tests) { steps { bat python run_prescan_tests.py --configtest_suite.json } } stage(Publish Report) { steps { publishHTML(target: [ allowMissing: false, alwaysLinkToLastBuild: true, keepAll: true, reportDir: test_output, reportFiles: index.html, reportName: PreScan Test Report ]) } } } post { always { junit test_output/*.xml } } }核心點(diǎn)是編譯C測(cè)試程序用MSBuild跑測(cè)試用Python調(diào)度器報(bào)告用HTML或JUnit XML格式。這樣CI系統(tǒng)就能把測(cè)試趨勢(shì)畫(huà)出來(lái)哪次提交讓某個(gè)場(chǎng)景掛了一眼就能看出來(lái)。6.5 結(jié)果報(bào)告從“跑完了”到“看得懂”測(cè)試報(bào)告并不是一個(gè)簡(jiǎn)單pass/fail列表就夠的。我見(jiàn)過(guò)很多團(tuán)隊(duì)CI跑完出一堆紅色但項(xiàng)目負(fù)責(zé)人根本不知道這意味著什么因?yàn)闆](méi)有上下文。我的做法是在測(cè)試用例的配置里加元信息包括需求編號(hào)、模塊負(fù)責(zé)人、嚴(yán)重等級(jí)。報(bào)告里不僅顯示pass/fail還要顯示“失敗用例屬于哪個(gè)模塊、影響的是哪個(gè)需求”。后來(lái)我還加了一個(gè)趨勢(shì)圖同一個(gè)用例在最近30次流水線里的通過(guò)率。這個(gè)趨勢(shì)圖幫助團(tuán)隊(duì)發(fā)現(xiàn)了很多“偶發(fā)問(wèn)題”——有些用例不是必掛而是隔三差五掛一次往往指向傳感器噪聲閾值設(shè)置不合理或者場(chǎng)景初始化不干凈。沒(méi)有趨勢(shì)圖這種偶發(fā)問(wèn)題很容易被當(dāng)作“環(huán)境抖動(dòng)”忽略掉。7. 踩坑經(jīng)驗(yàn)PreScan C自動(dòng)化測(cè)試中真實(shí)遇到的高頻問(wèn)題最后把我在這個(gè)領(lǐng)域里踩過(guò)的最有價(jià)值的坑集中列一遍。這些問(wèn)題沒(méi)有一個(gè)在官方文檔里寫(xiě)得很清楚但實(shí)際項(xiàng)目里幾乎都會(huì)遇到。7.1 VS版本不一致導(dǎo)致的DLL地獄前面提過(guò)這是第一位的老大難。PreScan編譯的仿真程序、你自己寫(xiě)的C測(cè)試程序、還有第三方庫(kù)如果三者的VS工具集版本不一致最終結(jié)果就是運(yùn)行時(shí)報(bào)找不到DLL或者報(bào)錯(cuò)信息含糊不清。最氣人的是同樣的代碼在開(kāi)發(fā)機(jī)上跑得好好的換到測(cè)試機(jī)就掛了。我的解決方案是項(xiàng)目里所有C工程統(tǒng)一用同一個(gè)VS版本編譯并且把版本信息寫(xiě)進(jìn)構(gòu)建腳本測(cè)試機(jī)上提前裝Visual C Redistributable聚合包每次換新開(kāi)發(fā)機(jī)時(shí)先在干凈環(huán)境里做一次完整編譯和跑批驗(yàn)證不要等到部署那天才暴露問(wèn)題。7.2 PreScan仿真啟動(dòng)慢超時(shí)誤報(bào)很多場(chǎng)景的仿真啟動(dòng)時(shí)間跟機(jī)器負(fù)載強(qiáng)相關(guān)第一次冷啟動(dòng)可能8秒但同一臺(tái)機(jī)器在CI高峰期可能20秒。如果測(cè)試程序里寫(xiě)死了“10秒內(nèi)必須就緒”那高峰期就會(huì)大量誤報(bào)fail。我的處理方式是啟動(dòng)等待時(shí)間設(shè)成正常值的3倍同時(shí)采用“輪詢物理時(shí)間”而不是“固定sleep”的方式。每200毫秒探測(cè)一次仿真是否就緒最多等待90秒這樣既不會(huì)誤報(bào)也不會(huì)因?yàn)檫^(guò)度等待拖慢整體節(jié)奏。7.3 共享內(nèi)存句柄泄漏長(zhǎng)時(shí)間跑批后測(cè)試程序突然出現(xiàn)共享內(nèi)存訪問(wèn)失敗基本都是句柄泄漏。Windows的句柄數(shù)量不是無(wú)限的如果你每條用例都OpenFileMapping但從來(lái)CloseHandle跑幾百條用例之后必然爆掉。解決辦法是每次MapViewOfFile之后必須在作用域結(jié)束前UnmapViewOfFile和CloseHandle用RAII封裝讓資源生命周期管理交給C的析構(gòu)函數(shù)內(nèi)部自檢機(jī)制每隔100條用例打印一次當(dāng)前句柄數(shù)如果異常增長(zhǎng)會(huì)立刻報(bào)警。7.4 端口被占用UDP收不到數(shù)據(jù)PreScan仿真程序每次啟動(dòng)都會(huì)綁定固定的UDP端口如果上一個(gè)仿真進(jìn)程沒(méi)有被完全殺掉端口還處于占用狀態(tài)新啟動(dòng)的仿真程序就會(huì)綁定失敗表現(xiàn)是“UDP收不到任何數(shù)據(jù)”而日志里什么都沒(méi)有。我后來(lái)在啟動(dòng)腳本里加了一步啟動(dòng)仿真前先檢查端口占用情況如果有殘留進(jìn)程就強(qiáng)制殺掉。netstat -ano | findstr :5600 taskkill /F /PID pid同時(shí)給仿真程序的進(jìn)程名統(tǒng)一命名調(diào)度器在啟動(dòng)前會(huì)把上一個(gè)殘留實(shí)例清掉避免因?yàn)楫惓Ｍ顺鰧?dǎo)致進(jìn)程殘留。7.5 結(jié)構(gòu)體對(duì)齊、字節(jié)序和字段類型不匹配通信協(xié)議里結(jié)構(gòu)體對(duì)齊不匹配是C測(cè)試?yán)锉容^隱蔽的坑表面上看數(shù)據(jù)能收到但數(shù)值不對(duì)。除了加#pragma pack之外我后來(lái)更推薦的做法是不光定義結(jié)構(gòu)體還定義序列化和反序列化函數(shù)并在函數(shù)里逐個(gè)字段賦值而不是直接memcpy。這樣做的優(yōu)勢(shì)是即使發(fā)送端和接收端的結(jié)構(gòu)體定義有微小差異比如PreScan版本升級(jí)后某個(gè)字段類型變了也能在反序列化階段做字段校驗(yàn)而不是把整個(gè)內(nèi)存塊硬懟過(guò)去導(dǎo)致數(shù)據(jù)全亂。7.6 斷言閾值定太緊隨機(jī)噪聲下偶發(fā)fail這個(gè)問(wèn)題在傳感器數(shù)據(jù)測(cè)試?yán)锾貏e常見(jiàn)。攝像頭輸出車道線系數(shù)時(shí)光照和路面紋理變化會(huì)導(dǎo)致輕微噪聲如果你把橫向偏移量的容忍閾值設(shè)成±0.1米而在仿真里真實(shí)情況下該值在±0.15米波動(dòng)那這條用例就會(huì)隔三差五失敗看起來(lái)像“玄學(xué)”。處理方式是在設(shè)計(jì)斷言前先做一輪噪聲摸底跑二十次相同的用例統(tǒng)計(jì)每個(gè)關(guān)鍵指標(biāo)的正常波動(dòng)范圍然后在這個(gè)范圍基礎(chǔ)上加一定余量作為斷言閾值。同時(shí)把閾值配置化不要寫(xiě)死在代碼里方便在測(cè)試報(bào)告里看到閾值調(diào)整的歷史。7.7 GUI模式彈窗掛死最后再?gòu)?qiáng)調(diào)一次自動(dòng)化測(cè)試必須使用靜默模式。PreScan的GUI模式在運(yùn)行時(shí)可能彈出各種提示窗口可能是資源加載失敗也可能是某個(gè)數(shù)據(jù)文件缺失任何彈窗都會(huì)導(dǎo)致任務(wù)永遠(yuǎn)卡在等待點(diǎn)擊狀態(tài)。用靜默模式不僅避免了這個(gè)問(wèn)題還節(jié)省了渲染資源提升了測(cè)試速度。如果某些場(chǎng)景確實(shí)需要GUI輔助排查我建議只開(kāi)一條單獨(dú)的手動(dòng)調(diào)試流水線和自動(dòng)化回歸流水線徹底分開(kāi)。避免為了“偶爾的方便”讓整個(gè)自動(dòng)化體系變得脆弱?；乜凑麄€(gè)過(guò)程PreScan的C自動(dòng)化測(cè)試之所以值得投入不是因?yàn)樗芴娲斯?chǎng)景搭建場(chǎng)景本身還是要在GUI里搭而是因?yàn)樗选胺磸?fù)執(zhí)行同一套驗(yàn)證”這件事徹底自動(dòng)化了。環(huán)境部分一次配好通信協(xié)議一次定好剩下的場(chǎng)景矩陣、回歸測(cè)試、CI集成全都是可持續(xù)積累的資產(chǎn)。對(duì)我來(lái)說(shuō)最大的收獲在于團(tuán)隊(duì)從“擔(dān)心改動(dòng)會(huì)不會(huì)引入回歸”變成了“每次提交都有幾百條用例在自動(dòng)守護(hù)”這種確定感是手動(dòng)測(cè)試永遠(yuǎn)給不了的。本文還有配套的精品資源點(diǎn)擊獲取