4. 验收工程概述

在智能驾驶版本迭代中，回归测试回答的是“新版本有没有把旧功能改坏”，而验收测试回答的是“这个版本能不能交付、能不能上线、能不能进入下一阶段”。两者都重要，但目标、依据、判定方式和工程位置完全不同。验收工程的核心，是把“功能正确”提升为“可交付、可接受、可追溯”的工程结论。

一、验收测试的定义与目标

验收测试（Acceptance Testing）是在版本完成开发、集成和回归验证之后，由需求方、质量方或独立验收团队依据既定验收标准，对智能驾驶系统在真实或近似真实场景中的表现进行确认的活动。它的本质不是“再测一遍”，而是对交付条件做正式判定。

验收测试的目标可以归纳为四个层面：

• 功能符合性：确认版本实现了需求规格中承诺的功能，如自动跟车、车道保持、变道辅助、自动泊车等。
• 安全与合规性：确认系统满足法规、标准及企业安全规范，尤其是功能安全、预期功能安全和网络安全要求。
• 用户体验可接受性：确认接管频率、舒适度、交互提示、误触发等指标在用户可接受范围内。
• 交付可追溯性：确认每条验收项都能追溯到需求、设计、测试用例和缺陷记录，形成闭环证据链。

二、验收标准的三大来源

验收标准不是测试团队凭空制定的，它来自三个相互补充的源头：法规、标准与用户需求。三者共同构成验收判定的依据体系。

来源	典型内容	验收关注点	证据形式
法规	准入法规、道路测试规范、数据记录要求	是否允许上路、是否满足强制条款	法规符合性报告、测试记录
标准	ISO 26262、ISO 21448、ISO 21434、企业内标	功能安全、预期功能安全、网络安全	安全案例、危害分析、验证报告
用户需求	产品需求文档、用户故事、体验指标	功能可用、舒适、易理解、少接管	需求追溯矩阵、用户场景测试

法规是底线，标准是方法，用户需求是上限。验收工程需要把三者映射为可执行的测试项和判定阈值。例如，法规要求“系统失效时需提示驾驶员”，标准要求“提示应在规定时间内发出”，用户需求则要求“提示不刺眼、不干扰”。三者叠加后，验收用例才完整。

三、验收与回归的关系与区别

验收与回归不是替代关系，而是前后衔接、互补验证的关系。回归保证版本没有引入意外退化，验收保证版本满足交付门槛。没有回归，验收会被大量低级缺陷干扰；没有验收，回归通过也无法证明版本可交付。

从工程流程看，回归测试通常发生在每次代码合入或版本构建之后，强调自动化和快速反馈；验收测试则发生在版本冻结或发布候选阶段，强调正式性、可追溯性和签字确认。回归可以频繁跑，验收必须按里程碑跑。

四、方法流程：从标准到验收结论

验收工程不是“跑一遍用例”，而是一条从标准到结论的完整链路。建议按以下步骤组织：

1. 标准收集与拆解：收集法规条款、标准要求、用户需求，拆解为可验证的验收项。
2. 验收项映射：将每条验收项映射到具体测试场景、测试方法和判定阈值。
3. 用例设计与评审：设计正常、边界、故障、降级等场景，组织需求方、安全方、测试方联合评审。
4. 环境与数据准备：准备实车、台架、仿真、数据回放等环境，确保场景覆盖和可重复性。
5. 执行与记录：按验收项执行，记录通过/失败/阻塞，保留日志、视频、数据包等证据。
6. 缺陷回归与复验：失败项修复后必须复验，复验通过才可关闭。
7. 验收结论与签署：输出验收报告，明确通过项、遗留风险、限制条件和最终结论。

验收项示例：AEB 行人横穿场景
来源：法规 + 企业安全标准 + 用户需求
判定阈值：
  - 触发成功率 ≥ 99.5%
  - 误触发率 ≤ 0.1 次/千公里
  - 驾驶员接管提示延迟 ≤ 200 ms
证据：场景日志、视频、CAN 数据、接管记录
结论：通过 / 有条件通过 / 不通过

五、案例场景：一次验收中的典型分歧

某版本在回归测试中全部通过，但验收阶段被安全团队卡住。原因是：回归用例只覆盖了历史缺陷和变更影响范围，而验收标准中有一条“夜间无路灯条件下对横穿行人的识别距离不低于 60 米”。回归没有覆盖该场景，验收实测为 52 米。最终版本被判定为“有条件通过”，要求补充夜间场景优化后再复验。

这个案例说明：回归通过不等于验收通过。回归的覆盖范围由变更和风险决定，验收的覆盖范围由交付标准决定。两者必须分别设计，不能互相替代。

六、复盘：验收工程的三条底线

• 标准可追溯：每条验收项都能追溯到法规、标准或用户需求，不能凭空产生。
• 证据可复核：每个结论都有日志、数据、视频或报告支撑，不能只写“通过”。
• 结论可签署：验收报告必须明确通过范围、遗留风险和限制条件，避免模糊交付。

验收工程的价值，不在于“测了多少”，而在于“能否给出一个可信的交付结论”。回归让版本稳定，验收让版本可交付。两者配合，才能让智能驾驶版本在速度与安全之间取得平衡。