当项目的需求“动态”变化并且您没有手头的功能或模块来监视每个需求的实现时，就会出现问题：如何分析范围？ QA团队在此类项目上使用的工具之一是可追溯性矩阵。
目前，我们已经使用矩阵超过2.5年。 在这段时间里，我们能够评估该工具的优势，并使其适应我们的项目。
什么是可追溯性矩阵？
根据定义，可追溯性矩阵是一个二维表，其中包含产品功能需求（功能需求）和准备好的测试用例（测试用例）的对应关系。
在相应行和列的交点处，放置一个标记，表明此测试用例满足了此要求。
因此，该表直观地显示了两个参数：
- 系统中是否存在尚未涵盖的需求（如果需求与测试用例没有单个交集（充分条件）；
- 系统中是否有过多的测试-如果需求有多个交叉点（必要条件）。
在我们的项目中，我们不仅使用可追溯性矩阵来评估覆盖范围，而且还可以确定开发任务，需求和测试工件之间的关系。
因此，矩阵具有表的形式，其每一行包含：
- 跟踪器任务中开发任务的编号和描述；
- 任务所属的逻辑块（可选）；
- 原子要求或接受标准；
- 优先权
- 相应测试工件的编号和说明。
由于我们使用Jira任务跟踪器，Jira的Zephyr来获取测试文档和Confluence需求管理系统，因此所有实体都是同步的，这种可追溯性使我们能够：
- 可视化当前的实施状态；
- 将需求分解为更多的原子需求并进行结构化；
- 监视是否有尚未计划开发的需求（实施阶段）；
- 监视当前是否已实施要求；
- 监视需求是否包含在测试用例中（跳过测试）；
- 可视化需求的优先级。
可追溯性矩阵中的关系选项
绑定要求和测试用例可以是：
- 一对一（原子需求，由一个测试用例覆盖，该测试用例仅覆盖此需求）；
- 1到n（一个需求包含在多个测试用例中，这些测试用例仅覆盖此需求）；
- n到n（几个测试用例涵盖的要求，这些测试用例涵盖了此要求和其他要求）。
关于最后一点，我想指出
- 当可追溯性矩阵中的一项要求被多个测试覆盖时，这可能表明测试是多余的。 在这种情况下，有必要分析需求的原子性。
- 如果通过执行所有测试用例我们确保覆盖范围的完整性，并且测试用例本身彼此不重复，那么这将不是过多的测试。
在我们的项目中，有一个案例包含多个测试，而一个测试可以覆盖多个需求（“ 1到n”和“ n到n”连接）。
使用可追溯性矩阵进行覆盖估计的特异性
如果我们使用度量“需求数量与测试工件数量的比率”来评估覆盖率，则矩阵中的关系应为“ 1对1”，并且需求应分解为最大数量。
一个例子。 我们有一个非原子性的要求：“用户必须能够在文本编辑器中修改和格式化字母。” 一个测试用例显然是不够的，但是如果矩阵中仅链接了一个工件，则从视觉上将可以满足要求。
因此更好：
- 将矩阵中的此要求分为文本编辑器的单独原子功能；
- 为每个功能写一个验收标准；
- 为每个标准创建一个测试工件；
- 如果一个检查表可以满足几个基本要求，那么您就不能进行过多的碎片化处理，从而节省了资源。
缺乏最大分解所需的资源，您可以使用非原子性需求，但要覆盖每个需求，您需要创建多个测试工件。
在这种情况下，一次编译每个非原子需求的测试用例和检查表，也就是说，矩阵中的每个需求要么完全被工件覆盖，要么根本不覆盖。
编译矩阵时，建议遵循以下建议：单个矩阵中每个需求的分解应该近似相等，即一张表不应包含需求，其中一些需求需要5个测试用例，而一部分需要一个测试用例。
在这种情况下，覆盖率得分是针对每个矩阵分别计算的。
由于我们的项目文档对每种功能的外观可能有所不同，甚至对一项功能的描述也可能包含UML，图表，用户案例和过渡图，并且该项目包含40多种丰富的功能，因此我们决定为每个模块或功能开发一个单独的矩阵，以便不要失去该工具的任何优势。
还针对每个模块或功能分别计算覆盖率得分。
通过这种方法，我们可以使用上述度量：“测试工件数量的需求数量”。 即使我们具有1到n，n到n的连接，我们也有几个组件，每个组件都可以在多个模块中使用。 在每个矩阵中描述了需求和接受标准，并使用了一个测试工件。
我们的矩阵也存储在Confluence需求管理系统中-每个矩阵都与结构一起定位，该结构作为为其开发功能的子页面。 另外，所有矩阵都收集在一页上，以方便评估整个应用程序的覆盖范围。
创建和维护矩阵
创建矩阵包含在分析任务的工作流程中。
当我们收到有关新功能的信息时，我们团队的分析师将在任务跟踪器中创建任务，并与产品所有者一起在客户方面作为此任务的一部分。 在收集和组织需求的过程中，整个团队都会进行审查并提出其他问题。 当需求由客户制定，记录和确认后，开发团队负责人将创建用于开发此功能的任务，测试团队便可以开始创建跟踪矩阵。
在这里，我们可以区分出可追溯性矩阵的以下几个阶段：
- 首先，通过质量检查和/或产品所有者命令分解需求并确定优先级。 此步骤的结果是此功能的所有要求的结构化优先列表。
- 第二阶段将与开发团队进行沟通，并从跟踪器的任务到矩阵中的开发任务分配相关需求。 结果，我们可以跟踪开发需求和任务的可追溯性。
- 第三阶段是测试用例和检查表的开发。
此阶段在测试特定任务之前或期间进行。
如果功能是新功能，并且界面将更改，则在某些情况下，最好在测试任务之前立即描述步骤。
如果实现功能与现有功能之一相似，那么我们可以在审查和分解需求之后立即开始用步骤描述测试用例。 - 阶段4-用测试用例填充矩阵。
基于整个过程的结果，我们获得了开发任务，用于测试的测试用例以及将它们与需求结合在一起的可追溯性矩阵。
开发需求的任务正在关闭。 - 阶段5-将矩阵保持在当前状态。 必须对要求进行任何修改。 您还应该考虑描述不同功能或模块的两个矩阵之间的集成关系，并且在更改其中之一时，请确保检查是否需要编辑第二个矩阵。
使用可追溯性矩阵的困难
- 实现
该矩阵仅在始终保持最新的情况下才有用。 在要求经常变化的项目中，更新花费了很多时间，但是如果矩阵不更新，不仅变得无用，而且会造成混乱。
如何决定 ：
需求的频繁更改部分地解决了该问题，并将创建矩阵的阶段转移到团队已审查需求并获得客户确认的那一刻。
团队决定，分析师不仅要在页面上用功能描述来更新需求，而且还要在矩阵中查找和更新需求，并用不同的颜色突出显示。 这有助于整个团队，尤其是质量保证团队，不会丢失所做的更改-查看哪些测试用例需要更新。 - 临时资源
该项目可能需要紧急发布并同时满足新需求，并且所有QA资源均已发送以进行测试，而不符合需求。 因此，根据测试文档，债务增加了。
如何决定 ：
如果所有质量检查专家都在忙于测试优先级任务，我们将为特定功能转移矩阵的创建。 尽可能将其转移到测试该功能的第一个任务的时刻，在这种情况下，当您测试实现该功能的任务时，矩阵中会填充测试用例。
质量保证专家不仅在评估时间上自行编写测试用例，还花费时间来开发矩阵。 - 效率性
如果项目很小，并且所有需求都以结构化ToR的形式构成，并且针对每个需求立即创建测试用例，那么我们表单中的可追溯性矩阵将只会重复信息，并且会浪费资源。
因此，您需要使用定义中描述的标准矩阵来评估覆盖率。
便利设施
- 该矩阵使您可以监视需求的实施，跟踪所有需求均已开发和测试且没有遗漏。
- 该矩阵可帮助质量检查小组跟踪测试文档中是否存在欠款，以及测试用例尚未涵盖哪些特定要求。
- 分析人员和质量检查团队使用该工具来监视更改的需求。
- 在项目中，我们不仅使用了可追溯性矩阵，而且客户的产品所有者也使用了可追溯性矩阵。 因此，他们确保所有要求都正确并且正确，并使用已经实现的矩阵进行跟踪。 矩阵使我们能够使开发和测试过程变得透明。