3. 需求追溯体系的基本概念

在汽车电子与 CANoe 测试项目中，需求追溯体系解决的核心问题是：每一个需求是否被测试覆盖、每一次测试执行对应哪条需求、每一个缺陷又回落到哪条需求或哪个测试用例。如果缺少这条链路，测试报告只能证明“测过”，却无法证明“需求被验证过”。追溯体系就是把需求、测试用例、测试结果、缺陷四类对象用可双向查询的关系连接起来，使覆盖率和影响分析可计算、可审计。

四类追溯对象及其关键属性

追溯体系中的四类对象并不是简单的文档，而是带有唯一标识和属性的可管理条目。在 CANoe 项目中，它们通常以需求管理工具（如 DOORS、Polarion、Jama）与测试管理工具（如 CANoe Test Feature Set、vTESTstudio、TestRail）之间的映射形式存在。

• 需求（Requirement）：唯一 ID（如 REQ-BCM-012）、需求文本、验收准则、优先级、版本、所属变体。验收准则是判断测试通过与否的最终依据。
• 测试用例（Test Case）：唯一 ID（如 TC-BCM-012-01）、前置条件、测试步骤、期望结果、关联需求 ID、执行环境（CANoe 配置、DBC、节点仿真）。
• 测试结果（Test Result）：一次执行的记录，包含用例 ID、执行时间、结果状态（Pass/Fail/Blocked/Not Run）、实测值、日志路径、CANoe 报告引用。
• 缺陷（Defect）：唯一 ID（如 BUG-2043）、发现该缺陷的测试结果、关联需求或测试用例、严重度、状态、修复版本。

四类对象之间的追溯链路可以概括为：需求 → 测试用例 → 测试结果 → 缺陷，并且缺陷可以反向指回需求或测试用例。正向追溯回答“这条需求被哪些用例覆盖、执行结果如何”；反向追溯回答“这个缺陷影响哪条需求、需要补测哪些用例”。

追溯链路的建立方式

追溯链路不是事后补写的表格，而是在需求评审通过后、测试用例设计阶段就同步建立的。以一条车身控制器需求为例：REQ-BCM-012 要求“车速大于 20 km/h 时，车门未关报警应在 200 ms 内触发”。测试工程师据此设计用例 TC-BCM-012-01，在 CANoe 中通过 CAPL 脚本模拟车速信号从 0 阶跃到 25 km/h，并监测报警信号的响应时间。

用例设计完成后，在测试管理工具中把 TC-BCM-012-01 与 REQ-BCM-012 建立“验证”关系。执行测试时，CANoe 生成测试报告，报告中的用例 ID 与结果状态被回写到测试结果对象。如果结果为 Fail，则创建缺陷 BUG-2043，并在缺陷中填写“发现于 TC-BCM-012-01”和“影响 REQ-BCM-012”。这样，从需求出发可以查到用例、结果、缺陷；从缺陷出发也可以反查到需求和用例。

追溯矩阵的字段与填写规则

追溯矩阵（RTM，Requirement Traceability Matrix）是追溯链路的表格化呈现。它的每一行通常对应一条需求，列则展开该需求关联的用例、结果、缺陷和覆盖状态。一个可用的 RTM 至少应包含以下字段：

填写 RTM 时最容易出现的问题是“只填用例 ID，不填结果和缺陷”。这样矩阵只能证明用例存在，不能证明需求被验证。正确的做法是：每次测试执行后，用脚本或工具接口把测试结果回写到 RTM 的“最近结果”列；当结果为 Fail 时，同步在“缺陷 ID”列填入缺陷编号。覆盖状态则根据结果自动计算：全部关联用例最近结果为 Pass 记为“已覆盖”；存在 Fail 或 Blocked 记为“部分覆盖”；无用例或全部 Not Run 记为“未覆盖”。

追溯体系在 CANoe 项目中的落地要点

在 CANoe 环境中落地追溯体系，需要把测试用例的标识与 CANoe 报告中的用例名称对齐。常见做法是在 vTESTstudio 或 CANoe Test Feature Set 中，把用例名称命名为与测试管理工具一致的 ID，例如 TC-BCM-012-01，这样生成的 XML/HTML 报告可以直接被解析并回写到 RTM。CAPL 脚本中也可以通过 TestReportAddExtendedInfo 之类的接口写入需求 ID，使报告本身携带追溯信息。

// CAPL 示例：在测试报告中写入需求追溯信息
testcase TC_BCM_012_01()
{
  TestReportAddExtendedInfo("Requirement", "REQ-BCM-012");
  TestReportAddExtendedInfo("TestCase", "TC-BCM-012-01");

  // 模拟车速从 0 阶跃到 25 km/h
  sysvar::VehicleSpeed = 0;
  testWaitForTimeout(100);
  sysvar::VehicleSpeed = 25;

  // 监测报警信号响应时间
  if (testWaitForSignalEvent(DoorAlarm, 1, 200) == 1)
  {
    TestStepPass("报警在 200 ms 内触发");
  }
  else
  {
    TestStepFail("报警未在 200 ms 内触发");
  }
}

这段脚本执行后，CANoe 报告会同时包含用例 ID、需求 ID 和 Pass/Fail 结果。测试工程师只需把报告解析结果导入 RTM，即可完成一次追溯闭环。若结果为 Fail，则创建缺陷并填写关联需求与用例，缺陷修复后重新执行同一用例，RTM 中的“最近结果”和“缺陷 ID”随之更新。

追溯链路的价值：从覆盖率到影响分析

建立追溯链路后，项目可以获得两类关键能力。第一是覆盖率计算：按需求统计“已覆盖 / 总需求”，得到需求覆盖率；按用例统计“已执行 / 总用例”，得到测试执行率。两者结合可以判断项目是否具备交付条件。第二是影响分析：当某条需求变更或某个缺陷修复时，沿追溯链路可以快速定位受影响的用例、需要重测的结果以及可能受牵连的其他需求。

例如，REQ-BCM-012 的响应时间从 200 ms 收紧到 150 ms，沿正向链路可以查到 TC-BCM-012-01 需要修改期望值并重测；沿反向链路可以查到 BUG-2043 是否与该需求相关，避免遗漏回归验证。追溯体系的意义正在于此：它让测试报告从“结果记录”升级为“需求验证证据”，让缺陷从“孤立问题”变成“可定位、可回归、可审计的追溯节点”。