测试中的需求可追溯性矩阵 (RTM) 是什么?
⚡ 智能摘要
需求可追溯性矩阵 (RTM) 是一个结构化文档,它将项目需求与相应的测试用例关联起来,确保全面覆盖和验证。它在软件测试中发挥着至关重要的作用,可以防止功能遗漏、支持合规性并为利益相关者提供可见性。
什么是可追溯性矩阵 (TM)?
可追溯性矩阵是一种将任何两个需要多对多关系的基线文档关联起来以检查关系完整性的文档。
它用于跟踪需求并检查当前项目需求是否得到满足。
什么是需求可追溯性矩阵?
需求可追溯性矩阵(RTM) 是一份将用户需求与测试用例进行映射和追踪的文档。它将客户提出的所有需求和需求可追溯性记录在一个文档中,并在项目结束时交付。 软件开发生命周期需求可追溯性矩阵的主要目的是验证所有需求都通过测试用例进行检查,以便在软件测试期间没有未检查的功能。
为什么 RTM 很重要?
每个测试人员的主要任务应该是了解客户需求,并确保输出产品没有缺陷。为了实现这一目标,每个 QA 都应该彻底理解需求,并创建正反两方面的测试用例。
这意味着客户提供的软件需求必须进一步分解成不同的场景,并进一步分解成测试用例。每个用例都必须单独执行。
这里出现了一个问题:如何确保需求得到测试,并考虑到所有可能的场景/情况?如何确保任何需求都不会被排除在测试周期之外?
一个简单的方法是跟踪需求及其相应的测试场景,并 测试用例。这被称为“需求可追溯性矩阵”。
可追溯性矩阵通常是一个工作表,其中包含所有可能的 测试场景 以及用例及其当前状态,例如,它们是否已通过或未通过。这将有助于测试团队了解针对特定产品进行的测试活动的级别。
谁需要 RTM?
A 利用需求可追溯性矩阵(RTM) 不仅适用于测试人员——它对于参与交付高质量软件或项目的任何人来说都很有价值。
- 质量保证和测试人员 → 通过映射良好的测试用例确保 100% 的需求覆盖率。
- 业务分析师 → 跟踪从 SRS/用户故事到执行的需求。
- 项目经理 → 了解范围、进度和错过的要求。
- 开发工具 → 了解功能如何映射回业务目标。
- 受监管行业 (医疗保健、汽车、航空航天、金融)→ 证明合规性并通过具有清晰可追溯性的审核。
- 客户和利益相关者 → 确保他们的要求得到实施和测试。
👉 简而言之,任何负责 构建、验证或批准软件需求 RTM 带来的好处。
需求可追溯性矩阵中应包含哪些参数?
- 需求编号
- 需求类型和 Description
- 带状态的测试用例
以上是需求可追溯性矩阵的示例。
但在一个典型的 软件测试 项目,可追溯性矩阵将包含不止这些参数。
如上所示,需求可追溯性矩阵可以:
- 以测试用例数量显示需求覆盖率
- 特定测试用例的设计状态以及执行状态
- 如果用户需要进行任何用户验收测试,那么 UAT 状态也可以在同一个矩阵中捕获。
- 相关缺陷和当前状态也可以在同一个矩阵中提及。
这种矩阵将提供 一站式商店 适用于所有测试活动。
除了单独维护 Excel 之外,测试团队还可以选择测试管理工具中提供的需求跟踪。
可追溯性测试矩阵的类型
在软件工程中,可追溯性矩阵可以分为以下三个主要部分:
- 向前追溯:此矩阵用于检查项目是否朝着期望的方向发展并开发出正确的产品。它确保每个需求都适用于产品,并且每个需求都经过彻底测试。它将需求映射到测试用例。
- 向后或反向追溯性: 它用于确保当前产品保持在正确的轨道上。这种可追溯性的目的是验证我们没有通过添加代码、设计元素、测试或其他需求中未指定的工作来扩大项目范围。它将测试用例映射到需求。
- 双向可追溯性(前向+后向): 此可追溯性矩阵确保测试用例覆盖所有需求。它分析了需求变更对测试用例的影响。 缺陷 在工作产品中,反之亦然。
如何创建需求可追溯性矩阵
让我们通过 Guru99 银行项目来了解需求可追溯性矩阵的概念。
在...的基础上 业务需求文档(BRD) 和 技术需求文件(TRD),测试人员开始编写测试用例。
假设下表是我们的业务需求文档或 BRD 等加工。为 Guru99银行项目.
这里的情况是,客户应该能够使用正确的密码和用户 ID 登录 Guru99 银行网站,而经理应该能够通过客户登录页面登录网站。
下表是我们的 技术需求文件(TRD).
请注意: QA 团队不会记录 BRD 和 TRD。另外,一些公司使用 功能需求文档 (FRD),它们与技术需求文档类似,但创建可追溯性矩阵的过程保持不变。
让我们继续在测试中创建 RTM
步骤1) 我们的 示例测试用例 is
“验证登录:输入正确的ID和密码后,应该可以成功登录。”
步骤2) 确定此测试用例正在验证的技术要求。对于我们的测试用例,正在验证技术要求 T94。
步骤3) 请注意测试用例中的此技术要求(T94)。
步骤4) 确定此 TR(技术要求-T94)定义的业务要求
步骤5) 注意测试用例中的BR(业务需求)
步骤6) 对所有测试用例执行上述操作。 Later,从测试套件中提取前 3 列。RTM 测试已准备就绪!
需求可追溯性矩阵的优势
- 确认测试覆盖率达到 100%
- 它突出显示任何缺失的要求或文件不一致之处
- 它显示了总体缺陷或执行状态,重点关注业务需求
- 它有助于分析或评估重新审视或重新编写测试用例对 QA 团队工作的影响
使用 RTM 的最佳实践和技巧
需求可追溯性矩阵 (RTM) 在以下情况下最有效 保持简单、一致并定期更新。以下是一些最佳实践,可以帮助团队确保 全面覆盖、最大程度减少返工并增强项目交付的信心:
- 尽早开始 → 在项目开始时创建您的 RTM。
- 保持更新 → 每当需求或测试用例发生变化时更新矩阵。
- 使用清晰的 ID → 为需求和测试用例分配唯一的 ID,以便于追踪。
- 涵盖正面和负面案例 → 确保每个要求都从多个测试角度进行验证。
- 跨团队协作 → 让测试人员、开发人员、BA 和项目经理参与维护 RTM。
- 杠杆工具 → 不要使用电子表格,而要考虑使用测试管理工具(如 Jira、HP ALM 或 Zephyr)来实现可扩展性。
- 版本控制 → 保留历史版本以跟踪变化并保持合规性。
- 专注于简单 → 避免矩阵超载;仅突出显示必要的参数。
- 定期审核 → 定期审查 RTM,以便在测试截止日期之前发现差距。
- 链接到商业价值 → 将需求映射回业务目标以显示投资回报率。
常见的RTM挑战和解决方案
- 挑战:保持 RTM 更新
需求和测试用例经常变化,导致 RTM 很快过时。
解决方案: 使用自动化测试管理工具实时同步需求、测试用例和缺陷。 - 挑战:过于复杂
添加太多参数会使 RTM 难以维护和解释。
解决方案: 通过仅关注 ID、描述和状态等重要字段来保持 RTM 精简。 - 挑战:团队协作不佳
不同的团队可能在所有权或更新方面不一致。
解决方案: 定义明确的角色,让测试人员、开发人员和分析师参与进来,并安排定期的 RTM 审查。 - 挑战:需求覆盖不完整
某些需求可能缺乏测试用例,导致功能缺失。
解决方案: 定期验证覆盖范围,使用双向可追溯性,并在主要版本发布之前运行审核。 - 挑战:大型项目中的手动工作
对于复杂的系统来说,在电子表格中管理 RTM 会变得非常耗时。
解决方案: 采用 Jira、HP ALM 或 Zephyr 等 RTM 工具来自动化映射和报告。
让我们通过视频中的示例来学习 RTM
点击 点击这里 如果视频无法访问
需求可追溯性矩阵 (RTM) 模板
点击下方下载 RTM 模板 Excel 文件