TN-09 · 2026-09-12 · 测试工程系列 · 第 2 篇

为什么 HIL 时代“夜间全量回归”是奢侈品

“下班触发，天亮看报告”——夜间全量回归是互联网/SIL 时代的 CI 标配，普通到没人觉得它需要辩护。

到了 HIL 时代，它变成了奢侈品。因为这个动作隐含三个假设——算力可弹性扩展、时间可压缩、失败成本低廉——而 HIL 恰好一个都不具备。这篇文章把账算清楚：夜间全量为什么贵、行业怎么安排节奏、全球团队怎么协调“没有共同的夜”。

一、先算一笔账

假设用例库 5000 条，平均每条 3 分钟 → 全量一遍 = 250 机时。一台机柜一夜可用约 10 小时 → 需要 25 台机柜并行才能天亮看结果。一台 HIL 机柜几十万到上百万人民币——几千万固定资产投入，只为把全量回归塞进一个晚上。

不是做不到，是贵到只有大厂玩得起（头部 OEM 确有“机柜农场”干这个）。这就是“奢侈”的数学含义。

二、HIL 缺少的三个假设

1. 算力不可弹性扩展

• SIL 全量回归：CI 集群开 100 个容器分片，成本几美元
• HIL 扩并行 = 买更多机柜 + 机房空间 + 维护人力——阶梯式资本支出，不是按量付费

2. 时间不可压缩

• HIL 测的是真 ECU，它的时钟是物理时钟：1 秒仿真必须花 1 秒真实时间——实时调度存在的意义就在这里
• 10 分钟的 AEB 场景就是 10 分钟，没有加速按钮；SIL 用逻辑时钟可 10x~100x 快进
• HIL 的“一晚”对用例总时长有硬上限，用例库一长就溢出

3. 失败成本不低廉

• 机柜会出状况：接触不良、板卡故障、ECU 刷写后挂死
• 夜间无人值守跑全量，早上发现卡在第 3/5000 条——半夜机时全废，而机时是最贵的资源
• 所以敢放夜间的要么是筛过的稳定子集，要么得有人值班

三、还有两笔隐性开销

• 配置切换：不同车型/软件版本之间要换线束、刷 ECU、校准、台架初始化——setup 纯烧机时，还常需人工干预，天然反“无人值守”
• 排队竞争：多项目多团队共享机柜池，夜间档是抢手资源，你的全量回归排在别人的发版验证后面

四、所以行业怎么做

推论：scope: smoke / nightly / regression / release 这个用例标签维度，就是为“HIL 跑不起全量”这个资源现实设计的——全量回归压在 SIL 层，HIL 靠标签筛子集。“SIL 先行”不只是好实践，是经济必然。

五、哪些软件需要夜间回归

跳出 HIL 看全行业。夜间回归存在的根本原因只有一个：全量测试跑不进每次提交的分钟级流水线预算，只能攒到夜里批量跑。所以判断“哪类软件需要”，本质是判断“哪类软件的完整验证又慢又贵又必须有”。按这个逻辑过一遍：

六、共同特征：判断你的软件要不要

满足两条以上，夜间回归基本是刚需：

1. 全量测试时长 > 15 分钟：MR 流水线等不起（业界共识是 MR 反馈超过 10 分钟，开发者就开始绕过它）
2. 依赖稀缺资源：台架、GPU 集群、license 有限的仿真器——必须排队调度，排队天然适合夜间
3. 状态空间爆炸：平台矩阵（芯片×OS×变体）、场景库、参数组合——全量只能批处理
4. 质量门槛高：安全关键/合规行业，每次构建都要有“全量过一遍”的证据留存
5. 外部依赖每天在动：上游数据、第三方服务、模型权重——昨晚还过，今天就挂，只有 nightly 能抓住

七、业界通行的分层结构

每次提交/MR   → 冒烟（≤5~10 min）：编译 + 静态检查 + 20~50 条核心用例
每天夜间      → 全量功能回归：整个用例库 + 平台矩阵 + 性能基线对比
每周/按需     → 稳定性浸泡（soak）：数小时压力、内存泄漏、长稳运行
发布前        → 稀缺资源全量：HIL 全场景、认证证据包生成

关键点：夜间回归不是“唯一的测试”，而是分层金字塔的中间层——冒烟拦住 90% 的低级错误（反馈快），nightly 兜底剩下的（覆盖全），两层职责不重叠。

