做车载座舱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_idAgent通过callback_id就能知道用户想干什么。实际配置上我们给机器人定义了指令前缀避免自然语言里出现歧义。语法大概是这样的机器人 测试 冒烟机器人 回归 语音唤醒 车型XC60机器人 查询 任务ID20250112_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_idworker根据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的每个结论都附上“证据包”——对应的截图、日志片段、规则命中记录。只要人能随时溯源到原始证据信任就会慢慢建立起来。 
长河君 · 2026/10/26 12:32:24 · 阅读 1.2k IM机器人+AI Agent驱动车载HMI自动化测试平台实践
做车载座舱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_idAgent通过callback_id就能知道用户想干什么。实际配置上我们给机器人定义了指令前缀避免自然语言里出现歧义。语法大概是这样的机器人 测试 冒烟机器人 回归 语音唤醒 车型XC60机器人 查询 任务ID20250112_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_idworker根据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的每个结论都附上“证据包”——对应的截图、日志片段、规则命中记录。只要人能随时溯源到原始证据信任就会慢慢建立起来。