做车载座舱HMI测试的朋友，应该都经历过这种场景：新版本车机固件提测，几千条用例堆在眼前，中控大屏每个菜单跳转要验证、不同分辨率下多任务卡片要确认、语音助手在不同背景噪音下的唤醒率要回归，一轮下来除了人累，漏测还要靠运气。我们部门很早就有了自己的自动化测试框架，用例能跑，但结果散落在各自电脑里，测试报告靠人工整理，问题单靠人肉流转。后来大家决定把“IM机器人 + AI Agent”引进来，做成了一套车载HMI自动化测试平台，让机器人负责收发消息、派发任务、推送结果，让Agent负责拆解需求、归因失败用例，彻底把自动化从“能跑”变成了“能用”。
这套平台适合两类人参考：一类是正在做座舱HMI或车机系统测试，想搭建自动化执行体系的同学；另一类是已经在做自动化，但苦于结果流转、任务触发、失败分析全靠人工的团队。今天这篇文章，我把架构设计、关键组件、落地过程和踩过的坑一次讲清楚，内容偏实践，可以直接照着搭。
1. 项目背景：车载HMI测试的痛点和破局思路
1.1 车载HMI测试到底难在哪
车载HMI，简单说就是车主每天面对的那块中控大屏、仪表盘、方向盘按键和语音交互界面的总称。它和普通App测试最大的区别在三点：第一是软硬一体，车机系统和座舱域控制器绑定，换一块屏、改一条CAN信号，都可能影响界面响应；第二是多模态交互，用户不只是点屏幕，还会按实体按键、说语音、看仪表，同一个功能可能由不同入口触发；第三是回归代价高，一个版本涉及多个车型、多种屏幕分辨率、中控和仪表联动，纯手工回归一个版本至少需要两个人扑上一周。
我们之前踩过的最大坑是“自动化用例跑通了，但结果没人看”。有一次自动化框架跑出一个中控黑屏的问题，因为当天没人盯执行结果，第二天测试经理问起才知道出了事故。所以当我们决定做新平台时，第一需求不是“多跑几条用例”，而是“让机器学会主动找人、主动分诊、主动给结论”。这也决定了后续架构的选型方向。
1.2 为什么是“IM机器人 + AI Agent”这套组合
市面上成熟的CI/CD平台很多，像Jenkins、GitLab CI，配合命令行也能实现定时跑测、发报告。但对车载HMI测试团队来说，它有两个别扭的地方：一是车机测试设备不是PC，是台架、域控制器、真车，环境搭建和任务派发需要跟硬件绑定，CI的通用调度模型没有适配；二是执行结果需要人为解读，失败截图往往是一张黑屏或者一个弹窗，没有领域经验的人根本看不出问题级别。
我们选择IM机器人做入口，是因为团队日常沟通本来就在IM群里，机器人把“跑测试、看结果、提问题”这些动作直接塞进聊天窗口，零学习成本。AI Agent负责把人和任务之间那层“翻译”工作接过去：你说“帮我回归一下高精地图模块”，Agent会解析这句话，匹配到对应的用例集合，找到空闲的台架，调度执行，等结果出来后判断失败原因，再把结论用人类能看懂的话发回群里。
如果用一句话概括选型逻辑：IM机器人解决“消息触达和交互”问题，AI Agent解决“任务理解和结果分析”问题，自动化执行框架负责真正把车机动起来。三者各管一段，耦合度低，哪个环节出问题都能单独替换。
2. 整体架构设计与核心组件拆解
2.1 四层架构与数据流转
平台的整体架构我习惯分成四层：接入层、调度层、执行层、数据层。
接入层就是IM机器人，负责接收群里的用户指令，比如“跑一遍主界面冒烟测试”“查一下昨晚失败的任务”；同时负责把执行结果、失败截图、分析报告推送到群里。
调度层是AI Agent，它做三件事：把用户自然语言转成标准任务描述；从用例库中检索匹配的用例集合；根据执行机的实时状态（是否空闲、是否在线）分配任务。
执行层是真正跑在车机或台架上的自动化框架，负责操作界面、采集截图、抓取日志、收集传感器状态，最后把原始结果汇总回传。
数据层包括用例库、执行记录库、截图和录像存储、日志库，还有一台对象存储服务器专门放车载设备回传的大文件。
数据流转的核心链路是这样：用户在群里发一句“回归一下岳母级语音唤醒成功率”→ IM机器人回调到Agent服务 → Agent解析意图并生成任务单 → 调度器查找空闲的HIL台架 → 执行器通过ADB连接车机 → 启动测试用例 → 每跑一步截图并记录状态 → 用例结束后汇总日志、截图、视频 → Agent对失败用例做归因分析 → 机器人把结构化报告推回群里。
这套架构最重要的设计原则是“异步”。IM机器人的回调接口要求在3秒内响应，否则IM平台会自动重试，如果同步处理任务，必然超时。所以我们把消息先丢进消息队列，Agent立刻返回一个“已收到，正在处理”的提示，后续所有动作异步进行。
2.2 IM机器人侧的设计
IM机器人我们选的是飞书机器人，原因很俗气：团队已经在用飞书，不需要额外引入一套IM系统。机器人注册成企业应用后，可以拿到一对密钥，用于签名校验和消息加解密。每个群可以绑定一个机器人，用户@机器人并发送指令，平台接收事件回调。
这里有两个容易踩坑的点。
第一个是“加签”。飞书机器人支持在Webhook地址后面附带签名，签名算法是时间戳加上密钥做HMAC-SHA256。很多群机器人只需要Webhook就能发消息，但只有Webhook只能“往外发”，收不到用户消息。想要双向交互，必须以“应用”形式创建机器人，并订阅“接收消息”事件。我们初期只配了Webhook，结果只能推送测试报告，群里说“跑一下XX用例”完全没反应，排查半天才发现事件订阅没配置。
第二个是“回调超时”。IM平台给回调接口的超时非常短，我们在回调里做任何重事都会失败。解决办法是消息到达后立刻持久化，投递到队列，然后返回一个卡片消息“任务已受理”。注意，卡片消息和普通文本消息不同，卡片支持按钮交互，我们后续的“重新执行”“只看失败用例”“下载完整日志”都是靠卡片按钮实现的。按钮的回调事件里带着callback_id，Agent通过callback_id就能知道用户想干什么。
实际配置上，我们给机器人定义了指令前缀，避免自然语言里出现歧义。语法大概是这样的：
@机器人 测试 冒烟@机器人 回归 语音唤醒 车型=XC60@机器人 查询 任务ID=20250112_1001
之所以用“动词+模块+过滤条件”的结构，是因为纯自然语言在早期阶段容易误判。先让语法结构化跑顺，再让Agent慢慢处理更口语化的表达，落地风险小很多。
2.3 AI Agent 的决策流程
AI Agent不是单独一个大模型服务，而是“规则引擎 + 小模型 + 大模型”的混合体。我的经验是别一上来就用大模型做所有事，成本高、延迟大，而且车载HMI测试要求结论可解释，大模型在专业术语上偶尔会“一本正经地胡说八道”。
我们的Agent走的是三段式流水线。
第一段是意图识别。先用规则做快速匹配，如果命中指令模板，直接转结构化任务；如果没命中，再丢给大模型做一个“信息抽取”，把模块、动作、设备、时间范围几个槽位填出来。大模型输出必须是JSON，例如：
{ "action": "regression_test", "module": "voice_wakeup", "device_group": "hil_01", "filter": { "os_version": "R17.3" } }第二段是任务编排。Agent根据填好的JSON去查询用例库，比如“voice_wakeup”模块下有180条用例，其中冒烟级30条、回归级150条。再查一下执行机状态，发现HIL台架1空闲、台架2被占用，那任务就落到台架1上，同时生成一个执行计划。
第三段是结果归因。测试跑完后，Agent会拿到每条用例的PASS/FAIL、截图、日志。归因有几条规则：如果截图全黑，判断为系统启动异常；如果截图上出现“无响应”弹窗，判断为ANR；如果日志里出现timeout且窗口句柄存在，判断为元素加载超时。这些规则覆盖不了的情况，才交给大模型看截图和日志摘要做描述性汇总。
这让我想起一个典型场景：某次回归语音助手，10条用例全挂，Agent自动检查日志发现总共只录入了3条语音文件，其余7条因为录制文件缺失没跑起来。Agent最后给出的结论是“用例数据异常，需补全语音资源，非产品功能缺陷”，这条判断节省了开发一上午的排查时间。所以Agent值钱的地方不是“多聪明”，而是“把常见的失败原因前置分类”，帮人省掉重复劳动。
3. 自动化执行层的关键技术实践
3.1 被测对象与自动化方案选型
车载HMI自动化执行层，难点在于“连得上、看得见、点得准”。我们的被测对象是一个基于Android的车机系统，运行在高通平台上，外接仪表和方向盘按键信号。Android系统天然支持ADB，所以最基础的连接方式是ADB over TCP/IP，测试机器和执行台架连同一个局域网，执行器通过adb connect建立会话。
UI自动化框架我们选了Appium加UiAutomator2驱动。选Appium而不是原生UiAutomator，是因为Appium有现成的WebDriver协议，后续接Agent、接CI、接IM都方便，而且支持Python写用例脚本，团队上手成本低。
但有一个坑必须提：车载屏幕的控件和手机App不一样，很多是系统级SurfaceView、自绘控件、OpenGL渲染出来的界面，UiAutomator2对这些控件没有有效的节点信息。比如地图的缩放按钮、视频播放器的进度条，在控件树里可能只是一块矩形区域，没有任何可点击描述。所以我们的方案是“层级式识别”：优先用UiAutomator2的控件树拿语义ID，拿不到就用图像识别定位坐标，再拿不到就用OCR识别文字后匹配位置。
控件树识别有个小技巧：车机Android系统开启“开发者选项”后，UiAutomator2可以dump出当前窗口的视图层级，包括resource-id、text、bounds。我们在代码里封装了一个find_by_attr函数，可按resource-id或text优先匹配，匹配不到自动回溯到图像识别。
3.2 用例描述规范与智能等待
HMI测试用例如果写成硬编码的Python脚本，维护成本会非常可怕。我们一开始就定了“用例数据与执行代码分离”的规范，每条用例本质是一条JSON记录：
{ "case_id": "case_swift_001", "title": "主界面快捷卡片点击后跳转", "module": "home_screen", "level": "regression", "steps": [ { "action": "click", "target": {"type": "resource_id", "value": "com.car.launcher:id/quick_card"}, "wait": {"type": "text", "value": "设置", "timeout": 5000} }, { "action": "assert_visible", "target": {"type": "text", "value": "车辆设置"} } ] }这里最核心的设计是wait字段，它替代了传统自动化里的sleep。在HMI测试中，不同分辨率下一屏加载速度差异很大，固定sleep两秒在高配车型上浪费，在低配车型上又容易误报失败。我们给每个动作配了“等待条件”，只有目标元素出现或消失才算动作结束，超时才算失败。
举一个实例：中控屏在开机后会自动加载“最近使用”应用列表，低配车型可能3秒才加载完，高配车型不到1秒。如果用sleep 3秒，用例跑得慢；如果sleep 1秒，低配车型就误报。后来我们改为等待“最近使用”标题出现在控件树中，出现后再点击第一个应用图标，问题直接消失。
智能等待的实现依赖一个状态探针服务，它每200毫秒dump一次当前界面的控件树，并把关键文本和resource-id缓存到内存。断言动作只需查询这个缓存，不必每次实时dump，性能提升非常明显。
3.3 控件识别、OCR兜底与截图比对
自绘控件和地图类界面是HMI自动化最容易翻车的场景。我们的做法是建立“图像目标库”，每个目标保存至少一张模板图，以及对应的识别区域和点击偏移量。比如中控屏左上角的返回按钮，在1280x720分辨率下是坐标(70, 60)附近，在1920x1080下就完全变了。所以我们维护了每款车机分辨率对应的UI规范文件，模板匹配时先缩放到目标分辨率，再用OpenCV的归一化相关系数法计算匹配度。
如果模板匹配也失败，就启用OCR兜底。我们使用了PaddleOCR的轻量模型，部署在测试执行机上，对截图做文字检测和识别。OCR识别出“导航”“媒体”“电话”这些文字后，根据文字框的中心点作为点击坐标。注意，OCR的返回结果需要进行“关键词到坐标”的二次映射，不能直接用识别出的字符串作为点击目标，因为OCR只有文字区域，不知道这个文字是否可点击，我们需要结合控件树中可点击节点来判断。
还有一类问题是截图比对。HMI测试经常要验证“页面渲染是否有异常”，比如花屏、黑屏、画面错位。这种问题无法用断言控件是否存在来判断，因为控件树正常，但屏幕上显示的就是不对。我们的做法是在用例里声明“渲染基线”，执行时对整屏截图做像素级比对，允许一定阈值（比如95%相似度），低于阈值就认为是渲染异常。这个方案最大的问题是“正常显示但动态区域有变化”，比如当前时间、信号格、动画效果。后来我们加了遮罩区域配置，把动态区域排除在比对范围之外，误报率立刻降了下来。
4. 落地全过程、问题排查与经验沉淀
4.1 平台从0到1的落地路线
整个平台不是一次性建成的，我们分了四个阶段，每个阶段有明确交付物。
第一阶段（两周）：搭最小闭环。执行层用Appium连接一台HIL台架，预先写20条冒烟用例；IM机器人只做Webhook推送，测试结果直接发给测试群。这个阶段的目标是“让结果不再躺在电脑里”。
第二阶段（四周）：接入AI Agent基础能力。Agent先实现指令模板匹配，支持“冒烟测试”“回归测试”两个动作，能根据模块名称检索用例，并把任务派发给唯一一台执行机。IM机器人升级为应用，支持@机器人和按钮交互。这个阶段的目标是“群里说一句话就能跑测试”。
第三阶段（三个月）：扩充执行资源池。我们接入了三台HIL台架和一台真车设备，Agent增加了设备调度和排队逻辑，同时补全了失败归因规则库，把常见的启动失败、ANR、元素超时、数据缺失都覆盖到。这个阶段的目标是“多设备并发也能稳定跑”。
第四阶段（持续）：让Agent更聪明。引入大模型做自然语言指令补充、截图描述、日志摘要，同时让Agent对失败用例自动生成“怀疑模块”和“建议负责人”，测试组只需要确认结论，不再从零排查。
每个阶段我都会设置一个“人工兜底开关”。比如Agent调度出错频次较高的头两周，所有任务都抄送一份给测试组长；归因结论存疑的用例，自动标记为“需人工复核”，而不是直接判定缺陷。这能保证团队对平台的信任度不被早期bug消耗掉。
4.2 典型故障排查实录
第一类问题：IM回调超时。
现象：用户@机器人后，很久没收到“任务已受理”的回复，但重复@后收到多条相同回复。排查后发现是回调接口处理时拉取了用例列表，用时超过3秒，IM平台重试了事件推送，导致重复受理。解决方案就是彻底异步：回调只负责把消息原文写入数据库，返回200状态码，后续流程由异步worker处理。同时给每个任务生成唯一request_id，worker根据request_id去重。
第二类问题：Agent调用大模型生成的任务JSON不符合规范。
现象：用户说“跑一下仪表盘联动”，大模型返回的JSON里action字段是“run_dashboard_test”，而我们的规范里定义的是“run_hmi_test”。这种不匹配直接导致了查询不到用例。解决方法是双层校验：先用JSON Schema做格式校验，再枚举执行引擎支持的action和module白名单，白名单外的值统一映射到最接近的合法值。同时，Agent会对校验结果做一个“一次确认”，比如回复“我理解为：执行仪表盘联动相关用例，共45条，是否开始？”，让用户在群里确认后再跑。
第三类问题：车机端ADB连接不稳定。
现象：台架长时间运行后，ADB设备偶尔会显示offline，执行器连接失败。这个问题的根因是车机系统长时间运行后USB调试服务进入空闲状态，加上TCP连接被防火墙中断。我们写了一个看门狗脚本，每30秒执行一次adb devices检查设备状态，发现offline就执行adb reconnect offline，再不行就通过继电器断电重启台架。后来干脆让Agent在任务开始前先做一次设备健康检查，不通过就不派发任务，避免任务跑一半挂掉。
第四类问题：截图对比误报。
现象：主界面正常，但截图比对总是失败。排查发现是时钟区域每秒钟都在变，还有其他动画控件。解决办法就是前面提到的“遮罩区域”。我们做了一个可视化标注工具，可以在测试环境里框选动态区域，自动生成遮罩配置写进用例JSON，后续比对自动忽略这些区域。
4.3 后续演进与几点忠告
这套平台落地后，最直观的收益是回归效率的提升。以前一个版本的中控回归需要2个人耗时两天，现在一条指令半小时跑完，Agent自动给出失败清单和初判原因，测试人员只需要重点复核疑似缺陷的用例。更重要的是，机器人每天早晨自动推送昨夜的运行报告，测试团队再也不用主动去翻执行结果。
往后演进的方向有三个。第一，让Agent自动生成用例。现在大模型对界面的理解能力已经很强，它可以看着一张截图说出“这个页面有5个可点击区域，对应XX功能”，下一步就是把这些观察自动转成用例步骤。第二，让Agent自动修复用例。目前很多失败是元素定位失效导致的，Agent可以根据截图和控件树，自动更新用例中的resource-id或坐标，生成补丁供人确认。第三，把工程量量化和质量看板打通，让机器人每周出一次“自动化健康报告”，量化用例稳定性、失败原因分布、设备使用率，方便管理层做决策。
几点忠告：一是别把Agent当成万能，在数据质量差的时候，它只会让错误流转得更快，所以要先保证用例可追溯、日志规范、设备状态可监控；二是IM机器人的交互体验很重要，每一次用户指令都必须有反馈，哪怕是“正在分析”也要有反应；三是平台上线后要设置灰度观察期，用真实回归任务慢慢验证，别一上来就全量接管核心验收流程。
最后说一个我在实际操作中体会最深的一点：这套平台里最难的不是技术，而是“让测试人员相信机器人的结论”。解决办法就是让整个过程透明，Agent的每个结论都附上“证据包”——对应的截图、日志片段、规则命中记录。只要人能随时溯源到原始证据，信任就会慢慢建立起来。