智驾域控软件其实同时命中上面表里好几行：嵌入式（台架稀缺）+ 安全关键（证据要求）+ 场景爆炸（智驾场景库）+ AI 成分（感知模型漂移）。这就是为什么智驾行业的测试架构清一色是“MR 冒烟 → 夜间 SIL 全量 → 发布前 HIL”的三层结构。

八、全球团队：地球上没有“共同的夜”

全球开发把“夜间回归”这个词里藏着的假设打破了：地球上没有“共同的夜”。上海夜里 2 点是慕尼黑晚上 8 点（他们还在提交）、加州上午 11 点（他们刚上班）。所以全球团队的第一课是认知转换：

nightly 的本质不是“夜里跑”，而是“固定节奏的快照回归”——协调的核心从“几点跑”变成“跑哪个快照、谁看结果、资源归谁”。

三种主流协调模式

汽车行业的现实答案通常是分区域窗口——因为 HIL 台架是物理资产，台架在哪个时区，就按哪个时区的夜来排（上海的台架跑上海的夜，慕尼黑的台架跑慕尼黑的夜），数据汇到统一看板。纯 SIL/GPU 资源则可以 follow-the-sun 连轴转——全球分布反而成了资源利用率的优势：同一片 GPU 农场，亚洲下班欧洲用，欧洲下班美洲用，24 小时不空转。

让三种模式都能转的五个关键机制

1. 按提交切，不按钟点切（最重要） “今晚的版本”必须是一个具体的 git SHA（如“18:00 前所有已绿 MR 的合并点”），而不是“跑的时候 main 上是什么”。否则德国同事 21:00 推的一个提交会溜进亚洲的回归里，结果张冠李戴。回归报告永远钉在 commit 上——所以规范的测试平台会把代码版本/工件哈希列为运行清单（run manifest）的一等公民。

2. 合并队列（merge queue / merge train）保住主干常绿 全球 24 小时都有人合并，主干必然频繁被撞红。合并队列让每个 MR 排队、先过门禁再合入，主干任何时刻都是绿的——回归才能放心地“随时取快照”。这是从“分窗口”走向“连续回归”的桥梁。

3. 自动归因与自动处置 夜间跑完发现挂了，不能让失败等 8 小时到责任人上班。成熟做法：

• 自动二分（bisect）定位肇事 commit
• 直接自动 revert 或自动打回（Google 的 TAP 就是这么干的）
• 按 CODEOWNERS 把失败路由到责任团队的看板/@值班人

4. 结果交接的“追日”流程 定义跨时区的接力 SLA，例如：亚洲早上由亚洲值班人首轮分诊（triage），属于欧洲模块的失败 @欧洲对应人，欧洲上班时看到的不该是“一片红”，而是“已初步归因、待你确认”。看板是唯一事实源，禁止用邮件/IM 传递失败结论。

5. flaky 治理全球统一 多时区最放大的毒瘤是 flaky test（时过时不过的用例）：亚洲标了“已知 flaky”，欧洲不知道，又查两小时。必须有全球统一的隔离区制度（连续 N 次不稳定就移出主干套件、单独跑、限期修复）。

一个典型的全球化配置

外资车企的典型配置：中国团队 + 欧洲总部 + 北美软件中心。常见的组合拳是：

• SIL 层：连续回归（无硬件约束，配合合并队列随到随跑），全球共享
• HIL 层：分区域窗口——各地台架跑各地夜间，用例库全球同一份（进仓库统一管理），结果汇聚同一证据库
• 平台能力清单（测试平台要内置的）：
  • 运行钉 SHA（运行清单里代码版本/工件哈希是一等公民）
  • 队列化调度 + 区域资源池（region: shanghai 标签路由到本地台架）
  • 失败按模块自动 @ 责任团队（从用例的 owner 字段读）
  • 跨时区统一的 flaky 标记与隔离清单

回看全文：“夜间全量”在 SIL 是标配，在 HIL 是奢侈品——行业的答案是分层：全量压给 SIL，HIL 靠标签筛子集，全球团队再把“夜”拆成区域窗口。而全球协调表面是时区问题，实质是快照治理、失败归属、资源调度三件事：时区只决定窗口几点开，剩下 90% 的工作是让任何时区的人早上打开看板，都能回答三个问题——跑的是哪个版本？谁弄挂的？现在轮到谁修？

附：名词解释（按出场顺序）