可追踪性矩阵（traceability matrix）也称为追溯矩阵，简称TM，是软件开发中的文件，一般会用表格来表示，利用多对多关系的比较来确认二个形态基准文件中的关系完整性。可追踪性矩阵常用来将高阶需求（多半也包括市场需求）以及产品的细部需求和高阶设计、细节设计、测试计划及测试用例进行对应。
可追踪性矩阵可以用来确认目前专案的需求是否都有符合，也有助于建立需求建议书[2]、软件需求说明[3]、许多的交付文件，以及专案计划任务。
常见的用法是一份文件中的项目以识别文字表示，将识别文字放在表格的左边。另一份文件中的项目也以识别文字表示，放在表格的上方。若左边某一项目及上方某一项目有关，则在对应二项目的方格注记记号。最后会分别将每一栏及每一列的注记数量加总，表示此项目在另一份文件中有关的项目数量。若数值为零，表示在另一份文件中，没有和此项目对应的项目。若数字很大，表示其关系太过复杂，需要再加以简化。
为了简化可追踪性矩阵的建立，一般会建议加上和程式码文件的关联性，以作到前向可追踪性及后向可追踪性[1]。当在形态基准文件中有任一项目有变动，很容易可以看出哪些项目会受到影响。
需求可追溯性矩阵有时分为三个子类型：
已剪辑自: https://www.kancloud.cn/apachecn/guru99-zh/1953521
可追溯性矩阵是一个文档，它与需要多对多关系以检查关系的完整性的任何两个基线文档相关联。
它用于跟踪需求并检查是否满足当前项目需求。
**需求可追溯性矩阵（RTM）**是一个文档，用于映射和跟踪带有测试用例的用户需求。 它在软件部署生命周期结束时提供的单个文档中捕获了客户提出的所有需求和需求可追溯性。 需求可追溯性矩阵的主要目的是验证是否通过测试用例检查了所有需求，以便在软件测试期间不取消任何功能。
在本教程中，您将了解有关-
每个测试人员的主要议程应该是了解客户的要求，并确保输出产品没有缺陷。 为了实现此目标，每个质量检查人员都应彻底了解需求并创建正面和负面的测试用例。
这意味着必须将客户端提供的软件需求进一步划分为不同的场景并进一步测试案例。 每种情况都必须单独执行。
这里出现一个问题，即如何确保考虑所有可能的场景/情况对需求进行测试？ 如何确保在测试周期内不遗漏任何要求？
一种简单的方法是使用相应的测试方案和测试案例来跟踪需求。 这仅称为“需求可追溯性矩阵”。
可追溯性矩阵通常是一个工作表，其中包含需求及其所有可能的测试方案和案例以及它们的当前状态，即它们是否已通过或失败。 这将有助于测试团队了解针对特定产品完成的测试活动的级别。
以上是样本需求可追溯性矩阵。
但是在一个典型的软件测试项目中，可追溯性矩阵将具有比这些参数更多的特性。
如上所述，需求可追溯性矩阵可以：
这种矩阵可以为所有测试活动提供一站式服务。
除了单独维护一个 excel。 测试团队还可以选择跟踪需求的可用测试管理工具。
在软件工程中，可追溯性矩阵可分为以下三个主要部分：
让我们通过 Guru99 银行项目了解“需求可追溯性矩阵”的概念。
根据业务需求文档（BRD）**和**技术需求文档（TRD），测试人员开始编写测试用例。
假设，下表是我们针对 Guru99 银行业项目的业务需求文档或 BRD 。
在这种情况下，客户应该能够使用正确的密码和用户#id 登录到 Guru99 银行网站，而经理应该能够通过客户登录页面登录到该网站。
下表是我们的技术要求文档（TRD）。
注意：**质量检查小组没有记录 BRD 和 TRD。 另外，一些公司使用**功能需求文档（FRD），与技术需求文档相似，但是创建可追溯性矩阵的过程保持不变。
让我们继续前进，在测试中创建 RTM
**步骤 1：**我们的样本测试用例是
“验证登录名，输入正确的 ID 和密码后，它应该成功登录”
步骤 2 ：确定该测试用例正在验证的技术要求。 对于我们的测试用例，技术要求是正在验证的 T94。
**步骤 3：**在测试用例中注意此技术要求（T94）。
**步骤 4：**标识为此 TR（技术要求-T94）定义的业务需求
**步骤 5：**注意测试用例中的 BR（业务需求）
**步骤 6：**针对所有测试用例执行上述操作。 稍后从测试套件中提取前 3 列。 测试中的 RTM 准备就绪！
点击下面下载 RTM 模板 Excel 文件
下载 RTM 模板 Excel（.xlsx）
