4. 夜间回归工程需求分析
夜间回归的价值不在于“跑得多”，而在于“跑得准、判得清、报得明”。如果回归范围、用例筛选、执行频率、通过准则、失败分类和报告需求没有事先定义，夜间回归很容易退化为每天生成一堆红色结果、却没人能据此做出发布判断的“噪声机器”。本节的目标是把这些需求固化为一份可执行的夜间回归规格（Nightly Regression Specification），使流水线在无人值守的夜间也能给出可信的结论。
回归范围定义：先划边界，再谈覆盖
回归范围定义要回答三个问题：哪些被测对象进入夜间回归、覆盖哪些功能域、明确排除什么。对于 dSPACE HIL 项目，被测对象通常包括被控对象模型（Plant Model）、实时 I/O 与故障注入板卡、诊断与网络通信（CAN/LIN/FlexRay/Ethernet）、以及标定与测量链路。范围定义建议以“功能域 × 测试层级”的矩阵方式表达，而不是简单罗列用例名。
一个实用的做法是引入回归等级：L0 为冒烟集（每次提交触发，约 10～20 分钟），L1 为夜间核心回归（每晚执行，覆盖主要功能与安全相关路径），L2 为周度扩展回归（覆盖边界、组合与长时工况）。夜间回归规格主要约束 L1，并明确 L1 与 L0、L2 的衔接关系。范围之外的内容必须显式写出，例如“本轮不覆盖 OTA 升级流程”“不覆盖未冻结的标定数据版本”，避免后续对结果产生歧义。
测试用例筛选：从全量到可执行子集
夜间回归的时间窗口有限（通常 8～10 小时），必须从全量用例中筛选出高价值子集。筛选依据可归纳为四类：需求追溯（用例是否关联到已冻结的需求 ID）、变更影响（本次提交或本迭代改动的模块）、历史失效（近 N 次回归中失败过的用例）、风险等级（安全相关 ASIL 等级或客户关键功能）。
筛选不是一次性动作，而应形成规则。例如：所有 ASIL C/D 相关用例必选；与本次变更文件存在依赖关系的用例必选；近 5 次回归中失败过的用例必选；其余用例按风险权重排序，在时间预算内取前若干条。这样既保证关键路径始终被覆盖，又能让用例集随项目演进动态调整。
执行频率与调度约束
执行频率需要与开发节奏匹配。常见约定是：每日夜间执行一次 L1 回归；每周固定一天执行 L2 扩展回归；每次合并到主分支前必须通过 L0 冒烟。夜间回归规格中应写明触发时间（如每日 22:00）、最长允许时长、以及超时后的处理策略（截断并标记未执行用例，而不是静默丢弃）。
调度还需考虑 HIL 台架资源。若只有一台台架，多个测试任务必须串行排队；若有多台，可按功能域分片并行。规格中应明确台架分配、用例分片规则和资源冲突时的优先级，避免夜间任务互相抢占导致结果不完整。
通过准则：从“全绿”到可判定的阈值
通过准则不能简单定义为“所有用例通过”。更合理的做法是分层判定：阻塞级用例必须 100% 通过，否则整轮回归判定为失败；核心级用例允许不超过约定数量的失败，但必须全部有明确失败分类；观察级用例失败不阻塞发布，但需记录趋势。同时应定义稳定性指标，例如用例通过率、失败复现率、平均执行时长波动范围。
对于 HIL 测试，还需注意“通过”的判定依据：是模型输出与期望值的偏差在容差内，还是诊断码、总线报文、故障注入响应满足预期。规格中应写明每类判定的容差来源和采样窗口，避免同一用例在不同台架上得出不同结论。
失败分类与报告需求
失败分类是夜间回归能否被信任的关键。建议至少分为：产品缺陷（被测对象或模型问题）、测试缺陷（用例、期望值或脚本问题）、环境问题（台架、板卡、网络、电源异常）、基础设施问题（CI 调度、版本、依赖失败）、未分类（需人工确认）。每类失败应附带可追溯信息：用例 ID、需求 ID、台架编号、软件版本、日志与测量文件路径。
报告需求方面，夜间回归应自动生成一份摘要报告，包含：执行时间窗、用例总数与通过/失败/跳过数量、失败分类分布、与上一轮的差异（新增失败、已修复、持续失败）、以及是否满足通过准则的结论。报告应支持按功能域和失败分类下钻，便于次日晨会快速定位。
可执行的夜间回归规格示例
将上述需求整理为一份可直接落地的规格表，字段应覆盖执行所需的最小信息集。以下为示例结构（参数为教学示例，实际项目需按台架与项目约束调整）：
| 规格项 | 示例内容 | 判定/约束 |
|---|---|---|
| 回归等级 | L1 夜间核心回归 | 每日 22:00 触发，最长 9 小时 |
| 覆盖范围 | Plant Model、CAN 诊断、故障注入、标定测量 | 排除 OTA 与未冻结标定版本 |
| 用例筛选规则 | ASIL C/D 必选；变更依赖必选；近 5 次失败必选；其余按风险权重取前 200 条 | 总用例数控制在 350 条以内 |
| 台架分配 | HIL-01 负责动力域，HIL-02 负责底盘与诊断 | 分片并行，冲突时按 ASIL 优先级排队 |
| 通过准则 | 阻塞级 100% 通过；核心级失败 ≤ 3 且全部已分类 | 不满足则整轮判定为失败 |
| 失败分类 | 产品缺陷 / 测试缺陷 / 环境问题 / 基础设施 / 未分类 | 未分类项须在次日 12:00 前完成归类 |
| 报告输出 | 摘要报告 + 差异对比 + 失败下钻链接 | 次日 07:00 前推送至项目看板 |
从规格到流水线：落地要点
规格确定后，需要将其转化为流水线可执行的配置。例如，用例筛选规则可以写成标签表达式（如 asil in [C,D] or changed_dependency or recent_failure），通过准则可以写成断言脚本，失败分类可以借助日志关键字和退出码自动预分类。夜间回归的最终产物不是“跑完了”，而是一份能直接支撑发布决策的结论：本轮回归是否通过、失败集中在哪个功能域、哪些失败属于产品缺陷、哪些需要人工复核。
当范围、筛选、频率、准则、分类和报告六个环节都被明确定义并自动执行时，夜间回归才真正成为持续集成中可信赖的质量门禁，而不是每天早上一堆需要人工解释的红色结果。