测试覆盖矩阵是一张把需求条目、验收条件与测试用例逐项对应的表：行放需求或验收条件，列放正常路径、边界、异常、权限、数据状态等覆盖维度，格子里填用例编号与覆盖判定。设计时先拆需求到可验证的验收条件，再定覆盖维度，逐格填用例并标注状态，最后用未覆盖格子和无需求支撑的用例双向核对，形成可评审的覆盖结论。
要点总览（TL;DR）
- 矩阵的行拆到可验证的验收条件，列取正常路径、边界、异常、权限、数据状态等覆盖维度，交叉格子是覆盖判定的最小单元。
- 填写按准备输入、逐格匹配用例、标注覆盖状态、补写缺口、输出缺口清单五步推进，完成标志是每格都有判定而非每格都填了用例编号。
- 需求方确认验收条件，测试负责人定结构与评审，测试执行者填矩阵并补用例，开发提供接口与异常场景说明。
- 登录示例演示了四条验收条件在五个维度上的二十个格子如何逐格判定，并识别出一处缺口。
- 评审前做双向核对、状态一致性、缺口处置、编号可追溯和维护责任五项检查，全部满足才进入评审。
先定矩阵的行与列：需求条目和覆盖维度
矩阵的骨架由行和列共同决定。行决定“要验证什么”，列决定“从哪些角度验证”，两者交叉出的格子就是覆盖判定的最小单元。行列定得合适，后续填写才有稳定的落点；行列定得含糊，矩阵容易变成用例清单的另一种排列。
行：拆到可验证的验收条件
行不建议直接放需求标题。需求标题往往是一句业务描述，无法直接判断是否被覆盖。更合适的做法是把每条需求拆成若干条验收条件，每条验收条件具备可观察的结果，能对应一个或一组用例。
拆解时可以用“条件—动作—预期结果”的句式检查：在什么前提下，执行什么操作，应得到什么结果。一条验收条件如果包含多个互不相关的预期结果，应继续拆开。例如“用户可以登录”可以拆为“正确账号密码登录成功”“错误密码提示失败且不进入系统”“连续失败达到阈值后账号锁定”等条目。拆到这一层，行才具备判定价值。
列：覆盖维度的常见取值
列是覆盖视角的集合，常见取值如下表。列的选择应结合需求性质，不必每张矩阵都套用全部维度。
| 覆盖维度 | 关注点 | 适用条件 |
|---|---|---|
| 正常路径 | 主流程按预期完成 | 所有功能需求 |
| 边界 | 取值上下限、长度临界、数量临界 | 存在数值、长度、数量约束 |
| 异常 | 非法输入、服务失败、超时、重复提交 | 存在外部依赖或用户输入 |
| 权限 | 不同角色可见性与可操作性 | 存在角色或数据权限区分 |
| 数据状态 | 新建、已提交、已审核、已关闭等状态下的行为 | 对象有生命周期状态 |
| 兼容场景 | 浏览器、终端、分辨率、接口版本差异 | 有多端或多版本要求 |
行列粒度与项目规模的匹配
粒度没有统一标准，按项目规模和风险调整。小型项目可以把一条需求拆成三到五条验收条件，列取正常、异常、权限三类；中大型项目或涉及资金、权限、合规的功能，验收条件拆得更细，列增加边界、数据状态和兼容场景。判断粒度是否合适，可以看一个格子能否用一句话说清覆盖判定：能说清就够细，说不清就继续拆。
本节产出是一张空白骨架：左侧列出验收条件编号与描述，顶部列出选定的覆盖维度，格子留空待填。
从需求到用例的填写步骤
骨架确定后，填写是一个逐格判定的过程。每一步都有明确的输入、动作和输出，完成标志是每个格子都有判定，而不是每个格子都填了用例编号。
第一步：准备输入
输入包括三部分：需求文档与验收条件清单、已有用例库、以及相关的接口说明或数据字典。验收条件清单应与矩阵行一一对应，编号保持一致，避免填写时对不上号。已有用例库先做一次去重和命名规范检查，减少同一场景多个用例重复对应同一格子的情况。
第二步：逐格匹配用例
按行推进，对每一行的每个覆盖维度，在用例库中查找能验证该条件的用例。找到则填入用例编号；找不到则标记为缺口，并记录缺口描述。匹配时以验收条件的预期结果为判断依据，不以用例标题的字面相似度为准。
第三步：标注覆盖状态
建议统一使用少量状态值，避免出现十几种含义模糊的标记。常用规则如下：
- 已覆盖：存在用例，且用例的预期结果与验收条件一致。
- 部分覆盖：存在用例，但只验证了条件的一部分，需注明缺哪一部分。
- 缺口：无用例，需补写。
- 不适用：该维度对本条验收条件无意义，需写明理由，例如无权限区分的纯展示字段。
“不适用”必须有理由，否则容易成为跳过覆盖的出口。
第四步：补写缺口用例
对标记为缺口和部分覆盖的格子，按验收条件补写用例，补写后回填编号并更新状态。补写时优先处理高风险行，例如涉及权限、金额计算、状态流转的验收条件。
第五步：输出与完成标志
输出两份东西：填满的矩阵，以及缺口清单（含缺口描述、补写责任人和计划完成时间）。完成标志是每一行每一列都有明确判定，不存在空白格子；缺口清单中的每一项都有处置结论，要么已补用例，要么明确不补并说明理由。
角色分工与各环节交付物
矩阵设计涉及需求理解、用例编写和覆盖判定三类工作，由不同角色承担更稳妥。分工的核心是让拆需求的人对验收条件负责，让写用例的人对验证手段负责，让评审的人对覆盖结论负责。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 需求方/产品 | 确认验收条件完整、可验证，解释业务规则 | 验收条件清单（确认版） |
| 测试负责人 | 确定行列结构、覆盖状态规则，组织评审 | 矩阵骨架、状态标记规则、评审记录 |
| 测试执行者 | 逐格匹配与补写用例，维护覆盖状态 | 用例、填写的矩阵、缺口清单 |
| 开发 | 提供接口与数据状态说明，确认异常场景可实现性 | 技术说明、异常场景清单 |
评审时点建议放在矩阵填写完成、缺口清单形成之后，参与人包括需求方、测试负责人和开发代表。评审重点看三件事：验收条件是否覆盖了需求意图，缺口处置是否合理，状态标记是否一致。评审记录应写明结论和待办，作为矩阵进入执行阶段的依据。
矩阵的用例关联和覆盖状态如果分散在文档与表格中，维护成本会随需求变更上升。ONES 测试管理支持用例与需求的关联，覆盖状态可以随用例执行情况更新，适合把矩阵作为持续维护的覆盖视图，而不是一次性交付的静态表格。
一个示例：登录需求如何填成矩阵
以下示例为演示情景，用于说明填写过程，不代表任何真实项目数据。
验收条件拆解
需求“用户可以使用账号密码登录系统”，拆为四条验收条件：
- R1：正确账号与密码登录成功，进入首页。
- R2：密码错误时提示失败，停留在登录页。
- R3：连续失败达到设定次数后账号锁定。
- R4：已锁定账号在锁定期内无法登录。
覆盖维度选取
该需求涉及用户输入、账号状态和角色差异，选取正常路径、边界、异常、权限、数据状态五列，兼容场景暂不纳入。
逐格填写与缺口识别
| 验收条件 | 正常路径 | 边界 | 异常 | 权限 | 数据状态 |
|---|---|---|---|---|---|
| R1 登录成功 | TC-01 已覆盖 | TC-02 密码长度上限 已覆盖 | 不适用（无异常输入） | TC-03 普通用户 已覆盖 | TC-04 账号正常态 已覆盖 |
| R2 密码错误 | 不适用 | TC-05 失败次数临界 已覆盖 | TC-06 空密码 已覆盖 | 不适用 | TC-07 账号正常态 已覆盖 |
| R3 失败锁定 | TC-08 达到阈值锁定 已覆盖 | TC-09 阈值减一不锁定 已覆盖 | 缺口：锁定期间重复提交 | 不适用 | TC-10 锁定态 已覆盖 |
| R4 锁定期内拒绝 | TC-11 锁定期内登录失败 已覆盖 | TC-12 锁定期到期边界 已覆盖 | 不适用 | TC-13 管理员解锁 已覆盖 | TC-14 锁定态 已覆盖 |
填写中发现一处缺口：R3 在异常维度缺少“锁定期间重复提交”的用例，需补写并回填。其余格子均有判定，“不适用”处已注明理由。
覆盖判定结论
四条验收条件在五个维度上共二十个格子，已覆盖十六格，不适用三格，缺口一格。缺口补写完成并通过评审后，该需求的覆盖判定为通过；若缺口未补，则结论为有条件通过，并在缺口清单中保留跟踪项。
完成检查：矩阵是否可用的核对项
矩阵填写完成后，用一组可核验的条目判断它是否达到可评审、可交付状态。检查不通过时，回到对应环节修正，而不是在评审会上临时解释。
- 双向核对：每条验收条件至少有一个已覆盖格子；每个用例都能对应到某条验收条件，无需求支撑的用例单独列出并说明用途，例如探索性测试或回归兜底。
- 状态标记一致：同一类情况使用同一状态值；标为“不适用”的格子均有理由；标为“已覆盖”的格子，用例预期结果与验收条件一致。
- 缺口有处置结论：缺口清单中每一项都有责任人、计划时间和结论，不存在只记录不处理的条目。
- 行列编号可追溯：验收条件编号与需求编号对应，用例编号与用例库一致，评审时能按编号回查。
- 维护责任明确：指定矩阵的维护人，约定需求变更、用例新增或状态调整时的更新时机，通常与需求评审或版本计划同步。
以上条目全部满足，矩阵即可进入评审。评审通过后，矩阵作为覆盖结论的依据随版本归档；后续需求变更时，由维护人更新对应行与格子，保持矩阵与用例库同步。
常见问题
需求条目很多时，矩阵行数太多怎么控制？
按风险和变更频率分层处理。涉及资金、权限、状态流转、合规的验收条件保留在矩阵中逐格判定；纯展示、低频变更的条目可以合并为一条验收条件，或归入回归清单而不进入主矩阵。行数控制的目标是让评审者能在一张表内看完关键覆盖结论，而不是把所有需求都平铺进去。
“不适用”和“缺口”容易混用，怎么区分？
两者的区别在于该维度对本条验收条件是否有意义。“不适用”表示这个覆盖维度对该条验收条件没有验证价值，例如无权限区分的纯展示字段，必须写明理由；“缺口”表示该维度有意义但当前没有用例，需要补写并跟踪到有结论。评审时重点看“不适用”的理由是否成立，避免它变成跳过覆盖的出口。
需求在版本中途变更，矩阵怎么跟着更新？
先更新验收条件清单，再同步矩阵行；新增或修改的验收条件对应的格子重新判定，原有用例若仍适用则保留编号，不适用则标记并说明。更新时机建议与需求评审或版本计划同步，由指定的矩阵维护人执行，并在评审记录中留下变更说明，避免矩阵与用例库出现两套口径。
矩阵里的用例编号和用例库对不上怎么办？
先做一次编号对齐：验收条件编号与需求编号建立对应关系，用例编号以用例库为准，矩阵中只引用不另编。填写前对已有用例库做去重和命名规范检查，可以减少同一场景多个用例对应同一格子的情况。对齐后若仍有对不上的条目，作为检查项列入缺口清单处理。
小团队没有专职测试负责人，矩阵由谁组织？
可以由承担测试主责的人兼任组织者，职责不变：确定行列结构与状态标记规则、组织评审、维护矩阵。需求方仍需确认验收条件，开发仍需提供接口与异常场景说明。团队规模小时可以简化列的数量和评审参与人，但双向核对和缺口处置结论这两项检查建议保留。
