座艙測試不是把手機App那套點屏腳本搬上車就能用。多屏聯動、語音并發、CAN信號耦合、長穩內存泄漏，任何一環斷掉，發版前回歸就會變成通宵手工點檢。下面按項目里真實踩過的坑，拆開講一套能落地的自動化做法。

?

早上九點，域控制器樣機剛刷完夜里的版本，測試臺架上三塊屏同時亮起來——中控、儀表、副駕娛樂屏。這時候如果還靠人拿手指去點「空調24度」「導航回家」「副駕說播放音樂」，一天撐死跑三十條用例，版本卻兩天一迭代。座艙自動化測試干的事，就是把這套動作拆成可復用腳本，讓機器半夜替你把回歸跑完，早上只管看哪條紅了。

?

先說清楚座艙跟普通終端最大的差別：屏幕上的「開了」不等于真的開了。點一下空調按鈕，UI狀態變藍沒用，得去CAN報文里看壓縮機請求信號有沒有發出去；掛進R擋倒車影像沒彈出來，光看Activity棧是查不出來的，因為硬解碼畫面根本不走安卓控件樹。所以座艙自動化從第一天就不能只做UI層，必須把「界面操作 → 總線信號 → 視覺畫面 → 音頻反饋」四條線綁在同一條用例里斷言，不然跑出來一片綠，裝車照樣出事。

?

一、先搭能干活的三層臺架
別一上來就買整套商用平臺。小團隊先湊最小閉環：
? 控制通路：adb走網絡連車機，uiautomator2或者類似輕量框架點屏、滑屏、讀控件；

? 信號通路：PCAN或同類硬件接CAN/CAN FD，python-can監聽報文，掛擋、車速、空調請求全走這邊發；

? 判定通路：工業相機架在屏前拍畫面，OpenCV做模板匹配，專門抓倒車影像、HUD箭頭、黑屏花屏這種控件抓不到的東西。

三條通路用同一份腳本調度，用例里既點界面又等信號，超時不是sleep(5)硬等，而是wait_for_signal輪詢，ECU沒回就判失敗。硬編碼等待是座艙腳本里最貴的債，版本一換負載曲線，假失敗能刷一屏。

?

二、用例別按「等價類邊界值」寫，按「上車到下車」寫
座艙的Bug藏在組合里。單獨測「語音開空調」百分百過，但「高速120km/h + 副駕喚醒 + 導航播報 + 來電接入」疊一起，音樂沒暫停、HUD卡一幀，這種問題人工點十遍不一定撞得見，腳本跑五十遍必出。
真實項目里好用的寫法是從用戶旅程拆：
通電→人臉登錄→主駕說「我冷」→同時方向盤右鍵調風量→儀表同步溫度數字→三秒后注入一條車速跳變報文→看空調有沒有被沖掉。
一條用例里塞進語音注入（TTS放音）、觸控、CAN信號、相機截幀，跑出來才有意義。只測單模塊不測聯動，量產反饋會教做人。

?

三、定位器活不過兩個版本，別跟resource-id死磕
車機系統是深度定制的，大版本一升，控件ID全洗牌。上版叫btn_temp，下版叫hvac_temp_btn，二十條腳本一夜掛一半，改定位器的時間比手工點還長。
扛造的寫法三種混著用：
? 關鍵按鈕用控件ID，但封裝成Page Object，改一處全量生效；

? 樣式常變的用OCR讀文字+周邊圖標相對位置；

? 3D車模、Kanzi/Unity畫出來的空調葉片、儀表盤指針，直接放棄控件樹，拿視覺模板匹配。

主題切換（白天/黑夜）別用顏色絕對值做錨點，用形狀+文字+區域坐標，不然切個暗色模式全量翻車。

?

四、長穩和性能必須進自動化，不全量跑
座艙最怕的是「跑著跑著就死了」。有個項目沒做內存長跑，實車跑四十多小時死機，召回代價比測試團隊一年預算都高。
臺架上的硬指標直接寫進流水線：
? 整機連續通電168小時，零死機，內存曲線只爬不落就攔下來；

? 冷啟動到首幀用高速相機逐幀掐表，一般要求≤5秒，比手機端嚴一倍；

? 滑動幀率、最大連續卡頓幀數、觸控到渲染全鏈路時延，用相機+時間戳算，不靠人眼估；

- Monkey和隨機操作腳本混跑，專門釣ANR和進程重啟。
這些不用全量天天跑，但每個版本發候選包必須過一遍夜，早上看內存曲線比看通過率更重要。

?

五、接進持續集成才算閉環
腳本能自跑不算贏，接進提交即觸發才是分水嶺。
做法分兩檔：
開發提代碼 → 跑冒煙（開機、登錄、空調開關、導航啟動，十分鐘出結果）；
夜里零點 → 全量回歸，多工位數屏并行，早上八點郵件甩報告，失敗用例按「環境抖動 / 定位失效 / 真Bug」自動歸類，真Bug直接掛給對應開發。
報告里別只寫「失敗」，把截圖、logcat、CAN報文三段拼一起，開發點開就能復現，扯皮量能砍掉一大半。

?

六、幾個容易把項目拖垮的坑
? 只在userdebug上調通就交差：量產車是user版本，adb root全廢，框架得走非Root的測試輔助服務，不然量產前一夜全崩。

? 語音只在安靜實驗室測：高速路噪、副駕小孩吵、方言「把風給我開大點」，識別率掉到八成是常態，聲學仿真和噪聲注入必須進用例。

? OTA回滾不測：座艙升級斷電離線，不驗回滾直接變磚，這條必須當安全用例卡死。

- 追求100%自動化：手感、美學、動畫「順不順眼」這類事留給探索性測試，機器只干重復、可量化、能斷言的活，二八法則在這里不是雞湯是保命。
? 腳本沒人養：設個「臺架守護」角色，每周清一次失效定位器，視覺模板進Git版本管理，UI大改拉分支統一換錨點，不然三個月后腳本比被測系統還難維護。

?

座艙自動化測試這件事，前半截是工程問題，后半截是取舍問題。先把「UI+信號+視覺」三路打通跑通一條空調聯動用例，再往里加語音并發、加多屏同步、加長穩壓測，比一上來鋪五百條脆弱腳本實在得多。臺架搭穩了，版本發得再快，半夜跑完的報表上紅的那幾條，才是真該修的東西。

?

希望對大家有所幫助，了解更多關于協作機械臂,單臂復合機器人,復合材料測試,四足機器人測試,智能座艙自動化測試,插拔測試等產品技術和售后服務，歡迎到訪官網咨詢！m.ustehs76.com