QA 中的 RTM：需求可追溯矩阵

需求追溯矩阵：结构及其在QA中的应用

需求追溯矩阵（RTM）是一种表格，用于记录软件生命周期各阶段中需求、测试用例和缺陷之间的关系。它回答了关键问题：哪些已测试、哪些未覆盖，以及为何执行特定测试。

没有RTM，测试会失去透明度；有了它，测试就成为一个可测量的过程，具有清晰的覆盖率指标。

使用矩阵的目标

RTM解决以下任务：

• 评估测试对需求覆盖的完整性。
• 识别测试文档中的空白。
• 分析需求变更对现有测试的影响。
• 追踪从需求到缺陷的路径。
• 为利益相关者生成带有量化指标的报表。

这些功能使RTM在需求广泛的中大型项目中不可或缺。

RTM中的追溯类型

构建关系有不同的方法：

| 类型 | 链接方向 | 应用场景 |

|------|-------------------|-------------|

| 正向 | 需求 → 测试用例 | 验证需求是否有对应测试 |

| 反向 | 测试用例 → 需求 | 证明测试的必要性 |

| 双向 | 需求 ⇄ 测试用例 | 双向全面控制 |

| 垂直 | 需求 → 设计 → 代码 → 测试 | 跨阶段端到端追溯 |

| 水平 | 测试 → 缺陷 → 修复 → 复测 | 测试内部的追溯 |

类型的选择取决于项目复杂度和开发阶段。

RTM表格的列结构

标准矩阵包含以下字段：

• 需求ID — 唯一标识符（REQ-AUTH-01）。
• 需求描述 — 简要描述（电子邮件授权）。
• 测试用例ID — 相关测试用例列表（TC-LOGIN-01、TC-LOGIN-02）。
• 测试状态 — 执行状态（通过/失败/阻塞/未执行）。
• 缺陷ID — 缺陷标识符（BUG-101）。
• 缺陷状态 — 缺陷状态（未解决/已修复/已关闭）。
• 覆盖状态 — 覆盖状态（已覆盖/未覆盖/部分覆盖）。
• 覆盖率% — 覆盖率百分比（100%/0%/50%）。

RTM表格示例

基础表格（需求与测试用例）

| 需求ID | 需求 | 优先级 | 测试用例ID | 测试状态 | 缺陷ID | 覆盖率% |

|--------|-------------|----------|--------------|-------------|-----------|------------|

| REQ-01 | 授权 | 高 | TC-LOGIN-01、TC-LOGIN-02、TC-LOGIN-03 | 通过、通过、失败 | BUG-101 | 100% |

| REQ-02 | 密码恢复 | 中 | TC-REC-01、TC-REC-02 | 通过、未执行 | — | 50% |

| REQ-04 | 价格筛选 | 低 | — | — | — | 0% |

带开发链接的扩展表格

| 需求ID | 需求 | 测试用例ID | 结果 | 缺陷ID | 开发任务 | 组件 |

|--------|-------------|--------------|--------|-----------|----------|-----------|

| REQ-01 | 登录 | TC-AUTH-01 | ✅ 通过 | — | TASK-101 | 授权模块 |

| REQ-01 | 登录 | TC-AUTH-03 | ❌ 失败 | BUG-001 | TASK-101 | 授权模块 |

此类表格便于快速定位问题区域。

文本追溯模式

经典正向链接

┌──────────────┐      ┌──────────────┐      ┌──────────────┐
│ 需求         │      │ 测试用例     │      │ 缺陷         │
│ REQ-01 ──────┼─────▶│ TC-01 ───────┼─────▶│ BUG-101      │
└──────────────┘      └──────────────┘      └──────────────┘

端到端垂直追溯

┌─────────────────────┐
│ 业务需求            │
└──────────┬──────────┘
           ▼
┌─────────────────────┐    ┌─────────────┐
│ 功能需求            │───▶│ 测试用例    │
└──────────┬──────────┘    └──────┬──────┘
           │                     │
           ▼                     ▼
┌─────────┐              ┌─────────────────────┐
│技术任务 │              │ 测试执行            │
└────┬────┘              └──────────┬──────────┘
     │                             │
     ▼                             ▼
┌─────────────────────┐    ┌─────────────────────┐
│ 缺陷                │    │ 追溯完成            │
└─────────────────────┘    └─────────────────────┘

覆盖率统计分析

典型的RTM报告包括：

| 指标 | 值 | 公式 |

|--------|-------|---------|

| 总需求数 | 50 | — |

| 有测试的需求数 | 45 | — |

| 无测试的需求数 | 5 | — |

| 覆盖率% | 90% | (45/50)×100% |

| 每个需求的平均测试数 | 3.6 | 180/50 |

常见错误：矩阵过时、链接形式化、缺乏缺陷链接、重复测试。

QA工程师检查清单

• 每个需求至少有一个测试用例。
• 没有无链接的“孤立”测试用例。
• 需求变更时更新相关测试。
• 每个缺陷都链接到需求。
• 每个冲刺/发布后更新矩阵。
• 可通过RTM分析失败原因。

RTM自动化工具

| 工具 | 类型 | 功能 |

|------|------|----------|

| Jira + Xray/Zephyr | 插件 | 敏捷追溯 |

| TestRail | 测试管理 | 原生RTM |

| Qase | 测试管理 | 简单链接 |

| Excel/Google表格 | 手动 | 适用于小项目 |

| Polarion/Azure DevOps | ALM | 企业级 |

何时避免使用RTM

矩阵不适用于：

• 需求少于20个的项目。
• 团队少于3人。
• 短冲刺（1-2周）。
• 临时测试或频繁变更的MVP。

缺点：更新工作量大、形式化风险、对初创企业有开销。

规则： RTM在需求超过20个且团队3人以上时才有回报。

关键要点

• RTM确保大型项目中测试覆盖90%以上的需求。
• 双向追溯最小化回归测试风险。
• 矩阵相关性是其价值关键；每次变更后更新。
• 企业级使用ALM工具实现自动化。
• 分析指标：覆盖率空白和每个需求的测试用例数。

— Editorial Team