3. 场景测试基础

在NOA（Navigate on Autopilot，领航辅助驾驶）场景测试与量产验证中，最容易被混淆的不是工具链，而是四个基础概念：场景、用例、测试项、测试套件。它们看似只是文档层级，实际上决定了测试覆盖是否可度量、回归是否可复用、问题是否能追溯到具体触发条件。如果概念边界不清，团队常出现“场景写成了用例”“用例堆成了套件”“测试项无法定位失败原因”等问题，最终导致验证效率低下。

一、四个概念的定义与边界

场景（Scenario）是对驾驶任务所处环境与动态交互的抽象描述，回答“在什么道路、什么交通、什么天气、什么目标下行驶”。例如“城市主干道无保护左转，对向有直行车辆，雨天，目标为安全通过且不引发冲突”。场景强调语义与约束，不绑定具体参数取值，也不规定必须用哪种工具执行。

用例（Test Case）是在某个场景下，为验证一个明确功能或安全目标而设计的最小验证单元。它把场景收敛为可判定的输入与预期，例如“主车在路口等待，对向直行车距50m、速度40km/h，主车应在安全间隙内完成左转，且不触发AEB”。用例强调验证意图与预期结果，通常一个场景可派生多个用例。

测试项（Test Item）是用例的可执行实例，包含具体参数、初始状态、执行步骤、判定阈值与数据采集要求。例如“主车速度0km/h，对向车初始距离50m，相对速度40km/h，仿真步长10ms，判定：左转完成时间≤8s，最小TTC≥2.5s，无碰撞”。测试项强调可执行、可复现、可判定，是自动化执行与结果记录的最小单位。

测试套件（Test Suite）是按一定策略组织的测试项集合，用于批量执行、回归验证或版本准入。例如“城市路口左转回归套件”包含20个测试项，覆盖不同对向车距离、速度、天气与光照组合。套件强调组织策略与执行范围，通常与版本、里程碑、风险等级绑定。

二、相互关系：从场景到套件的追溯链

四者不是简单包含关系，而是多对多、可追溯、可复用的工程关系。一个场景可派生多个用例；一个用例可实例化为多个测试项（不同参数组合）；一个测试项可被多个套件引用（如冒烟套件、回归套件、夜间专项套件）。反过来，任何一个测试项失败，都应能向上追溯到用例意图与场景来源，向下定位到具体参数与日志。

三、方法流程：如何从场景构建到套件执行

工程实践中，建议按以下流程推进，避免概念混用：

1. 场景建模：从ODD（运行设计域）出发，按道路类型、交通参与者、天气光照、任务目标四个维度建立场景库，每个场景赋予唯一ID与语义标签。
2. 用例设计：针对每个场景，识别需要验证的功能点与安全目标，形成用例。用例应写明前置条件、操作意图、预期结果与失败判据。
3. 测试项实例化：将用例中的变量参数化，生成具体测试项。每个测试项必须包含初始状态、执行步骤、判定阈值、数据采集项与通过标准。
4. 套件编排：按版本准入、冒烟、回归、专项（夜间/雨天/拥堵）等策略，从测试项池中选取并组织套件，设置执行顺序与优先级。
5. 执行与追溯：批量执行套件，记录每个测试项结果；失败项自动关联用例与场景，形成缺陷报告与覆盖度分析。

四、案例与清单：城市路口左转验证

以“城市主干道无保护左转”为例，四层概念的具体落地如下表所示。该表可直接作为团队内部的概念对齐清单。

五、常见误区与复盘

# 测试项元数据示例（YAML）
test_item_id: TI-LT-001-01
case_id: TC-LT-001
scenario_id: SC-CITY-LT-001
suite_refs:
  - SUITE-CITY-LT-REG
  - SUITE-SMOKE-CITY
params:
  ego_speed_kph: 0
  oncoming_distance_m: 50
  oncoming_speed_kph: 40
  weather: rain
criteria:
  min_ttc_s: 2.5
  collision: false
  max_completion_time_s: 8

掌握这四个概念的定义与关系，是后续场景覆盖率统计、测试项自动生成、套件回归策略设计的基础。只有把“场景—用例—测试项—套件”这条链打通，NOA场景测试才能从手工堆砌走向工程化、可度量、可追溯的量产验证体系。