制定测试覆盖判定标准，关键是把“覆盖到什么程度算通过”从个人判断变成可核对的口径。做法分四步：先界定覆盖对象与统计粒度，再为每类对象定义判定字段和阈值，接着明确各角色在需求分析、测试设计、执行与评审中的交付物，最后用一份完成检查确认标准可执行、可复核。标准宜分层设置：必测项用硬门槛，风险相关项用条件门槛，并保留例外审批记录。
要点总览（TL;DR）
- 先统一覆盖对象与统计粒度：需求条目、功能点、接口、场景组合、代码分支各自定义判定单位，避免同一份报告混用两套计数。
- 判定标准落成固定字段：覆盖对象、判定依据、阈值、证据、例外说明，字段不留空，不适用时注明原因。
- 阈值分硬门槛与条件门槛：必测项未覆盖即阻断，风险相关项按等级条件纳入，每个阈值注明出处。
- 角色与交付物按需求分析、测试设计、执行、评审、标准维护五个环节落实到人，结论确认人与复核人分离。
- 发布前用完成检查清单逐项核对，必测项未定义、阈值无出处、证据无法定位版本、例外无审批通道、结论无复核人属阻断项。
先定覆盖对象与判定口径
标准空泛的常见原因是对象没定清：有人按需求条目统计覆盖，有人按用例条数统计，结论自然对不上。第一步要把“覆盖什么”和“怎么计数”写死，形成一份口径清单，后续字段和阈值都挂在这份清单上。
覆盖对象通常分几类，各自适用的场景不同：
- 需求条目：适用于验收类判定，回答“这条需求有没有被验证过”。粒度最粗，适合作为硬门槛的底座。
- 功能点：把一条需求拆成若干可独立验证的功能点，适用于需求描述较粗、需要细化验证范围的场景。
- 接口：适用于服务间调用、对外API，判定单位通常是接口及其关键参数组合、返回分支。
- 场景组合：适用于业务流程、状态流转，判定单位是经过评审确认的关键路径与异常路径集合。
- 代码分支：适用于逻辑复杂、缺陷代价高的模块，判定单位是分支或条件组合，通常借助工具采集数据。
统计粒度必须统一到同一层。建议以“需求条目”作为对外汇报口径，以“功能点或场景”作为测试设计与执行的内部口径，两者建立映射关系，避免同一份报告里混用两套计数。
判定单位要写清计数规则。以需求条目为例，“一条需求算覆盖”的条件可以定义为：该需求下所有必测功能点均有对应用例，用例均已执行，执行结果通过或缺陷已按约定处理，且证据可查。只写了用例但未执行、或执行了但无记录，都不计入覆盖。
纳入方式分两类：法规、安全、核心交易链路等必测对象列入硬门槛，未覆盖即判定不通过；其余对象按风险评级条件纳入，风险等级达到约定级别的进入本轮覆盖范围，未达到的可记录为已知缺口。下表可作为口径清单的填写模板。
| 对象类型 | 统计粒度 | 判定单位 | 纳入方式 |
|---|---|---|---|
| 需求条目 | 按需求编号 | 一条需求 | 必测（硬门槛） |
| 功能点 | 按需求拆解后的功能点 | 一个功能点 | 必测或按风险条件纳入 |
| 接口 | 按接口及关键参数组合 | 一个接口的一个分支 | 按风险条件纳入 |
| 场景组合 | 按评审确认的路径清单 | 一条关键路径 | 核心链路必测，其余条件纳入 |
| 代码分支 | 按模块统计 | 一个分支或条件组合 | 高风险模块条件纳入 |
为每类对象定义判定字段与阈值
口径定完后，把判定标准落成固定字段，让任何人拿到同一份记录都能得出相同结论。建议每条覆盖判定记录包含五个字段：覆盖对象、判定依据、阈值、证据、例外说明。字段值不允许留空，不适用时填“不适用”并注明原因。
阈值设定要区分硬门槛与条件门槛。硬门槛来自外部约束或业务底线，例如必测需求覆盖率要求100%、核心链路关键路径全部执行通过，这类阈值没有商量空间，未达到即阻断发布。条件门槛与风险挂钩，例如高风险模块分支覆盖率不低于约定比例、接口异常分支覆盖不少于评审确认的清单，阈值依据可以是历史缺陷分布、变更影响面或架构评审结论。阈值要写明出处，避免拍脑袋定数。
证据要求与判定依据一一对应。需求覆盖的证据通常包括对应用例、执行记录和结果状态；场景覆盖的证据包括路径清单及评审记录；代码分支覆盖的证据包括工具采集的覆盖率报告及采集时间、代码版本。证据要能定位到具体版本，脱离版本的覆盖率数字无法复核。
例外与豁免要有正式通道：由提出方填写例外说明，写明未覆盖对象、原因、风险评估和补偿措施（如手工验证、灰度观察、后续补测计划），经测试负责人与需求负责人共同审批后记录在案。例外记录本身也是覆盖结论的一部分，评审时与覆盖率数据一并查看。
| 字段 | 填写要求 | 示例值 |
|---|---|---|
| 覆盖对象 | 对象类型+唯一标识 | 需求 REQ-1024 下的功能点 FP-3 |
| 判定依据 | 对应用例或路径清单编号 | 用例 TC-208、TC-209 |
| 阈值 | 硬门槛或条件门槛及出处 | 硬门槛：必测功能点全部通过 |
| 证据 | 执行记录、报告及版本 | 执行记录 v1.3.0，全部通过 |
| 例外说明 | 无例外填“无”，有例外附审批编号 | 无 |
角色分工与各环节交付物
标准要有人执行、有人复核，否则字段填了也没人看。按环节划分职责，每个环节明确输入、动作和输出，交付物是判定能否复核的凭据。
| 环节 | 角色 | 输入 | 动作 | 输出交付物 |
|---|---|---|---|---|
| 需求分析 | 需求负责人、测试分析人员 | 需求文档、变更说明 | 拆解功能点与场景，标注必测项与风险等级 | 覆盖对象清单、必测项标记 |
| 测试设计 | 测试设计人员 | 覆盖对象清单 | 为每个对象编写用例或路径，建立对象与用例的对应关系 | 用例集、覆盖对应表 |
| 测试执行 | 测试执行人员 | 用例集、被测版本 | 执行用例，记录结果与证据，登记缺陷 | 执行记录、覆盖率报告 |
| 评审与质量把关 | 测试负责人、质量负责人 | 执行记录、例外申请 | 核对字段完整性，判定覆盖结论，审批例外 | 覆盖判定结论、例外审批记录 |
| 标准维护 | 测试负责人指定维护人 | 评审反馈、缺陷复盘 | 修订对象分类、阈值与字段，发布新版本 | 标准版本记录、变更说明 |
覆盖判定结论由测试负责人确认，质量负责人复核，两者签字或系统留痕后才可作为发布依据。标准本身要有版本号和维护人，阈值调整需走变更记录，避免不同项目各用一套口径。
这些环节涉及需求、用例、执行记录与评审状态的连续流转。在ONES中，需求工作项可关联测试用例与执行结果，覆盖对象清单和例外审批可以作为工作项字段与评审记录留存，使判定结论能追溯到具体版本和证据，减少在多个表格之间对账的成本。
示例：一条需求的覆盖判定如何走完
以“订单退款申请”需求为例，演示标准从设计到判定的完整过程。
对象拆解。需求分析阶段把该需求拆为三个功能点：退款申请提交、退款金额校验、退款状态回写；识别两条关键路径：正常退款、部分退款；标注为必测项，风险等级高。
字段填写与证据收集。测试设计为三个功能点各编写用例，并补充异常分支用例；执行阶段在版本 v2.1.0 上执行全部用例，记录结果，其中金额校验的一个边界用例发现缺陷，修复后回归通过。覆盖率报告随版本归档。
例外处理。部分退款路径中一个极端组合（多笔优惠叠加）本轮未覆盖，提出方填写例外说明，评估影响为低频场景，补偿措施为上线后灰度观察并列入下轮补测，经测试负责人与需求负责人审批，记录例外编号。
结论形成。评审时核对：必测功能点全部有用例且执行通过，关键路径一条通过、一条带审批例外，字段无空缺，证据可定位到版本。判定该需求覆盖结论为“通过（含一条已审批例外）”，结论与例外记录一并归档。
完成检查：标准是否可执行
标准制定完成后，用下面的清单逐项核对。全部检查项通过才可发布执行；任一阻断项未通过，标准暂不生效。
- 覆盖对象分类齐全，每类对象都有明确的统计粒度和判定单位。
- 必测项与条件纳入项的划分有书面依据，风险等级定义清楚。
- 判定字段可填写，字段含义无歧义，不适用情形有填写规则。
- 每个阈值都注明出处，硬门槛与条件门槛区分明确。
- 证据类型与判定依据一一对应，且能定位到版本。
- 例外申请、审批、记录流程完整，审批人明确。
- 各环节角色、输入、动作、交付物均已落实到人。
- 覆盖结论的确认人与复核人分离，留痕方式确定。
- 标准有版本号、维护人和变更记录机制。
阻断项包括：必测项未定义、阈值无出处、证据无法定位版本、例外无审批通道、结论无复核人。任一项缺失，标准在执行中都会退回主观判断，需补齐后再发布。
常见问题
必测项和按风险条件纳入的项，边界怎么划才不会越定越宽？
建议用两条线来划：一条是外部约束线，法规、安全合规、核心交易链路这类对象直接列入必测，不参与风险评级讨论；另一条是内部风险线，其余对象按变更影响面、历史缺陷分布、架构评审结论评级，达到约定级别的进入本轮覆盖范围。
边界变宽的常见原因是评级标准模糊，比如“重要模块”没有定义。把风险等级写成可判断的条件（涉及资金流转、涉及权限变更、近三个版本有高频缺陷等），并定期用缺陷复盘结果校准，边界就能稳定下来。
覆盖率数字达标了，但评审仍判定不通过，这种情况合理吗？
合理。覆盖率是判定依据之一，不是判定结论本身。如果必测功能点存在无对应用例、执行记录缺失、证据无法定位到版本，或者例外没有审批记录，即使覆盖率数字达标，也应判定不通过。
反过来也要防止另一种偏差：把覆盖率当作唯一门槛，导致团队为凑数字补写用例而不执行。判定字段里把“用例已执行且结果可查”作为计数条件，可以约束这类行为。
例外审批由谁批、批到什么程度算有效？
例外说明应写明未覆盖对象、原因、风险评估和补偿措施，由测试负责人与需求负责人共同审批，记录例外编号并归档。只有口头同意或聊天记录，不算有效例外。
审批时要看补偿措施是否可执行：手工验证要有验证记录，灰度观察要有观察指标和观察期，后续补测要有排期。补偿措施落不了地的例外，建议不批，改为调整本轮范围或延期发布。
标准发布后，阈值多久调整一次比较合适？
没有统一周期，建议与两个触发条件挂钩：一是缺陷复盘发现某类问题反复出现在未覆盖区域，说明阈值或对象分类需要修订；二是业务或架构发生较大变更，原有风险等级不再适用。
调整要走变更记录，写明调整原因、影响范围和生效版本，由标准维护人发布新版本。避免项目组各自改阈值，否则跨项目汇总时口径又会分裂。
小团队人手有限，这套字段和流程能简化吗？
可以简化执行形式，不建议简化判定逻辑。字段可以合并到一张表里，评审可以合并到一次发布前会议，但覆盖对象、判定依据、证据、例外记录这几项要保留，否则结论无法复核。
人手紧张时优先保证必测项的硬门槛执行到位，条件门槛可以先覆盖高风险模块，其余对象记录为已知缺口并纳入后续计划。简化的是范围，不是记录本身。
