4. 测试需求分析与追溯

在ADAS量产测试与工程交付体系中，测试需求分析是把“系统要做什么”翻译成“测试要验证什么”的关键桥梁。系统需求通常以功能、性能、接口、安全目标等形式存在，例如“AEB在车速30～80 km/h范围内，对静止目标应在TTC≤1.2 s时发出制动请求”。测试需求不能简单复制这句话，而要把它拆解为可执行、可观测、可判定的验证条件：测试对象、触发条件、输入激励、预期响应、容差范围、通过准则。只有完成这种分解，后续的测试用例设计、台架/实车执行、结果判定才有稳定依据。

从系统需求到测试需求的分解方法

分解的核心不是“抄需求”，而是沿“功能链—接口—边界—异常”四个维度展开。以AEB前向制动为例，系统需求描述的是功能行为，测试需求需要回答：传感器输入是什么（目标距离、相对速度、RCS、置信度）、融合输出是什么（目标ID、TTC、碰撞概率）、执行器响应是什么（制动请求值、减速度、响应时间）、人机交互是什么（仪表报警、安全带预紧）。分解时建议采用“需求—功能—接口—测试点”的映射路径：先识别功能链上的关键节点，再为每个节点定义可测量的测试点，最后把测试点写成测试需求条目。

一个可操作的分解模板如下：每条测试需求包含唯一ID、来源系统需求ID、测试层级（部件/系统/整车）、前置条件、输入激励、观测变量、通过准则、容差、优先级。例如：

TR-AEB-012
来源：SR-AEB-004
层级：系统级
前置条件：车速 50 km/h，干燥沥青路面，目标静止
输入激励：目标距离 40 m，相对速度 -50 km/h，TTC 2.88 s
观测变量：TTC 触发时刻、制动请求值、减速度峰值
通过准则：TTC ≤ 1.2 s 时发出制动请求，减速度 ≥ 6 m/s²
容差：触发时刻 ±50 ms，减速度 ±0.5 m/s²
优先级：高

分解过程中最容易出问题的是“不可观测需求”。例如“系统应保证安全”无法直接测试，必须转化为“在定义场景下，碰撞避免率≥99.9%”或“误触发率≤1次/10万公里”。另一个常见问题是层级混淆：把部件级需求直接当成整车级测试需求，导致台架能过、实车不过。正确做法是明确测试层级，并在每一层保留可追溯的上游来源。

需求追溯矩阵

需求追溯矩阵（RTM）是保证“每条系统需求都有测试覆盖、每条测试需求都有来源”的核心工具。它通常以表格形式维护，行是系统需求，列是测试需求或测试用例，交叉点标记覆盖关系。RTM的价值在于：第一，防止需求遗漏；第二，防止测试冗余；第三，为变更影响分析提供索引。一个精简的RTM示例如下：

维护RTM时要注意双向追溯：正向追溯确认“需求→测试”无遗漏，反向追溯确认“测试→需求”无多余。对于安全相关需求（如ASIL等级），还应在RTM中增加安全目标ID和验证方法字段。实际项目中，RTM通常与需求管理工具（如DOORS、Polarion、Jama）联动，通过链接关系自动生成矩阵，避免手工维护导致版本错乱。

变更影响分析

ADAS项目需求变更频繁，可能来自法规更新、传感器选型变化、场景库扩充或客户反馈。变更影响分析的目标是快速回答三个问题：哪些系统需求变了？哪些测试需求/用例受影响？需要重跑哪些测试？RTM在这里起到索引作用：从变更的系统需求ID出发，反向查询所有关联的测试需求，再进一步查询测试用例、测试脚本、标定参数和场景文件。影响范围通常分为四类：直接覆盖失效、边界条件变化、接口时序变化、安全目标变化。不同类别对应不同的回归策略。

以“AEB触发TTC从1.2 s调整为1.0 s”为例，变更影响分析应识别：TR-AEB-012的通过准则需更新；关联的测试用例中TTC=1.1 s的边界用例需重新判定；场景库中静止目标、移动目标、弯道目标三类场景均需回归；标定参数中的触发阈值需同步修改；若涉及安全目标，还需重新评估ASIL分解是否仍然成立。实际工程中，建议为每条测试需求维护“变更敏感度”字段，标记其是否依赖标定参数、场景库版本或传感器配置，以便快速圈定回归范围。

总结来说，从系统需求到测试需求的分解，本质是把功能语言转化为可观测、可判定、可追溯的验证语言；RTM是维持这种转化的骨架；变更影响分析则是骨架上的神经反射。三者配合，才能在ADAS量产测试中既保证覆盖充分，又控制回归成本，最终支撑工程交付的可信度。