需求追溯矩阵把需求、实现、用例和缺陷放进同一张表，让每条需求都能查到由谁实现、用什么用例验证、发现了哪些缺陷。本文提供可直接复制的空白表，逐字段说明含义与取值来源，区分必填与选填，并用一条需求从提出到缺陷关闭的完整示例演示填写方式，最后给出随需求变更维护矩阵的方法。
要点总览（TL;DR）
- 追溯矩阵用一张主表串起需求、实现、用例、缺陷四段链路，每行对应一条需求或一个验收点，另配验收点拆分表和缺陷回填表。
- 必填字段保证链路不断：需求编号、需求名称、验收标准、覆盖判断始终必填；实现工作项编号、用例编号、执行结果、缺陷编号按阶段补齐。
- 填写示例以 REQ-0182 订单导出需求演示：实现工作项 TASK-0456、用例 TC-0311 与 TC-0312、缺陷 BUG-0774 修复回归后覆盖判断填“已覆盖”。
- 维护围绕需求变更更新行、用例与缺陷及时回填、按覆盖判断筛出缺口定期核对三件事展开，编号直接引用各库既有编号。
- 团队可先用表格跑通字段口径，再把需求、用例、缺陷作为关联对象放到同一工具中，减少重复维护。
可复制的需求追溯矩阵空白模板
追溯矩阵按“需求—实现—用例—缺陷”四段链路组织。主表每行对应一条需求或一个验收点，横向展开实现、验证和缺陷信息。下面三张表可以分别复制到表格工具或文档中使用，表头保持一致即可。
主追溯表（需求—实现—用例—缺陷）
| 需求编号 | 需求名称 | 验收标准 | 优先级 | 实现工作项编号 | 负责人 | 实现状态 | 用例编号 | 用例类型 | 执行结果 | 执行日期 | 缺陷编号 | 严重程度 | 缺陷状态 | 覆盖判断 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
一条需求对应多个用例或多个缺陷时，有两种处理方式：在主表中用逗号分隔多个编号，或者拆成多行、每行一个用例或缺陷。需求验收点较多时，建议采用下面的验收点拆分表，主表只保留需求级汇总。
需求与验收点拆分行模板
| 需求编号 | 验收点编号 | 验收点描述 | 对应用例编号 | 验收点结果 | 关联缺陷编号 | 覆盖判断 |
|---|---|---|---|---|---|---|
缺陷回填行模板
| 缺陷编号 | 缺陷标题 | 关联需求编号 | 关联用例编号 | 严重程度 | 发现日期 | 当前状态 | 修复版本 | 回归结果 | 关闭日期 |
|---|---|---|---|---|---|---|---|---|---|
追溯矩阵各字段说明
字段口径统一，矩阵才能被产品、开发、测试不同角色一致填写。下表按需求侧、实现侧、验证侧、缺陷侧和覆盖判断分组，说明每个字段的含义、取值来源和主要填写角色。
| 分组 | 字段名 | 含义 | 取值来源 | 填写角色 |
|---|---|---|---|---|
| 需求侧 | 需求编号 | 需求的唯一标识，矩阵的主键 | 需求库中的既有编号，不另起编码 | 产品经理 |
| 需求侧 | 需求名称 | 需求的简短标题，便于人工识别 | 需求库标题 | 产品经理 |
| 需求侧 | 验收标准 | 判断需求是否完成的客观条件 | 需求描述中的验收条款 | 产品经理 |
| 需求侧 | 优先级 | 需求的相对重要程度 | 需求库优先级字段 | 产品经理 |
| 实现侧 | 实现工作项编号 | 承接该需求的任务、故事或开发单编号 | 项目管理工具中的工作项编号 | 开发负责人 |
| 实现侧 | 负责人 | 实现工作项的责任人 | 工作项指派字段 | 开发负责人 |
| 实现侧 | 实现状态 | 实现工作项的当前进度 | 工作项状态字段，如待开始、进行中、已完成 | 开发负责人 |
| 验证侧 | 用例编号 | 验证该需求的测试用例唯一标识 | 用例库中的既有编号 | 测试人员 |
| 验证侧 | 用例类型 | 用例的验证层次或类别 | 用例库分类，如功能、接口、性能、回归 | 测试人员 |
| 验证侧 | 执行结果 | 用例最近一次执行结论 | 测试执行记录，如通过、失败、阻塞、未执行 | 测试人员 |
| 验证侧 | 执行日期 | 用例最近一次执行的日期 | 测试执行记录时间 | 测试人员 |
| 缺陷侧 | 缺陷编号 | 执行失败或使用中发现的缺陷标识 | 缺陷库中的既有编号 | 测试人员 |
| 缺陷侧 | 严重程度 | 缺陷对业务或系统的影响等级 | 缺陷库严重程度字段 | 测试人员 |
| 缺陷侧 | 缺陷状态 | 缺陷当前处理阶段 | 缺陷库状态字段，如新建、修复中、待验证、已关闭 | 测试人员 |
| 缺陷侧 | 关联需求 | 缺陷所影响的需求编号 | 缺陷单中填写的关联需求 | 测试人员 |
| 覆盖判断 | 覆盖判断 | 该需求当前是否被有效验证 | 由用例结果与缺陷状态综合判定，取值见下文 | 测试负责人 |
覆盖判断建议使用固定取值，避免各人写法不一：已覆盖指该需求下所有验收点都有用例且执行通过；部分覆盖指部分验收点有用例或部分用例未通过；未覆盖指尚无对应用例；待验证指缺陷已修复但回归尚未执行。判定时以验收点为单位逐条核对，再汇总到需求级。
哪些字段必填、哪些可以选填
必填字段保证链路不断：从需求能追到实现，从实现能追到用例，从用例能追到缺陷。选填字段用于补充分析信息，按团队需要启用。下表给出对照。
| 字段 | 填写要求 | 理由或适用场景 |
|---|---|---|
| 需求编号 | 必填 | 矩阵主键，缺失则整行无法定位 |
| 需求名称 | 必填 | 便于评审和核对时快速识别 |
| 验收标准 | 必填 | 覆盖判断的依据，没有验收标准就无法判断是否覆盖 |
| 实现工作项编号 | 必填（进入开发后） | 建立需求到实现的链路 |
| 用例编号 | 必填（用例设计完成后） | 建立需求到验证的链路 |
| 执行结果 | 必填（测试执行后） | 覆盖判断的直接输入 |
| 缺陷编号 | 必填（发现缺陷时） | 建立验证到缺陷的链路 |
| 覆盖判断 | 必填 | 矩阵的核心结论字段 |
| 优先级 | 选填 | 用于排期和缺口排序时建议填写 |
| 负责人 | 选填 | 需要按人统计实现进度时填写 |
| 实现状态 | 选填 | 需要跟踪开发进度时填写 |
| 用例类型 | 选填 | 需要区分功能、接口、性能等验证层次时填写 |
| 执行日期 | 选填 | 需要判断验证时效时填写 |
| 严重程度 | 选填 | 需要按缺陷影响排序时填写 |
| 缺陷状态 | 选填 | 需要跟踪缺陷闭环时填写，建议与缺陷库保持一致 |
| 备注 | 选填 | 记录例外情况、阻塞原因等 |
填写要求可以随阶段放宽，避免在信息尚不完整时强行填满：需求评审前，至少填写需求编号、需求名称、验收标准和优先级；用例设计前，补齐实现工作项编号和用例编号；测试执行后，填写执行结果和执行日期；缺陷产生后，回填缺陷编号、严重程度和状态；需求关闭前，覆盖判断必须为已覆盖或经评审确认的例外。分阶段规则的作用是让矩阵在早期保持轻量，在交付前保持完整。
完整填写示例：一条需求从提出到缺陷关闭
以下示例为演示数据，用于说明字段之间的联动关系。假设某系统需要支持“订单导出”，产品经理提出需求，开发完成实现，测试设计用例并执行，过程中发现一个缺陷，修复后回归关闭。
需求侧：需求编号 REQ-0182，需求名称“订单列表支持按时间范围导出”，验收标准为“选择起止日期后可导出对应订单，导出文件字段与列表一致，单次导出不超过 5 万条”，优先级为高。
实现侧：实现工作项编号 TASK-0456，负责人为开发人员甲，实现状态为已完成。
验证侧：用例编号 TC-0311，类型为功能，执行结果为失败，执行日期为 6 月 12 日；补充用例 TC-0312 验证导出条数上限，执行结果为通过。
缺陷侧：执行 TC-0311 时发现导出文件缺少“下单渠道”字段，缺陷编号 BUG-0774，严重程度为严重，状态为已关闭，关联需求 REQ-0182。开发修复后，测试于 6 月 15 日回归通过，缺陷关闭。
覆盖判断写法：该需求有两个验收点，导出字段一致性和导出条数上限。前者由 TC-0311 验证，缺陷修复后回归通过；后者由 TC-0312 验证通过。因此覆盖判断填写“已覆盖”，备注中注明“BUG-0774 已修复并回归通过”。如果缺陷尚未关闭，覆盖判断应填写“部分覆盖”，备注写明“等待 BUG-0774 回归”。
| 需求编号 | 需求名称 | 验收标准 | 优先级 | 实现工作项编号 | 负责人 | 实现状态 | 用例编号 | 用例类型 | 执行结果 | 执行日期 | 缺陷编号 | 严重程度 | 缺陷状态 | 覆盖判断 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| REQ-0182 | 订单列表支持按时间范围导出 | 选择起止日期可导出对应订单；导出字段与列表一致；单次不超过 5 万条 | 高 | TASK-0456 | 开发甲 | 已完成 | TC-0311、TC-0312 | 功能 | TC-0311 失败后回归通过；TC-0312 通过 | 6 月 15 日 | BUG-0774 | 严重 | 已关闭 | 已覆盖 | BUG-0774 已修复并回归通过 |
矩阵的调整与日常维护方法
矩阵失效通常来自三种情况：需求改了但行没更新，用例和缺陷新增后没有回填，覆盖缺口长期无人核对。维护动作围绕这三类问题展开。
需求变更时的行更新规则
需求内容或验收标准发生变化时，先更新需求侧字段，再沿实现工作项和用例检查影响范围：验收标准新增的，补充对应用例行；验收标准删除的，将相关用例标记为失效并在备注说明；需求拆分或合并的，保留原需求编号并在备注中记录新编号，避免历史追溯断链。变更后覆盖判断应重置为“待验证”，直到新用例执行完成。
新增用例与缺陷的回填时机
用例设计完成后即回填用例编号，不必等到执行；测试执行当天回填执行结果和日期；缺陷创建后回填缺陷编号、严重程度和状态，缺陷关闭并回归通过后更新状态和备注。回填时机与测试活动同步，可以避免在版本发布前集中补表。
定期核对覆盖缺口的方法
建议每个迭代结束前和版本发布前各核对一次。核对时按覆盖判断字段筛选出“未覆盖”“部分覆盖”“待验证”的行，逐条确认原因：是用例缺失、执行未完成，还是缺陷未关闭。对确认的缺口指定责任人和处理时间，处理后更新覆盖判断。核对节奏可按团队交付频率调整，交付频繁时缩短间隔。
矩阵与需求库、用例库、缺陷库的同步方式
矩阵中的编号应直接引用各库的既有编号，不另建一套编码。同步方式有两种：手工维护时，以需求库为源头，每次需求评审后同步更新矩阵；使用工具承载时，可以把需求、用例、缺陷作为关联对象放在同一处，矩阵由关联关系生成或导出。ONES 的 ALM 方案以数字线程贯通需求、开发、测试、变更与发布，把测试用例、缺陷、版本和发布过程关联到需求链路中，需求变化时可以沿关联关系分析受影响的任务、测试和交付内容，并保留过程追踪依据（依据官方方案资料，具体字段与配置以实际部署版本为准）。团队可以先用手工表格跑通字段口径，再迁移到工具中减少重复维护。
常见问题
需求拆成多个验收点时，主表和验收点拆分表怎么分工？
主表保留需求级汇总，一行对应一条需求；验收点拆分表按验收点逐行展开，记录每个验收点对应的用例、结果和缺陷。覆盖判断先在拆分表按验收点逐条判定，再汇总到主表。这样需求数量多时主表不会过度膨胀，核对缺口时又能定位到具体验收点。
一条需求对应多个用例或多个缺陷，矩阵里怎么记录？
两种方式都可行：在主表单元格内用逗号分隔多个编号，或者拆成多行、每行一个用例或缺陷。用例和缺陷数量少、以需求为核对单位时用前者；需要按用例或缺陷单独跟踪状态时用后者。无论选哪种，同一张表内保持统一，避免同一列混用两种写法。
缺陷修复后回归未执行，覆盖判断应该填什么？
填“待验证”。覆盖判断的“已覆盖”要求该需求下所有验收点都有用例且执行通过，缺陷修复但回归尚未执行时，验证链路还没有闭合。等回归通过后再改为“已覆盖”，并在备注中记录缺陷编号和回归日期；回归失败则回到“部分覆盖”，继续跟踪。
矩阵用表格手工维护，什么时候适合迁移到工具里？
当需求变更频繁、用例和缺陷数量增长，手工同步开始出现漏填或编号对不上时，可以考虑迁移。迁移的前提是字段口径已经跑通，各库编号规则稳定。使用工具承载时，可以把需求、用例、缺陷作为关联对象放在同一处，矩阵由关联关系生成或导出。ONES 的 ALM 方案以数字线程贯通需求、开发、测试、变更与发布，把测试用例、缺陷、版本和发布过程关联到需求链路中，需求变化时可以沿关联关系分析受影响的任务、测试和交付内容（依据官方方案资料，具体字段与配置以实际部署版本为准）。
需求拆分或合并后，历史追溯记录怎么保留？
保留原需求编号，在备注中记录新编号和拆分或合并的日期，原行不删除。新需求行重新建立实现、用例和缺陷关联，覆盖判断重置为“待验证”。这样按旧编号仍能查到当时的验证记录，按新编号能跟踪当前进展，历史链路不会断。
