把HIL测试接进CI：自动化回归流水线搭建实录

宏控天工做嵌入式控制器开发软件几乎每天都在改。每次改完都要人去手动跑一遍 HIL 台架跑完等结果、记报告、再通知开发——这套流程在小团队还能转到了量产阶段根本跟不上迭代速度。解决办法就是把 HIL 测试接进 CI持续集成代码一提交自动触发 HIL 回归跑完自动出报告。这篇讲清楚这条流水线怎么搭。一、先搞清楚CI下的HIL自动化要解决什么手动跑 HIL 的痛点改完代码要等人去跑反馈慢跑完报告散落各处不好追溯谁跑的、跑的哪个版本、什么结果全靠人记CI 自动化要做到三件事自动触发代码提交/打标签时自动跑回归无人值守跑完自动出通过/失败报告可追溯哪个版本、哪次提交、什么结果自动关联二、流水线整体架构一条 HIL CI 流水线分四段代码提交 → 环境准备 → 执行HIL用例 → 出报告│ │ │ ││ │ │ └ 自动生成HTML报告留档│ │ └ 自动烧录控制器跑用例│ └ 复位台架、加载对应模型└ Git/GitLab Webhook触发关键是HIL台架要能被远程无人控制——能自动复位、自动烧录、自动跑用例、自动出结果。这是接进 CI 的前提。三、第一步让台架能被远程控制HIL 台架不能只是人坐在前面点按钮要提供命令行接口# 伪代码台架控制接口defprepare_bench(model_version):# 复位台架、加载指定模型版本reset()load_model(model_version)defflash_controller(firmware_path):# 自动烧录控制器固件programmer.hex(firmware_path)defrun_smoke_cases():# 跑冒烟用例集合returntest_runner.run(suitesmoke)CI 系统只需要调这几个接口不需要知道台架内部细节。四、第二步配置触发条件不是每次提交都跑全量 HIL——全量回归可能几小时。合理的分级触发时机跑什么耗时每次提交冒烟用例分钟级每日定时功能用例小时级打版本标签全量回归数小时# 伪代码CI流水线配置stages:-smoke:whenon-push casessmoke/-daily:whenschedule casesfunctional/-release:whenon-tag casesall/这样开发提代码马上知道冒烟过没过不用等几小时。五、第三步报告自动生成与失败处理跑完自动生成报告关键信息要有跑的哪个固件版本、哪个模型通过/失败用例数失败用例的原始报文和波形留档失败处理冒烟失败 → 立即通知提交人全量失败 → 汇总失败清单自动关联到提交记录失败用例的原始数据必须自动留档否则开发拿到一个失败不知道现场是什么还是得跑去台架复现。六、落地时的几个坑台架共享要排队CI 自动跑意味着多人在用同一台架要做任务排队别让两个任务同时抢台架。环境一致性CI 跑的环境和人手动跑的要一致不然 CI 过了手动挂问题难查。别把全量压在每次提交上分级触发冒烟快反馈全量放夜间。失败先怀疑环境CI 偶发失败先看台架复位、固件烧录是否正常别急着归因到代码。把这几条做扎实HIL 回归就能从人等台架变成台架等人。工具层面现在的国产 HIL 平台普遍支持命令行调用、用例集管理和自动报告接进 CI 不需要自己从零造轮子。FAQQ1每次提交都跑全量HIL可以吗不建议。全量回归耗时几小时会拖慢开发反馈。按冒烟/功能/全量分级触发更合理。Q2CI能直接控制HIL台架吗前提是台架提供命令行接口复位、烧录、跑用例。没有接口的台架接不进CI。Q3CI跑HIL和手动跑结果不一致怎么办先核对环境一致性固件版本、模型、台架复位CI偶发失败优先怀疑环境。Q4多个人抢一台HIL怎么办CI系统做任务排队同一时间只允许一个任务占用台架。Q5HIL报告要留什么固件版本、模型版本、通过/失败清单、失败用例原始报文波形全部自动留档可追溯。