从金融系统转到无人配送车后，我最明显的感受是：被测对象变多了。
以前主要面对服务、数据库、消息和资金状态。现在还要理解传感器、车端软件、自动驾驶算法、底盘、地图、远程协助和道路环境。系统输出也不再只是一个接口结果，它最终会变成车辆在真实道路上的动作。
我进入这个领域时间不长，下面更多是把已有的软件质量经验迁移过来之后形成的工作框架，不是对自动驾驶安全的完整答案。
质量边界为什么变了
软件系统里，很多要求可以写成确定性断言：金额一致、状态合法、消息不丢、接口在时限内返回。
无人车里仍然有大量这样的检查，例如任务下发、车云状态、OTA、鉴权和数据完整性。但自动驾驶能力还要面对场景分布：
- 光照、天气和道路条件变化；
- 行人、非机动车和其它车辆的交互；
- 临时施工、障碍物和交通规则变化；
- 传感器遮挡、退化和故障；
- 规划控制在边界条件下的行为。
“通过率”仍然有用，但必须说明分母是什么。1000 个重复的简单场景全部通过，不能说明一个关键高风险场景已经覆盖。
用 ODD 约束讨论范围
自动驾驶系统不应脱离运行设计域（ODD）谈能力。测试计划至少要明确：
- 允许的道路类型和区域；
- 速度范围；
- 天气、光照和能见度；
- 可接受的道路与交通参与者条件；
- 车辆、传感器和通信的最低状态；
- 超出范围时如何降级、停车或请求协助。
ODD 既是产品边界，也是测试边界。发现新问题时，首先要判断：这是 ODD 内能力不足、ODD 定义不清，还是系统没有正确识别自己已经越界。
场景要贯穿不同验证层
一个线上问题如果只剩一段描述，很难形成回归。更理想的状态是，同一场景能在不同层次被追踪：
线上事件
→ 关联车辆、版本、任务和 ODD
→ 提取关键数据与场景标签
→ 仿真或回放复现
→ 定位感知 / 预测 / 规划 / 控制 / 云端问题
→ 修复后分层回归
→ 重新进入场景库并非所有真实事件都能在仿真中完全复现。传感器噪声、硬件时序、道路摩擦和交通参与者行为都可能有差异。因此需要多层验证：
- 单元与接口测试；
- 软件在环（SIL）；
- 硬件在环（HIL）；
- 日志回放；
- 仿真场景；
- 封闭场地；
- 受控路测；
- 灰度运营与线上监控。
这些层次不是互相替代，而是逐步增加真实度和成本。
业务、产品和研发需要同一份事件
一次窄路通行失败，业务可能看到任务超时，产品看到场景能力缺口，研发看到规划阈值或感知结果。
测试开发能做的，是把这些视角关联到同一条事件记录：
- 订单或任务；
- 车辆和软硬件版本；
- 场景与 ODD 标签；
- 关键传感器和算法输出；
- 远程协助与人工操作；
- 用户或运营反馈；
- 最终根因和回归结果。
这比多开几次协调会更重要。只要数据对象没有对齐，各角色仍然会各自解释同一问题。
多车型不是简单复制测试项目
车型、传感器、底盘、算法版本和部署环境组合后，很容易形成很大的测试矩阵。我的理解是，平台需要把“共同能力”和“差异配置”分开。
共同能力包括：
- 场景库与标签；
- 仿真、回放和任务调度；
- 版本与配置管理；
- 指标计算和结果比较；
- 缺陷、修复和回归关联；
- 数据权限与审计。
差异配置包括：
- 车型几何与动力学参数；
- 传感器组合和标定；
- ODD；
- 车端、云端和算法版本；
- 客户环境与交付形态。
平台不能假设“同一个场景在所有车型上完全等价”。它更应该帮助团队看清：差异来自车型、配置、版本，还是随机波动。
私有化交付时，环境也属于产品
自有云环境相对可控，私有化部署则会引入更多变量：
- 操作系统、容器和中间件版本；
- 网络拓扑、带宽、NAT 和防火墙；
- 证书、时间同步和权限策略；
- 日志、指标和远程诊断能力；
- 客户侧变更造成的环境漂移。
因此测试对象不是一个安装包，而是“软件 + 配置 + 运行环境”。交付前要定义兼容矩阵和最低基线，部署后要有环境自检、升级检查、备份恢复和受控的远程诊断方案。
可观测数据是否能离开客户环境，还要服从合同、隐私和安全边界，不能默认全部回传。
中间件迁移先做语义清单
例如从一种 Redis 兼容服务迁移到另一种实现，接口看起来相近，行为仍可能不同：
- 过期、淘汰和持久化策略；
- 主从切换与故障恢复；
- Lua、事务、pipeline 和集群命令支持；
- 大 key、热点 key 和连接数限制；
- 客户端重试是否导致重复写；
- 监控指标和告警口径。
测试不应只跑功能回归，而要先列出依赖语义、生产流量画像和故障模式，再决定哪些可以平移，哪些需要改造。
指标要同时看安全、任务和体验
单一指标很难代表无人车质量。至少要分几组：
- 安全相关：关键事件、最小安全距离、急停、碰撞和 ODD 越界；
- 自动驾驶能力：场景通过、远程协助、人工接管和降级；
- 任务结果：完成率、时效、失败原因；
- 车辆与系统健康：传感器、车端资源、网络、云端依赖；
- 用户体验：等待、投诉、运营介入和可解释性。
远程协助率或行驶里程可以提供信息，但都不能单独证明安全。指标必须带场景分布、版本和运行条件。
AI 可以先用来整理证据
我目前更看好 AI 在低风险辅助环节的作用：
- 给日志和事件做初步归类；
- 汇总跨系统 trace；
- 检索历史相似问题；
- 从需求和故障复盘生成候选场景；
- 形成待验证的根因假设。
至于自动选择测试、自动调整场景、自动决定发布，还需要稳定评测、权限控制、人工确认和回滚机制。尤其在涉及车辆动作和安全决策时，不能因为模型输出流畅就扩大授权。
现阶段我更关心的几件事
- 线上事件能否稳定转成可回归场景；
- 同一指标能否在不同车型和版本间公平比较；
- 仿真、回放和路测的结果差异如何解释；
- 车端、云端和算法日志能否对齐到同一时间线；
- ODD 外行为和降级策略是否被充分验证；
- 用户与运营反馈能否回到工程数据。
从屏幕走到街道后，质量没有变成一个全新的学科，但很多旧经验需要重新校准。金融系统让我习惯检查不变量、幂等和对账；无人车又要求我学习场景、概率和物理后果。两者的共同点仍然是：重要结论要有证据，变更要能回滚，已知失败要进入回归。