手工测试中的跟踪能力矩阵是什么？如何计算或估计？

Question

我最近改变了公司的手动测试角色，我的经理让我为需求或测试用例建立跟踪能力矩阵(我不确定)。然而，这是我第一次听到“追踪能力矩阵”这个词。然而，在一些基于提供的信息的博客上，我理解它类似于编写业务场景、测试场景和测试用例。我的理解正确吗？

Answer 1

什么是可追溯矩阵？

它用于跟踪需求和检查当前的项目要求是否满足。也就是说，可追溯性矩阵是一个文档，它将需要多到多个关系的任何两个基线文档相互关联，以检查关系的完整性。

需求跟踪矩阵

需求跟踪能力矩阵或RTM捕获客户端或开发团队提出的所有需求及其在生命周期结束时交付的单个文档中的跟踪能力。

简单地说，它是一个用测试用例映射和跟踪用户需求的文档。需求跟踪矩阵的主要目的是确保涵盖所有测试用例，以便在测试时不遗漏任何功能。

RTM参数包括：

Requirement ID
Risks
Requirement Type and Description
Trace to design specification
Unit test cases
Integration test cases
System test cases
User acceptance test cases
Trace to test script

据我所知，可追溯矩阵有三种类型

Forward traceability
Backward or reverse traceability
Bi-directional traceability ( Forward+Backward)

前向可追溯性：这个矩阵用于检查项目是否朝着预期的方向和正确的产品进展。它确保每个需求都应用于产品，并对每个需求进行彻底的测试。它将需求映射到测试用例。

反向或反向可追溯性：用于确保当前产品是否保持在正确的轨道上。这种可追溯性背后的目的是验证我们没有通过添加代码、设计元素、测试或其他需求中未指定的工作来扩展项目的范围。它将测试用例映射到需求。

双向可跟踪性( Forward+Backward):这个可跟踪度量确保所有需求都被测试用例覆盖。它分析受工作产品缺陷影响的需求更改的影响，反之亦然。

需求可追溯矩阵的优势

It confirms 100% test coverage
It highlights any requirements missing or document inconsistencies
It shows the overall defects or execution status with a focus on business requirements
It helps in analyzing or estimating the impact on the QA team's work with respect to revisiting or re-working on the test cases

Answer 2

对于测试过程来说，traceability matrix是一个常见且非常有用的工具。由于矩阵结果，有可能获得一些与测试过程相关的非常重要的覆盖率度量。您必须将两个度量定义为表输入(例如x值和y值)，并在满足两个输入之间关系的单元格中插入一个交叉项。具体而言，一些常见的可追溯矩阵是：

1. test cases <--> requirements：这种矩阵帮助测试人员估计给定结果的已实现测试用例的覆盖率。此表中的空单元格意味着必须生成更多的测试用例来满足所有给定的需求，
2. requirements <--> source code：这个矩阵有助于理解某些生成的代码是否包含在任何需求中。空单元格可能是由需求编号不足或代码多余造成的，
3. test cases <--> source code：这个矩阵对于理解测试代码的百分比很有用。多个原因可能导致空单元格。

Answer 3

“需求跟踪矩阵(RTM)是一个简单而有效的工具，允许为您的项目建立和维护双向可跟踪性。

顾名思义，RTM只不过是一个显示不同开发工件之间关系的表。由于它的简单性，它可以用最基本的工具创建--例如用excel。有时甚至可以在白板上画出来，让团队中的每个人都能看到。根据您创建RTM的目的，它可以可视化‘链接’工件之间的直接链接，显示整个“跟踪”上的累积视图。“

[https://blogs.itemis.com/en/how-to-create-a-requirements-traceability-matrix]