在汽车研发项目中检查需求设计与测试的双向追溯，核心是沿“需求→设计→测试用例→测试结果”逐层核对正向覆盖与反向回链：正向确认每条需求都有设计承接和测试用例覆盖，反向确认每个测试用例和设计项都能回到明确需求。本文按判定口径、检查准备、分步操作、角色分工、单条示例和完成标准展开，适用于研发过程管理层面的追溯检查，不涉及控制算法与硬件设计内容。
要点总览（TL;DR）
- 双向追溯检查分两个方向：正向从需求出发确认每条需求都有设计承接和测试用例覆盖，反向从测试用例和测试结果出发确认都能回到明确需求，两侧都成立才算追溯链完整。
- 检查前先统一需求、设计项、测试用例的编号规则和追溯字段最小集合，并明确本次是全量核对还是按模块或变更抽样，否则比对结果会因粒度不一致而失真。
- 操作按五步执行：核对需求清单完整性、核对需求到设计承接、核对设计到用例覆盖、反向回查孤儿用例与断链、汇总缺口登记整改，每步留下核对表和结论。
- 覆盖缺口、孤儿项和断链是三类不同问题，整改责任人和处理方式不同，应分开记录和统计。
- 检查完成以覆盖率、孤儿项和断链数量对照约定阈值判断，需求变更后需同步更新追溯关系并纳入变更关闭动作，配合周期性抽查维持有效。
双向追溯检查的判定口径与追溯链结构
检查开始前，团队需要先就“什么算通过”达成一致，否则不同人核对同一批数据会得出不同结论。双向追溯的判定分为两个方向：正向追溯看覆盖，即从需求出发，能否找到承接它的设计项，以及覆盖该需求的测试用例；反向追溯看回链，即从测试用例和测试结果出发，能否回到一条明确的需求。两个方向都成立，才算这条需求的追溯链完整。
追溯链通常包含四层对象，链接方向如下：
| 层级 | 对象 | 上游链接 | 下游链接 |
|---|---|---|---|
| 第一层 | 需求项 | 来源（客户需求、法规要求、系统需求等） | 承接的设计项 |
| 第二层 | 设计项 | 来源需求 | 覆盖的测试用例 |
| 第三层 | 测试用例 | 来源需求与设计项 | 对应的测试执行记录 |
| 第四层 | 测试结果 | 所属测试用例 | 通过/失败结论及缺陷项 |
追溯粒度需要在检查前统一。需求项级粒度适合核对需求是否被设计和测试完整承接，功能级粒度适合按功能域做抽样核对，用例级粒度适合验证单条用例的回链准确性。粒度混用会导致比对结果失真，例如需求按功能级拆分而用例按需求项级关联，覆盖率统计就会出现无法对应的条目。实践中常见做法是以需求项级为主粒度，设计和用例向需求项对齐。
核对中会出现三类不同问题，需要分开记录：覆盖缺口指需求没有承接设计或没有测试用例覆盖；孤儿项指设计项或测试用例找不到来源需求；断链指链接指向的对象已被删除、合并或变更，导致链接失效。三类问题的整改责任人和处理方式不同，混在一起统计会让检查结论失去指导意义。
检查前的准备：标识规则、追溯字段与样本范围
检查能否顺利执行，取决于输入条件是否已经落定。首先要统一编号或标识规则，让需求、设计项、测试用例使用可互相引用的标识。常见做法是采用带层级前缀的编号，例如需求用REQ-模块-序号，设计用DES-模块-序号，用例用TC-模块-序号，并在编号中保留模块信息，便于按模块抽取样本。
追溯关系字段的最小集合应覆盖四类信息：来源需求、承接设计、覆盖用例、执行结果。下表可作为字段清单的起点：
| 字段 | 所属对象 | 填写要求 |
|---|---|---|
| 需求编号与版本 | 需求项 | 唯一，变更时递增版本 |
| 来源需求编号 | 设计项、测试用例 | 至少一条，允许多条 |
| 承接设计编号 | 需求项、测试用例 | 需求项至少一条；用例可关联设计项 |
| 覆盖用例编号 | 需求项、设计项 | 用于正向覆盖率统计 |
| 执行结果与执行日期 | 测试结果 | 关联到具体用例与版本 |
检查范围需要明确是全量核对还是抽样核对。项目早期或追溯关系刚建立时，建议对全部需求做一次全量核对，摸清基线；进入稳定迭代后，可按模块抽样，或针对本次变更涉及的需求做定向核对。抽样时应覆盖高风险模块、近期变更需求和历史上出现过断链的模块，避免只抽容易核对的部分。
检查所需输入包括：当前版本的需求清单、设计说明或设计项清单、测试用例库、测试执行记录、上一轮检查的缺口清单。责任人方面，需求负责人提供需求清单并确认需求完整性，设计负责人提供设计项与需求的对应关系，测试负责人提供用例与执行记录，质量或过程负责人负责组织核对并汇总结论。
分步检查操作：从需求到测试再回到需求
以下五步构成一次完整的双向追溯检查，每步都说明输入、动作、输出和完成标志，可按顺序执行，也可在数据量较大时按模块分批执行。
第一步：导出需求清单并核对需求项完整性
输入为当前版本需求库，动作为导出全部需求项并检查编号唯一性、版本状态和必填字段是否齐全，输出为一份可用于比对的需求基线清单。完成标志是清单中不存在重复编号、状态为“已批准”或“已基线”的需求均包含来源信息。若发现需求缺少来源或状态不明，先登记为待确认项，不进入后续覆盖核对。
第二步：逐条核对需求到设计的承接关系
输入为需求基线清单和设计项清单，动作为逐条检查每个需求项是否至少关联一个设计项，并确认设计项描述与该需求的范围一致。输出为需求—设计承接核对表，标注“已承接”“未承接”“承接但范围不符”三种状态。完成标志是所有需求项都有明确状态，未承接项已登记责任人和计划完成时间。
第三步：核对设计到测试用例的覆盖关系
输入为设计项清单和测试用例库，动作为检查每个设计项是否有测试用例覆盖，并核对用例的验证目标是否对应设计项的功能或约束。输出为设计—用例覆盖表，记录覆盖用例数量和覆盖状态。完成标志是每个设计项都有覆盖结论，覆盖不足的设计项已标注缺口类型，例如无用例、用例仅覆盖正常路径而缺少异常路径。
第四步：反向从测试用例与结果回查需求
输入为测试用例库和测试执行记录，动作为从用例出发检查其来源需求字段是否填写、指向的需求是否仍然有效，并核对执行结果是否关联到正确的用例版本。输出为反向回查清单，列出孤儿用例、指向失效需求的用例以及结果与用例版本不匹配的记录。完成标志是所有用例都有回查结论，孤儿用例已确认是补充用例还是应删除的冗余用例。
第五步：汇总缺口、断链与不一致项并登记整改
输入为前四步的核对表，动作为合并同类问题、按模块和责任人归类，形成缺口清单，并为每项问题指定整改动作、责任人和复核时间。输出为一份带缺口清单的双向追溯检查记录。完成标志是缺口清单中的每一项都有唯一编号、问题类型、影响范围和关闭条件，检查记录已提交评审。
在记录管理上，ONES 在 ASPICE 解决方案中提出支持跨域协作全过程的可追溯性，并提供需求池、测试管理与缺陷管理等模块，可用于承载需求项、用例与问题项的关联记录；具体的链接字段与覆盖统计方式需结合项目实际配置确认。
角色分工与各环节交付物
双向追溯检查如果只由质量人员单独完成，容易变成一次性文档核对，问题也难以推动关闭。合理的分工是各角色对自己产出的对象负责，质量或过程负责人负责组织、汇总和跟踪。
| 角色 | 检查中的职责 | 输入 | 输出交付物 |
|---|---|---|---|
| 需求负责人 | 确认需求清单完整、来源清晰、版本有效 | 需求库、变更记录 | 需求基线清单、需求完整性确认 |
| 设计负责人 | 确认设计项与需求的承接关系及范围一致性 | 设计说明、设计项清单 | 需求—设计承接核对表 |
| 测试负责人 | 确认用例覆盖关系、执行记录与用例版本匹配 | 用例库、测试执行记录 | 设计—用例覆盖表、反向回查清单 |
| 质量或过程负责人 | 组织检查、汇总缺口、跟踪整改与复核 | 各角色核对表 | 双向追溯检查记录、缺口清单、复核结论 |
问题项的确认与关闭遵循“谁产出、谁整改、谁复核”的原则：覆盖缺口由对应需求或设计负责人补充承接对象，孤儿项由测试负责人确认用例归属或提出删除申请，断链由链接维护方修复。质量或过程负责人负责复核关闭证据，确认整改后追溯关系可再次通过核对。
评审或会签的触发条件建议明确为：检查发现覆盖缺口涉及安全相关需求、缺口数量超过本轮约定阈值、同一模块连续两轮出现同类断链。满足任一条件时，组织需求、设计、测试三方会签，确认整改方案后再关闭检查。
示例：一个功能需求的双向追溯核对过程
以下为演示情景，用于说明单条需求的核对方式，不代表真实项目数据。
某车型项目有一条需求REQ-BCM-012：“车门未关提示应在车速超过设定值时触发仪表报警”。正向核对时，检查人员先在需求清单中确认该需求状态为已批准、来源为整车功能规范。随后在设计项清单中查找承接设计，发现DES-BCM-045描述了报警触发条件的判断逻辑，承接关系成立。继续核对设计到用例的覆盖，发现TC-BCM-101验证正常触发场景，TC-BCM-102验证车速未达设定值时不触发，覆盖情况基本完整，但缺少车门状态信号异常时的处理用例，登记为覆盖缺口。
反向核对时，从TC-BCM-101出发回查来源需求，链接指向REQ-BCM-012，回链成立；从TC-BCM-102回查时发现其来源需求字段指向一条已合并的旧需求REQ-BCM-008，属于断链。进一步筛查同模块用例，发现TC-BCM-118没有填写来源需求，属于孤儿用例，经测试负责人确认是早期补充的边界用例，应补挂到REQ-BCM-012。
问题登记后，测试负责人补充异常场景用例并关联到DES-BCM-045，链接维护方将TC-BCM-102的来源需求更新为REQ-BCM-012，TC-BCM-118补挂来源需求。复核时重新执行正向与反向核对，该需求的承接设计、覆盖用例和回链均成立，缺口与断链状态更新为已关闭，检查记录中保留整改前后的对照信息。
检查完成标准与后续维护
判断一次检查是否完成，可以对照以下清单逐项确认：
- 需求基线清单已确认，需求项编号唯一且状态明确；
- 每条需求都有承接设计结论，未承接项已登记责任人与计划完成时间；
- 每个设计项都有用例覆盖结论，覆盖缺口已分类记录；
- 每条测试用例都有回查结论，孤儿项与断链已确认处理方式；
- 缺口清单中每项问题都有编号、类型、责任人和关闭条件；
- 检查记录、核对表和证据已归档，可供后续复查调取。
完成阈值建议在检查前由项目约定，例如需求覆盖率、设计覆盖率、用例回链率的目标值，以及孤儿项和断链数量的可接受上限。阈值应结合项目阶段设定，早期阶段重点看缺口是否被识别和登记，稳定阶段再看关闭率。检查记录与证据按项目配置管理要求归档，保留版本信息，便于评估或审计时追溯。
追溯关系的持续有效依赖变更流程。需求发生变更时，应同步检查承接设计是否需要调整、覆盖用例是否需要新增或修改，并将追溯关系更新作为变更关闭的必做动作，避免历史链接形成假覆盖。周期性安排上，可在每个迭代或每个基线节点做一次定向抽查，每季度做一次全量复查，抽查范围优先覆盖变更频繁和高风险模块。ONES 通过统一的需求池、工单与任务看板同步状态与信息，可用于在日常协作中保持需求与问题项的关联记录，支撑变更后的追溯更新。
常见问题
需求、设计、测试用例的追溯粒度不一致时，检查结果还能用吗？
粒度不一致会直接影响比对结果的可信度。例如需求按功能级拆分，而测试用例按需求项级关联，覆盖率统计时就会出现无法对应的条目，缺口数量也会失真。遇到这种情况，建议先暂停覆盖统计，把粒度对齐到同一基准再继续核对。常见做法是以需求项级为主粒度，设计和用例向需求项对齐；如果项目已有功能级基线，也可以在功能级做抽样核对，但同一轮检查内应保持一种主粒度。
反向回查发现孤儿用例，应该删除还是补挂需求？
先判断这条用例是否仍在验证有效内容。如果它验证的是当前需求范围内的场景，只是来源字段缺失，应由测试负责人确认归属后补挂到对应需求，并同步检查是否需要关联设计项。如果它验证的功能已被删除或合并，且没有其他需求需要该用例，可以提出删除申请并保留删除记录。两种情况都需要在检查记录中写明判断依据，避免下一轮复查时重复出现同一问题。
需求变更后，追溯关系应该在什么时点更新？
建议把追溯关系更新作为需求变更关闭的必做动作，与变更评审同步完成。变更评审时确认承接设计是否需要调整、覆盖用例是否需要新增或修改，变更关闭前核对链接是否已同步。如果等到下一轮追溯检查再补，历史链接会形成假覆盖，检查时难以区分是遗漏还是变更未同步。对于影响安全相关需求的变更，还可以在变更评审中增加测试负责人会签环节。
全量核对和抽样核对分别适合什么阶段？
项目早期或追溯关系刚建立时，建议做一次全量核对，摸清基线并识别系统性缺口，例如某类需求普遍缺少设计承接。进入稳定迭代后，可以转为按模块抽样或针对本次变更需求做定向核对，抽样范围优先覆盖高风险模块、近期变更需求和历史上出现过断链的模块。无论哪种方式，检查记录都应保留核对范围和抽样依据，便于后续复查时判断结论的适用范围。
检查发现的问题由谁负责关闭，质量人员需要复核到什么程度？
问题关闭遵循“谁产出、谁整改、谁复核”的原则：覆盖缺口由对应需求或设计负责人补充承接对象，孤儿项由测试负责人确认归属或提出删除，断链由链接维护方修复。质量或过程负责人复核关闭证据，确认整改后追溯关系能再次通过正向与反向核对，而不是只看整改说明。涉及安全相关需求、缺口数量超过约定阈值或同一模块连续两轮出现同类断链时，建议组织需求、设计、测试三方会签后再关闭。
