数据结构
网络
关系数据库管理系统
操作系统
Java
MS Excel
iOS
HTML
CSS
Android
Python
C 语言编程
C++
C#
MongoDB
MySQL
Javascript
PHP
物理学
化学
生物学
数学
英语
经济学
心理学
社会学
服装设计
法律研究什么是需求追溯矩阵？
需求追溯矩阵简介
追溯矩阵是一个表格样式的文档，用于跟踪软件应用程序开发中的需求。它可以用于向后追溯（从编码到需求）以及向前追溯（从需求到设计或编码）。需求追溯矩阵 (RTM) 或交叉引用矩阵是它的其他名称 (CRM)。
它是在测试执行过程之前生成的，以确保所有需求都以测试用例的形式得到解决，确保不会遗漏任何测试。我们在 RTM 文档中将所有需求与其关联的测试用例连接起来，以保证我们为每个条件编写了所有测试用例。
RTM 将由测试工程师为其分配的模块准备，并转发给测试主管。测试主管将转到存储库以查看测试用例是否存在，然后整合并准备单个 RTM 文档。
本文件的目的是确保每个需求都有一个测试用例，并且测试用例是根据客户的业务需求准备的。如果缺少任何需求，则将使用测试用例执行，这意味着没有为该特定需求设计测试用例，并且该特定需求将不会被测试，因为它可能包含错误。追溯的编写方式确保了所有需求都得到满足。
这类似于带有表格的工作表文档，但追溯矩阵还具有许多用户定义的模板。追溯矩阵中的每个需求都与其相应的测试用例相关联，允许按照需求指定的顺序运行测试。
重要 -
我们在批准后和执行前进行 RTM，以确保没有遗漏任何需求的测试用例。
我们不会在编写测试时编写 RTM，因为它可能未完成，并且我们也不会在编写测试用例后进行此操作，因为它可能会被拒绝。
RTM 文档确保每个需求至少有一个测试用例，但它不讨论该特定需求的所有可能的测试用例。
RTM 模板示例
RTM 的意义是什么？
每个测试人员的主要目标都应该是理解客户的需求并确保最终产品没有缺陷。为此，每个 QA 都应该正确理解需求并设计正面和负面的测试用例。
这意味着客户的软件需求必须进一步细分为场景和测试用例。必须分别处理每个案例。
**这里有一个问题** - 您如何确保在所有潜在场景/案例中都测试了需求？您如何确保在整个测试过程中没有遗漏任何需求？
跟踪需求及其相关的测试场景和测试用例是一种简单的方法。这通常称为“需求追溯矩阵”。
追溯矩阵通常是一个工作表，它提供需求以及所有可能的测试场景和案例，以及它们当前的状态，例如它们是否已通过或失败。这将有助于测试团队确定产品测试操作的范围。
追溯矩阵的目标
它有助于跟踪在 SDLC 的各个阶段创建的文档。
它确保程序完全满足客户的需求。
它有助于检测任何错误的根本原因。
追溯测试矩阵类型
以下是三种不同的追溯矩阵类型 -
前向追溯
后向或反向追溯
双向追溯
前向追溯
前向追溯测试矩阵用于确保每个业务的需求或要求在应用程序中得到正确实现和全面测试。主要目标是确保产品开发沿着正确的路径进行。然后，需求以正向方式映射到测试用例。
后向或反向追溯
反向或后向追溯用于确保我们不会通过改进设计元素、代码或测试不包含在业务需求中的其他项目来扩展产品的空间。并且其主要目标是使当前项目沿着正确的路径前进。在这种方法中，需求被反向映射到测试用例。
双向追溯
它是一种前向和后向追溯矩阵的组合，用于确保所有业务需求都包含在测试用例中。它还评估由于程序中的缺陷而导致的任何需求变化。
需求追溯矩阵中包含的参数
在需求追溯矩阵中，应包含哪些参数？
需求 ID
需求 ID 的类型和描述
测试用例的状态
| 需求编号 | 需求描述 | 测试用例 ID | 状态 |
|---|---|---|---|
| 123 | 登录应用程序 | TC01、TC02、TC03 | TC01-通过 TC02-通过 |
| 345 | 工单创建 | TC04、TC05、TC06、TC07、TC08、TC09、TC010 | TC04-通过 TC05-通过 TC06-通过 TC06-失败 TC07-未执行 |
| 456 | 搜索工单 | TC011、TC012、TC013、TC014 | TC011-通过 TC012-失败 TC013-通过 TC014-未执行 |
上面显示了一个需求追溯矩阵示例。
然而，在典型的软件测试项目中，追溯矩阵将包含比这些标准更多的内容。
需求追溯矩阵可以 -
显示覆盖所有需求所需的测试用例数量。
对于单个测试用例，存在设计状态和执行状态。
如果需要用户执行用户验收测试，则可以在同一矩阵中记录 UAT 状态。
在同一矩阵中，可以提及相关的缺陷及其当前状态。
这种类型的矩阵将成为所有测试需求的一站式服务。
除了保留一个单独的 excel 文件之外。测试团队还可以使用各种测试管理工具之一来跟踪需求。
需求追溯可以为您做什么
需求在哪里实现
例如，
**需求** - 在电子邮件应用程序中实现“撰写邮件”功能
**实现** - “撰写邮件”按钮应位于主页面上的哪个位置以及如何访问？
是否需要有需求？
例如，
**需求** - 仅允许指定用户在邮件应用程序中使用“撰写邮件”功能。
**实现** - 如果用户将电子邮件收件箱设置为“只读”，则“撰写邮件”按钮将不需要。
理解需求的最佳方法是什么？
例如，
**需求** - 在邮件程序中使用字体和附件功能“撰写邮件”。
**实现** - 按下“撰写邮件”按钮时应提供哪些功能？
撰写电子邮件的正文并以多种字体样式编辑它们，以及粗体、斜体和下划线。
多种类型的附件（图像、文档、其他电子邮件等）
附件的尺寸（允许的最大尺寸）
因此，需求被细分为子需求。
哪些设计决策会影响需求的实现
例如，
**需求** - 所有功能，如“收件箱”、“已发送邮件”、“草稿”、“垃圾邮件”、“垃圾箱”等都应该清晰可见。
**实现** - 可见项目应以“树”或“选项卡”格式显示。
所有需求是否都已分配
例如，
**需求** - 有一个“垃圾箱”邮件选项。
**实现** - 如果“垃圾箱”邮件选项可用，则必须首先实现并测试“删除”邮件选项（需求），以确保其正常工作。如果“删除”邮件选项工作正常，则只有已删除的邮件将被收集到“垃圾箱”中，并且采用“垃圾箱”邮件选项（需求）将是合理的（将是有用的）。
1K+ 次查看
