1. 课程导入
智能驾驶系统的研发节奏与传统车载电子有着本质差异。传统 ECU 的软件版本可能一年迭代一到两次，而一套城区 NOA 或高速领航辅助系统，算法模型、感知融合、规控策略、地图与定位模块往往以周甚至天为单位更新。版本迭代速度越快，“改一处、崩一片”的风险就越高：感知模型换了后处理阈值，可能让原本稳定的 AEB 误触发；规控参数调了舒适性权重，可能让匝道汇入的成功率下降；一个看似无关的日志埋点改动，也可能引入时序抖动，导致下游模块超时。
这正是本课程要解决的核心问题：如何让智能驾驶版本在快速迭代中保持可验证、可回归、可验收。回归与验收工程不是测试的附属环节，而是贯穿需求、开发、集成、发布全链路的工程能力。
一、智能驾驶版本迭代的典型挑战
与普通软件相比，智能驾驶版本迭代面临四类叠加挑战：
- 安全等级高：功能安全要求 ASIL-B/D，任何回归遗漏都可能对应实车风险，测试必须覆盖正常、边界与故障注入场景。
- 系统耦合深：感知、定位、预测、规划、控制、人机交互、车控执行形成长链路，单模块通过不等于系统通过。
- 场景长尾多：Corner Case 数量近乎无限，靠人工路测无法穷尽，必须依赖场景库、仿真与数据闭环。
- 版本组合爆炸：软件版本、模型版本、地图版本、标定参数、硬件配置相互组合，回归范围难以界定。
常见误区：把“回归测试”等同于“把上一版用例再跑一遍”。真正的回归工程需要先做变更影响分析，确定哪些模块、接口、场景、指标受影响，再决定回归范围与深度，否则要么漏测，要么把大量时间浪费在无关用例上。
二、回归与验收工程的定义
回归工程关注的是“变更之后，原有能力是否被破坏”。它以版本差异为输入，以影响域分析为方法，以自动化用例、仿真回放、实车抽检为手段，输出可量化的回归结论。
验收工程关注的是“这个版本是否达到可发布标准”。它以需求与验收准则为输入，以指标门限、场景通过率、安全冗余、性能基线为依据，输出明确的放行或阻断决策。
两者关系可以概括为：回归回答“有没有变坏”，验收回答“够不够好”。回归是验收的前置证据，验收是回归的最终出口。
三、一个典型场景：为什么“只跑旧用例”会失效
假设某版本将前视感知模型从 v2.3 升级到 v2.4，官方说明是“提升夜间行人召回”。如果只回归上一版的高速 NOA 用例，很可能全部通过，但城区场景中可能出现新的误检：夜间广告牌被识别为车辆，导致不必要的急刹。问题根源不在旧用例失效，而在于变更影响域没有被识别——模型后处理阈值变化会影响所有依赖感知输出的下游模块，包括 AEB、ACC、规划避让。
正确的做法是：先做影响分析，圈定“夜间 + 城区 + 广告牌/反光物体”场景，补充针对性用例，再执行全量回归。这样既控制成本，又避免漏测。
四、学习目标与课程框架
完成本课程后，你应当能够：
- 独立完成一次版本变更的影响域分析，输出回归范围建议。
- 设计并维护可复用的智能驾驶场景库与回归用例集。
- 搭建或接入自动化回归流水线，实现版本触发、执行、报告闭环。
- 定义验收指标门限，并基于数据做出放行或阻断决策。
- 对回归失败进行根因定位，推动缺陷闭环与版本复盘。
| 课程模块 | 核心内容 | 关键产出 |
|---|---|---|
| 基础与定义 | 回归、验收、版本、基线概念 | 术语与流程共识 |
| 变更影响分析 | 模块依赖、接口、场景映射 | 回归范围清单 |
| 场景库与用例 | 场景标签、优先级、版本绑定 | 可执行用例集 |
| 自动化回归 | 仿真、回放、台架、流水线 | 回归报告与趋势 |
| 验收与放行 | 指标门限、风险评估、发布冻结 | 验收结论 |
| 复盘与改进 | 缺陷根因、流程优化、度量 | 改进项与基线更新 |
学习建议：本课程强调“可操作”。每学完一个模块，建议结合你所在团队的版本发布流程，尝试输出一份对应的回归范围表或验收检查单。只有把方法落到真实版本上，回归与验收工程才会从概念变成能力。
智能驾驶版本迭代的速度不会放慢，安全要求也不会降低。回归与验收工程的价值，正是在速度与安全之间建立一套可重复、可度量、可追溯的工程秩序。接下来，我们将从最基础的版本与基线概念开始，逐步搭建这套秩序。