作者 | Qunying Song、Yuan Gao、Johannes Betz、Dietmar Pfahl、Mohammad Reza Mousavi、Federica Sarro
机构 | University College London、Technical University of Munich、University of Tartu、King's College London
论文 | In the Driver's Seat: A Multi-Company Study on the Reality of Autonomous Driving System Testing
版本 | arXiv:2607.15820v1（2026年7月17日）
关键词 | 自动驾驶测试 / 场景覆盖 / X-in-the-loop / 安全论证 / 闭环测试框架 / 访谈研究 / 仿真到现实01 这篇论文真正重要的，不是再发明一种测试工具，而是把 ADS 测试重新放回“证据闭环”
这篇论文不是常见的那类“提出一个新 planner / 新仿真器 / 新 benchmark 然后刷一组指标”的工作。它做的是另一件更基础、也更贴近产业现实的事：直接去问真正做 ADS 测试的人，行业今天到底怎么测、卡在哪、下一步会往哪里走。
论文团队采访了来自 9 家公司、6 个国家 的 9 位专家，讨论对象覆盖自动驾驶功能、ADAS、泊车、高速、城市和农村道路等不同 ODD，也横跨 L2 到 L5、模块化到端到端等不同系统形态。
这篇论文最值得记住的定位是：它把自动驾驶测试从“多跑一些场景”重新定义成 围绕安全主张组织证据的测试生命周期管理。
02 研究设计为什么值得看
这项研究的可信度，首先来自它并不是只找同一种角色做访谈。受访者里既有 system analyst、chief engineer、system tester，也有 researcher、senior engineer 和 engineering manager；从经验看，总行业经验跨度大致在 2 年到 14 年，且都直接参与过 ADS 测试。
论文围绕三个研究问题展开：
RQ1RQ2：这些实践最真实的难点在哪里，可能的解决方向是什么；RQ3
样本规模不是做统计显著性的那一路，但它的价值在于：这是一篇 跨公司、跨国家、跨角色 的经验归纳论文，重点是把零散工程经验收敛成一个更完整的行业图谱。
表1 / 表2：受访专家与公司分布。样本不大，但覆盖了不同角色、地区与企业类型。03 行业现在到底怎么测：主轴仍是 scenario-based，但组织方式比想象中复杂得多
论文最先确认的一件事是：行业对 ADS 测试已经形成了一种相对稳定的共识，那就是 场景驱动 和 X-in-the-loop。但这不意味着大家都按同一张固定流程图执行。相反，测试计划与策略往往是多因素共同决定的。
论文在测试策略层面总结出了几种常见思路：
- function-driven
- requirement-driven
- simulation-driven
- development-driven
- data-driven
- objective-driven
此外，论文明确写出了受访者所处 ADS 的分布：既有 ADAS / L2-L4，也有 L4 / L5；既有模块化系统，也有端到端和 hybrid 架构。这一点很重要，因为它解释了为什么测试策略不会只有一种标准模板。
图1：受访者所面对的 ADS 类型，包括功能、ODD、自动化级别与系统架构。04 一条典型测试链路，实际上横跨策略、流水线、活动、切换和验收
如果把论文的行业共识压缩成一条最典型的测试链路，大概会是这样：先做 test plan and strategy，再进入 MiL / SiL / HiL / ViL 以及 simulation、proving ground、on-road testing 等活动，过程中不断判断是否该进入下一阶段，最后再看证据是否足以支撑当前阶段的完成或发布。
这里最容易被低估的有三点：
- vehicle integration
- 阶段切换 往往不只靠一个指标，常常要把 metric、经验、变更分析和系统状态一起看；
- 验收标准 在很多公司里仍然不够统一，性能、覆盖率、数据饱和度和安全判断常常混在一起。
论文对这一层的总结非常完整，几乎可以直接拿来做 ADS 测试流程梳理的第一版 checklist。
图2：测试流程主题模型，覆盖策略、流水线、活动、阶段切换与满足标准。这篇论文有一个特别工程化的发现：真正决定测试质量的，往往不是“有没有做仿真”，而是 场景何时进入哪种环境、在什么条件下允许升级阶段、哪些证据才算够。05 场景驱动仍是主轴，但数据驱动已经深度渗进来了
从测试方法层面看，scenario-based approach 依然是绝对主流。受访者普遍围绕 parking、highway、urban 等具体功能和 ODD 来设计场景，并根据法规、常见交通分布和历史问题选择测试集合。
但与此同时，data-driven testing 已经不是边角料了。论文里提到的几种典型做法包括：
- 真实道路运行后，把事故、异常和失败场景回灌进后续测试集；
- 用 log replay 和 4D labeling 平台把 collected driving data 重新加工成训练与测试资产；
- 把 regression testing 做成持续循环，而不是版本末尾的一次性动作。
在评价指标上，论文给出的行业共识也很清晰：scenario coverage 是第一优先级，其次才是碰撞相关、舒适性、成功率、准确率和 fault rate 等指标。也就是说，行业真正焦虑的，不只是“某个测试跑过没有”，而是“关键场景库到底够不够”。
图3：方法、指标、基准与工具主题模型。场景驱动仍是主轴，但数据驱动已经深度进入流程。论文给出的现实判断很直白：重复刷大量低价值里程，并不能等价于真正的场景覆盖。 行业更在意的是能否尽快发现、组织、回放并回归那些高风险、高信息量的场景。06 真正卡住行业的，不只是仿真 fidelity，而是一整条测试链的可信性
挑战部分是整篇论文最有信息密度的一段。论文没有把问题只归结为“模拟器不够真”，而是把挑战拆到了多个层面：
- sim-to-real gaps：包括 simulation fidelity、representation 和 quality assessment；
- uncertain scenario realism
- incomplete coverage
- lack of public benchmarks / transparency
- deployment discrepancies
- data transfer challenge
- resource constraints
- unstable customer system
- non-reproducible issues
- unclear acceptance criteria：什么叫“safe enough”依然很难正式回答。
图4：ADS 测试挑战主题模型。问题并不只在仿真 fidelity，而是贯穿输入、执行、验收与发布。如果只挑一个更高层的问题，这篇论文其实在反复指向 acceptance criteria 和 safety argument。也就是：系统到底凭什么被认为“已经足够安全可以推进或发布”。不同专家给出的“最痛点”并不完全相同。有人把 coverage 看得最重，有人最担心资源与执行约束，也有人把 acceptance criterion 视为最紧迫问题。这说明 ADS 测试的难点是 系统级张力，不是某个单一技术模块的缺陷。07 行业下一步会往哪走：AI、世界模型、端到端和自动化测试都会进来
未来趋势部分很值得读，因为它不是泛泛地喊口号，而是把可能进入产业链的方向讲得很具体：
- 更高效率的测试流程：更多 operational log 会直接喂回不同测试阶段，缩短周期；
- AI-empowered testing：用 Agentic AI 或视频生成模型辅助场景创建；
- transparency and sharing：行业会越来越需要共享 benchmark、指标和知识；
- end-to-end infrastructures
- world models：更真实地建模环境与传感器交互，用于统一训练、仿真和测试；
- test automation
- reduced proven-in-use：减少“跑了很多年所以差不多安全”的被动论证方式。
图5：行业对未来测试演进的判断，关键词包括 AI、世界模型、自动化与透明共享。非常值得注意的一点是，world model 在这篇论文里并不是“一个热门模型名词”，而是未来测试基础设施的一部分。它服务的是更真实的环境生成、更统一的训练-仿真-验证接口。但论文同时保持了很强的克制。它明确提醒：只要 physics、sensor behavior 和 explainability 还没补齐，AI 生成场景和世界模型就很难直接支撑高风险验证。08 这篇论文最有建设性的交付，是一套六阶段证据闭环
相比“列出很多挑战”，这篇论文最有建设性的部分，是它最后没有停在问题清单，而是把访谈结果收束成了一套 evidence-centered closed-loop ADS testing framework。
如果用更工程的话翻译，这套框架的核心就是：
- 然后把证据编织成 safety argument 做推进或发布决策；
- 最后把运营反馈重新回灌进前面的 scenario portfolio 和 regression loop。
图6：论文提出的 evidence-centered closed-loop ADS testing framework，共六个阶段。这套框架最值得学的地方，是把“先想证明什么，再决定测什么，再决定去哪测，再决定证据够不够”真正串成了闭环。scenario list 不再是起点，safety claim 才是起点。09 如果把这套框架再抬高一层，它其实在讲“测试生命周期管理”
这也是这篇论文特别适合公众号完整解读的原因。它并不只是教团队多建几个场景、加几个指标，而是在要求团队重新理解测试资产的组织方式：
- 场景应该是 portfolio，而不是散落的孤立 case；
- 每个场景最好都带着来源、ODD、稀有度、关键性、oracle 和 evidence role 等元数据；
- 同一批场景不该默认在同一环境执行，而要按 evidence need 做 routing；
- 测试结果不该只汇总成 dashboard，而要进入安全论证和 release decision；
- 部署后的日志、接管、事故、OTA 回归，都应该回到前面的 testing loop。
可以把这篇论文放到一个更高的命题里来看：它讨论的其实是 自动驾驶测试生命周期管理。场景只是资产，证据才是主线，发布只是阶段节点，运营反馈才是闭环入口。10 这篇论文的边界也要看清
- 这是一篇 行业访谈研究，不是统一基准上的定量对比论文；
- 它给出的是跨公司经验与框架抽象，不是可直接拿来部署的现成工具链；
- PDF 给出了论文、DOI 和补充材料入口，但没有给出一个明确的“官方代码仓库”；
- 因此，这篇论文更像 方法论和流程框架，而不是“开箱即用的测试平台发布”。
11 公开入口与可跟进资源
- 论文页：https://arxiv.org/abs/2607.15820v1
- DOI：10.48550/arXiv.2607.15820
- 访谈问题与补充材料：https://doi.org/10.5281/zenodo.21408632
- 这份 PDF 没有给出专门的项目代码仓库，更适合把它当作产业方法论论文来读。
12 结论
把这篇论文压成几句最值得记住的话，大概是：
- 今天的 ADS 测试已经形成 scenario-based + X-in-the-loop 的主流共识，但真正决定质量的是证据如何被组织，而不只是场景跑了多少。
- 行业最难的两件事，始终是“场景够不够真、够不够全”和“证据到底够不够支撑 safe enough”。
- AI、世界模型、端到端和自动化测试会越来越重要，但它们进入高风险验证链条的前提，仍然是 fidelity、可解释性和证据可信度。
- 这篇论文最有价值的交付，不是一个新工具，而是一套把安全主张、场景资产、测试环境、证据门和运营反馈串起来的闭环框架。
如果用一句话收住：
自动驾驶测试真正缺的，不只是更多场景，而是把场景、证据、发布和运营反馈组织成一个可持续演化的闭环。
10个月宝宝每天需要喝多少奶粉？