📚 课程目录第4章 CANoe中需求与测试用例的关联方式

4. CANoe中需求与测试用例的关联方式

在CANoe的测试体系中，测试用例不是孤立存在的脚本，而是需求的可验证载体。需求与测试用例之间的关联，决定了后续测试报告能否回答一个关键问题：这条需求到底被哪条用例覆盖了，覆盖结果如何？CANoe通过Test Case Editor、需求ID映射、属性字段与元数据配置三层机制，把这种关联从“人工记忆”变成“可查询、可追溯、可报告”的结构化数据。

一、Test Case Editor：关联关系的编辑入口

Test Case Editor是CANoe中管理测试用例元数据的核心界面。它并不负责编写CAPL或XML测试逻辑，而是负责给每条测试用例挂上“身份信息”。在Test Setup中右键一条测试用例，选择“Edit Test Case”即可打开该编辑器。典型字段包括：

Name：测试用例名称，建议采用“TC_功能_条件_预期”的命名规范，例如 TC_BMS_OverVoltage_Shutdown。
Description：用例目的与前置条件说明。
Requirement IDs：需求标识列表，支持一条用例关联多个需求ID，也支持多条用例关联同一需求。
Test Case Type：功能测试、边界测试、故障注入、回归测试等分类。
Priority：优先级，用于筛选执行集。
Custom Attributes：自定义属性，如验证阶段、所属子系统、ASIL等级等。

这些字段最终会写入测试报告。因此，Requirement IDs字段是需求追溯的“锚点”——没有它，报告只能显示“某用例通过”，无法回答“某需求是否被验证”。

二、需求ID映射：从需求库到测试用例

需求ID映射的本质是建立双向索引。假设需求管理工具（如DOORS、Polarion或Excel需求表）中有一条需求：

REQ_BMS_012：当电池单体电压超过4.25V并持续200ms时，BMS应在100ms内切断主继电器。

在CANoe中，对应的测试用例可以这样配置Requirement IDs：

Requirement IDs: REQ_BMS_012; REQ_BMS_015
Test Case Name: TC_BMS_OverVoltage_Cutoff
Test Case Type: Functional
Priority: High
Custom Attributes:
  Subsystem = BMS
  VerificationPhase = Integration
  ASIL = C

映射关系建立后，CANoe在生成测试报告时，会把每条用例的Requirement IDs提取出来，与需求清单做匹配。匹配结果通常呈现为三种状态：

状态	含义	处理建议
已覆盖	需求ID至少被一条用例引用，且用例已执行	检查通过率，确认是否满足覆盖准则
未覆盖	需求ID未出现在任何用例的Requirement IDs中	补充测试用例或标记为不适用
孤立用例	用例未关联任何需求ID	补充需求映射，或确认是否为探索性测试

实际项目中，需求ID的命名必须与需求库保持严格一致。常见错误是需求库中写 REQ_BMS_012，而CANoe中写成 REQ-BMS-012 或 BMS_012，导致匹配失败。建议在项目启动时统一ID格式，并在Test Case Editor中使用下拉选择或导入方式，而不是手工输入。

三、属性字段与元数据配置：让关联可筛选、可统计

仅有需求ID还不够。一个中型ECU项目可能有上千条测试用例，如果只靠需求ID关联，报告会变成一张巨大的平表。属性字段和元数据配置的作用，是把关联关系变成可分组、可筛选、可统计的维度。

CANoe允许在Test Case Editor中定义自定义属性，也支持通过Test Configuration的“Attributes”页面批量配置。常见的元数据维度包括：

需求层级：系统需求、软件需求、安全需求。
验证阶段：单元测试、集成测试、系统测试、整车测试。
测试类型：正常值、边界值、故障注入、鲁棒性。
覆盖准则：语句覆盖、分支覆盖、需求覆盖。
变更影响：关联的变更请求ID或缺陷ID。

这些属性会随测试报告一起导出。例如，在CANoe Test Report中按“VerificationPhase = Integration”筛选，可以快速得到集成阶段的测试结果；按“Subsystem = BMS”分组，可以统计各子系统的需求覆盖率。元数据配置的粒度应与项目追溯目标匹配：如果报告只需要回答“需求是否通过”，Requirement IDs加Pass/Fail即可；如果需要回答“哪个阶段、哪个子系统、哪种测试类型覆盖了该需求”，就必须配置对应的属性字段。

建议在Test Case Editor中把Requirement IDs设为必填字段，并在Test Configuration中启用“Check for missing requirement IDs”选项，避免遗漏关联。

四、关联关系的实际配置流程

下面以一条BMS过压保护需求为例，说明从需求到测试用例的完整关联配置过程。假设需求库中已有 REQ_BMS_012，测试用例已用CAPL编写完成并加入Test Setup。

在Test Setup中右键测试用例，选择“Edit Test Case”。
在Name字段填写 TC_BMS_OverVoltage_Cutoff。
在Requirement IDs字段输入 REQ_BMS_012，多条需求用分号分隔。
在Test Case Type中选择“Functional”，Priority选择“High”。
展开Custom Attributes，添加 Subsystem=BMS、VerificationPhase=Integration、ASIL=C。
保存后，在Test Configuration的Attributes页面确认这些字段已纳入报告模板。
执行测试，打开Test Report，检查Requirement IDs列是否显示 REQ_BMS_012，并确认该需求在覆盖率统计中被标记为“已覆盖”。

如果报告中没有出现需求ID，优先检查三处：Test Case Editor中是否填写、报告模板是否包含该列、需求ID拼写是否与需求库一致。

五、关联配置中的常见问题与判断依据

需求与测试用例的关联不是一次性配置，而是随需求变更持续维护的过程。以下问题在实际项目中高频出现：

需求ID拼写不一致：报告显示“未覆盖”，但用例实际已执行。判断依据是检查Test Case Editor中的ID与需求库是否逐字符一致，包括大小写、分隔符。
一条用例关联过多需求：导致失败时无法定位具体需求。建议一条用例关联的需求不超过3条，超出时拆分为多条用例。
元数据字段未纳入报告模板：配置了属性但报告不显示。判断依据是检查Test Configuration的Report页面是否勾选了对应属性列。
需求变更后未更新映射：需求ID已废弃，用例仍引用旧ID。建议在需求库变更后，用脚本或导出对比方式检查CANoe中的Requirement IDs列表。

需求ID映射一旦建立，不应在测试执行后随意修改。若必须修改，应在报告中保留变更记录，否则历史测试结果的可追溯性会被破坏。

总结来说，CANoe中需求与测试用例的关联由三个层次构成：Test Case Editor提供编辑入口，Requirement IDs建立追溯锚点，属性字段与元数据配置提供筛选和统计维度。三者配合，才能让测试报告从“用例通过率”升级为“需求覆盖率”，真正支撑需求追溯体系。