什么是可追溯性矩阵？
可追溯性矩阵是一个文档，它与需要多对多关系以检查关系的完整性的任何两个基线文档相关联。它用于跟踪需求并检查是否满足当前项目需求。
什么是需求追踪矩阵？
需求可追溯性矩阵（RTM）是一个文档，用于映射和跟踪带有测试用例的用户需求。 它在软件部署生命周期结束时提供的单个文档中捕获了客户提出的所有需求和需求可追溯性。 需求可追溯性矩阵的主要目的是验证是否通过测试用例检查了所有需求，以便在软件测试期间不取消任何功能。在本文中，您将了解：
- 为什么 RTM 很重要？
- 需求可追溯性矩阵中应包含哪些参数？
- 可追溯性测试矩阵的类型
- 需求追踪矩阵的优势
- 需求跟踪矩阵（RTM）模板
为什么 RTM 很重要？
每个测试人员的主要议程应该是了解客户的要求，并确保输出产品没有缺陷。 为了实现此目标，每个质量检查人员都应彻底了解需求并创建正面和负面的测试用例。
这意味着必须将客户端提供的软件需求进一步划分为不同的场景并进一步测试案例。 每种情况都必须单独执行。
这里出现一个问题，即如何确保考虑所有可能的场景/情况对需求进行测试？ 如何确保在测试周期内不遗漏任何要求？
一种简单的方法是使用相应的测试方案和测试案例来跟踪需求。 这仅称为“需求可追溯性矩阵”。
可追溯性矩阵通常是一个工作表，其中包含需求及其所有可能的测试方案和案例以及它们的当前状态，即它们是否已通过或失败。 这将有助于测试团队了解针对特定产品完成的测试活动的级别。
需求追踪矩阵中要包括哪些参数？
- 需求编号
- 需求类型和说明
- 状态测试用例
以上是样本需求可追溯性矩阵。
但是在一个典型的软件测试项目中，可追溯性矩阵将具有比这些参数更多的特性。
如上所述，需求可追溯性矩阵可以：
- 在测试用例数量中显示需求覆盖率
- 特定测试用例的设计状态以及执行状态
- 如果用户要进行任何用户接受测试，那么 UAT 状态也可以捕获在同一矩阵中。
- 相关的缺陷和当前状态也可以在同一矩阵中提及。
这种矩阵可以为所有测试活动提供一站式服务。
除了单独维护一个 excel。 测试团队还可以选择跟踪需求的可用测试管理工具。
可追溯性测试矩阵的类型
在软件工程中，可追溯性矩阵可分为以下三个主要部分：
- 前向可追溯性：此矩阵用于检查项目是否按期望的方向进行，并且产品正确。 它确保每个要求都适用于产品，并且每个要求都经过了彻底的测试。 它将需求映射到测试用例。
- 向后或反向可追溯性：用于确保当前产品是否保持在正确的轨道上。 这种类型的可追溯性的目的是通过添加代码，设计元素，测试或要求中未指定的其他工作来验证我们没有扩大项目范围。 它将测试用例映射到需求。
- 双向可追溯性（向前+向后）：此可追溯性矩阵确保测试用例满足所有要求。 它分析了工作产品中受缺陷影响的需求变更的影响，反之亦然。
需求追踪矩阵的优势
- 它确认 100％的测试覆盖率
- 它突出显示了所有缺少的需求或文档不一致的地方
- 它显示整体缺陷或执行状态，并着重于业务需求
- 在重新审视或重新测试测试用例方面，它有助于分析或评估对质量检查小组工作的影响
制作需求跟踪矩阵（RTM）的工具
制作需求跟踪矩阵（RTM）可以使用多种工具，具体选择取决于你的需求、团队规模、预算和个人偏好。以下是一些常用的工具：
- Microsoft Excel或腾讯文档，比较适合无预算的团队，该类工具的缺点是它们缺乏自动化、集成和复杂需求管理功能，难以支持大型或动态变化的项目，不适合十人以上规模的团队。而优点在于这些电子表格工具广泛可用，易于学习和使用。
- 专业项目管理软件，比如PingCode：这是国内非常推荐使用的，因为这是一个高级的需求管理和跟踪系统，可以用来创建详细的需求跟踪矩阵、跟踪需求、故事、任务和bug，并且与项目计划、测试用例、任务等全流程环节集成。
- 独立的需求管理工具：比如IBM Rational DOORS：这是海外一个高级的需求管理和跟踪系统，适合复杂的项目。
比如以下截图就是使用PingCode进行需求跟踪管理的示意：
选择合适的工具时，要考虑以下因素：
- 项目的规模和复杂性：大型项目可能需要更专业的工具来管理复杂的需求。
- 团队的工作方式：敏捷团队可能更喜欢灵活的看板式工具，而传统团队可能更喜欢详细的需求文档。
- 预算：一些工具是免费的或提供免费版本，而更专业的解决方案可能相对昂贵。
- 集成需求：如果需要与其他系统（如代码仓库、持续集成工具等）集成，要选择支持这些集成的工具。
以上就是关于需求跟踪矩阵（RTM）的全部内容希望对大家有所帮助。
