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

宏控天工

做嵌入式控制器开发，软件几乎每天都在改。每次改完都要人去手动跑一遍 HIL 台架，跑完等结果、记报告、再通知开发——这套流程在小团队还能转，到了量产阶段根本跟不上迭代速度。

解决办法就是把 HIL 测试接进 CI（持续集成）：代码一提交，自动触发 HIL 回归，跑完自动出报告。这篇讲清楚这条流水线怎么搭。

一、先搞清楚：CI下的HIL自动化要解决什么

手动跑 HIL 的痛点：

• 改完代码要等人去跑，反馈慢
• 跑完报告散落各处，不好追溯
• 谁跑的、跑的哪个版本、什么结果，全靠人记

CI 自动化要做到三件事：

1. 自动触发：代码提交/打标签时自动跑回归
2. 无人值守：跑完自动出通过/失败报告
3. 可追溯：哪个版本、哪次提交、什么结果，自动关联

二、流水线整体架构

一条 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(suite="smoke")

CI 系统只需要调这几个接口，不需要知道台架内部细节。

四、第二步：配置触发条件

不是每次提交都跑全量 HIL——全量回归可能几小时。合理的分级：

# 伪代码：CI流水线配置
stages:
-smoke:when=on-push cases=smoke/
-daily:when=schedule cases=functional/
-release:when=on-tag cases=all/

这样开发提代码马上知道冒烟过没过，不用等几小时。

五、第三步：报告自动生成与失败处理

跑完自动生成报告，关键信息要有：

• 跑的哪个固件版本、哪个模型
• 通过/失败用例数
• 失败用例的原始报文和波形留档

失败处理：

• 冒烟失败 → 立即通知提交人
• 全量失败 → 汇总失败清单，自动关联到提交记录

失败用例的原始数据必须自动留档，否则开发拿到一个"失败"不知道现场是什么，还是得跑去台架复现。

六、落地时的几个坑

1. 台架共享要排队：CI 自动跑意味着多人在用同一台架，要做任务排队，别让两个任务同时抢台架。
2. 环境一致性：CI 跑的环境和人手动跑的要一致，不然 CI 过了手动挂，问题难查。
3. 别把全量压在每次提交上：分级触发，冒烟快反馈，全量放夜间。
4. 失败先怀疑环境：CI 偶发失败，先看台架复位、固件烧录是否正常，别急着归因到代码。

把这几条做扎实，HIL 回归就能从"人等台架"变成"台架等人"。工具层面，现在的国产 HIL 平台普遍支持命令行调用、用例集管理和自动报告，接进 CI 不需要自己从零造轮子。

FAQ

Q1：每次提交都跑全量HIL可以吗？
不建议。全量回归耗时几小时，会拖慢开发反馈。按冒烟/功能/全量分级触发更合理。

Q2：CI能直接控制HIL台架吗？
前提是台架提供命令行接口（复位、烧录、跑用例）。没有接口的台架接不进CI。

Q3：CI跑HIL和手动跑结果不一致怎么办？
先核对环境一致性（固件版本、模型、台架复位），CI偶发失败优先怀疑环境。

Q4：多个人抢一台HIL怎么办？
CI系统做任务排队，同一时间只允许一个任务占用台架。

Q5：HIL报告要留什么？
固件版本、模型版本、通过/失败清单、失败用例原始报文波形，全部自动留档可追溯。