测试覆盖矩阵把需求条目、验收条件和测试用例放进同一张表，用行表示需求或验收点，用列表示测试用例或测试类型，在交叉格标注覆盖状态与证据。本文提供一份可直接复制到文档或表格工具中的空白矩阵，并说明字段口径、必填与选填规则、完整填写示例以及后续维护方法。
要点总览（TL;DR）
- 空白矩阵按“需求行 × 用例列”组织，交叉格填覆盖状态，行末固定列放证据链接和备注，可直接复制到文档或表格工具使用。
- 覆盖状态建议统一为已覆盖、部分覆盖、未覆盖、不适用四档，判定依据是验收条件是否有对应用例且执行证据可查。
- 需求编号、需求描述、验收条件、用例编号、用例名称、覆盖状态为必填；测试类型和备注为选填；证据链接在状态为已覆盖或部分覆盖时必填。
- 填写时按验收条件拆行，一条需求可占多行，示例中三条验收条件分别对应用例，部分覆盖需在备注写明缺口。
- 矩阵维护绑定需求变更、用例增删和覆盖复核三个触发点，发布前归档只读版本，复核人与填写人分离。
可复制空白测试覆盖矩阵表
下面这张表按“需求行 × 用例列”组织。实际使用时，把用例列向右扩展，每个用例占一列；需求行向下增加，每条需求或验收点占一行。交叉格填写覆盖状态，证据和备注放在行末的固定列中，方便逐行核对。
| 需求编号 | 需求描述 | 验收条件 | 用例编号 | 用例名称 | 测试类型 | 覆盖状态 | 证据链接 | 备注 |
|---|---|---|---|---|---|---|---|---|
如果希望矩阵更接近“交叉格”形态，可以把用例编号作为列标题，每个需求行只保留需求侧字段和状态格，结构如下：
| 需求编号 | 需求描述 | 验收条件 | TC-001 | TC-002 | TC-003 | 覆盖状态 | 证据链接 | 备注 |
|---|---|---|---|---|---|---|---|---|
两种结构表达的信息相同。第一种适合用例数量多、需要逐条记录用例属性的场景；第二种适合用例数量有限、希望一眼看出需求与用例对应关系的场景。选定一种后保持全表一致，避免同一份矩阵混用两种布局。
矩阵字段说明：每一列记录什么
字段说明与上面的模板一一对应。填写前先统一口径，尤其是覆盖状态的判定标准，否则不同人填出的矩阵无法横向比较。
需求侧字段
- 需求编号：需求在需求库或需求文档中的唯一标识，如 REQ-012。填写时直接引用原编号，便于回溯到需求原文。
- 需求描述：用一句话概括该需求要实现的业务行为，写清对象和动作，例如“订单提交后 30 分钟内可取消”。描述保持简短，详细内容留在需求文档中。
- 验收条件：该需求被判定为完成的可见条件，通常一条需求对应一到三条验收条件。验收条件是覆盖判定的最小单位，矩阵按验收条件逐条核对，比只按需求整体打勾更可靠。
用例侧字段
- 用例编号：测试用例库中的唯一标识，如 TC-1042。与需求编号一样，引用原编号，不另起一套编号体系。
- 用例名称：描述该用例验证什么行为，例如“订单提交后 29 分钟取消成功”。名称应能独立读懂，避免“测试用例1”这类无信息量的命名。
- 测试类型：标注用例所属的测试类别，常见取值包括功能、接口、性能、兼容性、安全、异常场景。测试类型用于检查同一需求是否只做了单一类型的验证。
覆盖与证据字段
- 覆盖状态：记录该需求或验收点当前的验证结论，取值口径见下文。
- 证据链接：指向测试执行记录、缺陷单、测试报告或截图存档的位置。证据的作用是让评审者不依赖填写人的口头说明就能核实结论。
- 备注：记录例外情况，例如某验收条件本期不适用、某用例因环境限制暂缓执行、覆盖结论存在争议等。备注只写影响判断的信息，不写过程流水。
覆盖状态的取值口径
| 取值 | 判定标准 | 典型情形 |
|---|---|---|
| 已覆盖 | 该验收条件有对应用例，且用例已执行并通过，证据可查 | 功能用例通过，执行记录已归档 |
| 部分覆盖 | 有对应用例，但只验证了验收条件的一部分，或执行结果存在未关闭的缺陷 | 主流程通过，异常分支尚未验证 |
| 未覆盖 | 没有对应用例，或用例尚未执行 | 新需求刚进入测试，用例待设计 |
| 不适用 | 该验收条件在本期范围内不需要验证，且备注中写明了原因 | 依赖的功能本期不上线 |
四档取值中，“部分覆盖”最容易被滥用。填写时应说明缺哪一部分，例如“仅验证正常取消，未验证超时后不可取消”，让后续补测有明确目标。
必填与选填：哪些字段不能空
必填字段决定矩阵能否支撑覆盖判断和评审追溯，选填字段用于补充上下文。必填缺失时，该行不能进入覆盖统计，也不能作为测试完成的依据。
| 字段 | 必填/选填 | 理由与适用场景 |
|---|---|---|
| 需求编号 | 必填 | 矩阵与需求库的连接点，缺失则无法回溯和统计 |
| 需求描述 | 必填 | 让评审者不打开需求文档也能理解该行验证什么 |
| 验收条件 | 必填 | 覆盖判定的最小单位，缺失会导致只能按需求整体打勾 |
| 用例编号 | 必填 | 定位具体用例，支撑执行与缺陷关联 |
| 用例名称 | 必填 | 便于快速阅读矩阵，减少来回跳转 |
| 测试类型 | 选填 | 需要检查测试类型分布时填写；单一功能验证为主的矩阵可省略 |
| 覆盖状态 | 必填 | 矩阵的核心结论字段，空白等同于未判定 |
| 证据链接 | 必填（状态为已覆盖或部分覆盖时） | 结论需要可核实；状态为未覆盖时可不填 |
| 备注 | 选填 | 状态为不适用、存在争议或暂缓执行时填写 |
必填字段缺失时按以下规则处理：需求编号或验收条件缺失的行，退回需求侧补齐后再进入矩阵；用例编号缺失的格子视为未覆盖，不能凭记忆认定已测；覆盖状态为空的行不计入覆盖率统计，并在评审时单独列出。证据链接缺失但状态填了已覆盖的，评审时按部分覆盖处理，直到补上执行记录。
填写示例：一条需求如何填满一行
以下示例为演示情景，需求与用例均为虚构，用于说明填写方式。示例需求为“订单提交后 30 分钟内可取消”，拆成三条验收条件，分别对应用例。
| 需求编号 | 需求描述 | 验收条件 | 用例编号 | 用例名称 | 测试类型 | 覆盖状态 | 证据链接 | 备注 |
|---|---|---|---|---|---|---|---|---|
| REQ-012 | 订单提交后 30 分钟内可取消 | 提交后 29 分钟内取消成功，订单状态变为已取消 | TC-1042 | 订单提交后 29 分钟取消成功 | 功能 | 已覆盖 | 测试报告 v1.3 第 4 节 | |
| REQ-012 | 订单提交后 30 分钟内可取消 | 提交满 30 分钟后取消入口不可用 | TC-1043 | 订单提交满 30 分钟后取消入口置灰 | 功能 | 已覆盖 | 测试报告 v1.3 第 4 节 | |
| REQ-012 | 订单提交后 30 分钟内可取消 | 取消操作在弱网环境下不产生重复退款 | TC-1044 | 弱网下重复点击取消仅生成一笔退款 | 异常场景 | 部分覆盖 | 缺陷单 BUG-208 执行记录 | 弱网模拟仅覆盖 3G 限速，未覆盖断网重连 |
逐项对照字段说明：需求编号与需求描述在三行中重复填写，保证每行可独立阅读；验收条件按可判定的粒度拆分，没有把三条合并成一句；用例编号引用用例库原编号，用例名称写清了时间点和预期结果；测试类型区分了功能与异常场景；覆盖状态按实际执行结论填写，第三行因验证范围不完整填为部分覆盖，并在备注中写明缺口；证据链接指向可查的执行记录，没有只写“已测”。
这一行需求在矩阵中占三行，而不是一行打一个总勾。这样做的价值在于：当评审问“弱网场景测了吗”，矩阵直接给出部分覆盖和具体缺口，不需要重新翻用例库。
矩阵的调整与维护方法
矩阵建立后如果只在版本发布前更新一次，很快会与需求和用例脱节。维护动作应绑定到需求变更、用例增删和覆盖复核三个触发点，并保留版本记录。
需求变更时的行更新
- 需求新增验收条件时，在对应需求下增加行，覆盖状态先填未覆盖，进入待补用例清单。
- 验收条件被修改时，保留原行并在备注中注明变更，新增行记录新条件，避免历史覆盖结论被覆盖掉。
- 需求被取消或延期时，把相关行状态改为不适用，备注写明原因和关联的版本决策。
用例增删时的列更新
- 新增用例后，在用例列区补充列或在行内补充用例编号，并回填其覆盖的验收条件。
- 用例被废弃时，不直接删除列，先把对应格状态改为未覆盖并备注“用例已废弃”，待替代用例补齐后再清理。
- 用例拆分或合并时，同步更新用例编号引用，保持矩阵与用例库编号一致。
覆盖状态的复核时点
建议在三个时点复核：测试执行完成、缺陷修复验证后、版本发布前。执行完成时核对状态与证据是否匹配；缺陷修复后检查部分覆盖的行是否可转为已覆盖；发布前做一次全表扫描，确认没有空白状态和缺失证据的行。复核人应与填写人分离，至少由另一名测试或开发人员抽查。
版本与归档方式
矩阵按版本或迭代保存快照，文件名或表头注明版本号与日期，例如“覆盖矩阵_v1.3_2025-06”。每次发布前归档一份只读版本，作为该版本测试覆盖的留存记录。日常维护在最新版本上进行，历史版本不再修改。归档时同时保留证据链接的有效性说明，避免链接失效后无法核实。
当需求、用例和覆盖状态分散在不同工具中时，矩阵的维护成本主要来自来回核对。ONES TestCase 支持测试用例与需求、任务关联，测试计划与迭代关联，用例属性支持筛选，便于按需求维度找出对应用例并核对覆盖情况；用例支持从 Excel 批量导入和导出，矩阵可以在表格工具中维护后与用例库对齐。是否提供现成的覆盖矩阵视图或按需求统计覆盖情况，需在选型时结合实际配置核验。
常见问题
一条需求对应多条验收条件时，矩阵里应该占几行？
按验收条件拆行，一条验收条件占一行，同一需求编号和需求描述在多行中重复填写。这样每个交叉格只对应一个可判定的验证点，评审时能直接看出哪条验收条件已覆盖、哪条还有缺口。如果只按需求整体打一个勾，部分覆盖的情况会被掩盖，后续补测也缺少明确目标。
覆盖状态填了“已覆盖”但证据链接暂时没有，评审时怎么处理？
按部分覆盖处理，直到补上执行记录。证据链接的作用是让评审者不依赖填写人口头说明就能核实结论，缺少证据的“已覆盖”无法支撑覆盖判断。补上证据后再改回已覆盖，并在备注中记录这次调整的时间。
用例被废弃或替换时，矩阵里的列可以直接删掉吗？
建议先保留，把对应格状态改为未覆盖并备注“用例已废弃”，等替代用例补齐后再清理。直接删除列会让历史覆盖结论失去对应关系，评审时无法判断该验收条件曾经测过什么。替代用例就位后，再同步更新用例编号引用，保持矩阵与用例库一致。
矩阵需要多久复核一次？
按触发点复核比按固定周期更可靠，建议在测试执行完成、缺陷修复验证后、版本发布前三个时点各做一次。执行完成时核对状态与证据是否匹配；缺陷修复后检查部分覆盖的行能否转为已覆盖；发布前全表扫描，确认没有空白状态和缺失证据的行。复核人应与填写人分离，至少由另一名测试或开发人员抽查。
需求、用例和覆盖状态分散在不同工具里，矩阵怎么减少来回核对？
优先让用例与需求在同一套工作项体系中关联，矩阵只承担汇总和评审视图的角色。ONES TestCase 支持测试用例与需求、任务关联，测试计划与迭代关联，用例属性支持筛选，便于按需求维度找出对应用例；用例支持从 Excel 批量导入和导出，可以在表格工具中维护矩阵后与用例库对齐。是否提供现成的覆盖矩阵视图或按需求统计覆盖情况，需在选型时结合实际配置核验。
