测试覆盖判定标准示例要解决的问题是：测试执行结束后，团队如何用一张表说明“覆盖到什么程度算通过”。本文给出一份可直接参照的已填写判定表，以订单模块为演示情景，覆盖需求条目、功能点、异常场景三类对象，并逐列解释取值理由与结论推导。示例数据仅用于说明填写方法，阈值需按项目风险重新设定。
要点总览（TL;DR）
- 测试覆盖判定标准示例的核心是一张可逐项填写的判定表：覆盖对象、覆盖类型、计划用例数、已执行数、通过数、证据、判定结论七列。
- 判定表同时容纳需求条目、功能点、异常场景三类对象，结论分为通过、有条件通过、不通过三种，避免把覆盖判定简化成二选一。
- 执行率回答“计划用例是否都跑了”，通过率回答“跑过的用例有多少通过”；先看执行率再看通过率，防止把未执行误判为无问题。
- 换模块时列结构保持不变，覆盖对象、计划用例数和阈值按模块风险重新设定，结论需经评审确认而非单人填写。
- 示例数据为演示情景，不涉及插桩、代码级覆盖率统计和需求全链路追溯，安全与性能专项需另设判定口径。
示例目标：这份判定表要回答什么
这份判定表回答一个具体问题：在测试执行结束到发布评审之间，订单模块的测试覆盖是否达到可以放行的程度。它把“覆盖够不够”从口头判断变成可逐项核对的记录，让评审者看到每个覆盖对象的计划量、执行量、通过量和证据，再据此给出结论。
示例的覆盖对象限定在三个层级。需求条目层面对应订单模块的业务规则，例如下单、取消、退款；功能点层面对应界面或接口上的可操作单元，例如提交订单按钮、订单状态查询接口；场景层面对应跨步骤的业务流程与异常路径，例如库存不足时下单、支付超时后取消。三个层级各有用途：需求条目回答“业务规则是否都被验证”，功能点回答“每个可操作单元是否都被执行”，场景回答“关键路径和异常分支是否被走到”。
判定表的使用时点在执行结束与发布评审之间。测试人员完成执行并补齐证据后填写，测试负责人核对口径，评审会上作为放行讨论的输入。它不替代缺陷管理，也不替代代码级覆盖率报告，只承担“覆盖判定”这一件事。
以下表格与说明均为演示情景，不对应任何真实项目、客户或实测数据。
完整示例：订单模块测试覆盖判定表
下表是一份已填写的判定表。为便于对照，覆盖对象按需求条目、功能点、异常场景三类排列，结论覆盖通过、有条件通过、不通过三种情况。
| 覆盖对象 | 覆盖类型 | 计划用例数 | 已执行数 | 通过数 | 证据 | 判定结论 |
|---|---|---|---|---|---|---|
| 下单业务规则（含优惠券叠加） | 需求条目 | 12 | 12 | 12 | 用例执行记录、关键页面截图 | 通过 |
| 订单取消规则（未支付、已支付两种状态） | 需求条目 | 8 | 8 | 7 | 用例执行记录、缺陷单链接 | 有条件通过 |
| 提交订单按钮 | 功能点 | 5 | 5 | 5 | 用例执行记录、接口返回日志 | 通过 |
| 订单状态查询接口 | 功能点 | 6 | 4 | 4 | 用例执行记录、接口日志 | 不通过 |
| 库存不足时下单 | 异常场景 | 4 | 4 | 4 | 用例执行记录、错误提示截图 | 通过 |
| 支付超时后自动取消 | 异常场景 | 3 | 3 | 2 | 用例执行记录、定时任务日志、评审结论 | 有条件通过 |
这张表刻意包含了三种结论，便于说明判定不是二选一。订单取消规则执行完整但有一条用例未通过，属于“覆盖到位、质量待确认”；订单状态查询接口计划六条只执行四条，属于“覆盖未完成”；支付超时场景执行完整、两条通过、一条因环境限制暂未验证，经评审接受为有条件通过。
逐项解释：每列取值与结论怎么来的
判定表的价值在于每列都有明确口径，换人填写也能得到相近结果。下面按列说明。
覆盖类型如何选择
覆盖类型决定判定口径。需求条目看“规则是否被完整验证”，计划用例数通常由需求拆解得出，判定关注执行率与通过率是否同时达标。功能点看“可操作单元是否被执行”，计划用例数较少，判定更关注是否全部执行。异常场景看“关键异常路径是否被走到”，判定更关注场景是否被覆盖，单条用例的通过情况需要结合缺陷严重程度判断。同一个模块里三类对象并存，是为了避免只统计用例总数而掩盖某类对象未被覆盖的情况。
执行率与通过率的口径区别
执行率等于已执行数除以计划用例数，回答“计划内的用例是否都跑了”。通过率等于通过数除以已执行数，回答“跑过的用例里有多少通过”。两者不能混用：订单状态查询接口执行率约67%，通过率100%，说明已执行的都通过，但覆盖范围不足，结论仍是不通过；订单取消规则执行率100%，通过率约88%，说明覆盖完整但存在未通过项，结论是有条件通过。填写时先看执行率是否达标，再看通过率，顺序颠倒容易把“没跑”误判成“没问题”。
证据列记录什么
证据列要让评审者不打开其他系统也能判断结论可信。常用形式包括用例执行记录（含执行人、时间、结果）、关键页面截图、接口请求与返回日志、定时任务或后台作业日志，以及评审会上形成的结论记录。证据与结论要对应：判定“通过”的对象，证据应能支撑全部用例已执行且通过；判定“有条件通过”的对象，证据中应包含未通过项或未验证项的处理说明；判定“不通过”的对象，证据应能说明缺口在哪里。
有条件通过与不通过怎么区分
区分依据是缺口性质。覆盖已完整、缺口是单条用例未通过或个别场景受环境限制未验证，且缺口已被记录、有明确处理计划、经评审确认不影响本次放行范围，可判为有条件通过。覆盖本身未完成，即计划用例未执行到约定比例，或未通过项涉及核心业务规则且无替代验证手段，应判为不通过。示例中订单取消规则有一条用例未通过，缺陷已登记并约定修复后回归，因此判为有条件通过；订单状态查询接口有四条用例未执行，覆盖缺口无法用现有证据弥补，因此判为不通过。
结论推导可以按固定顺序进行：先核对计划用例数与覆盖对象是否匹配，再算执行率，再算通过率，再检查证据是否齐全，最后对照阈值给出结论。任何一步不满足，都应在结论列写明原因，而不是只写结论词。
可迁移规律：换一个模块怎么套用
换模块时，判定表的列结构保持不变，需要调整的是覆盖对象、计划用例数和阈值。列结构稳定，评审者才能横向比较不同模块的判定结果；对象和阈值随模块变化，判定才贴合实际风险。
对象与阈值按模块调整
支付模块可以把覆盖对象设为支付渠道、退款规则、对账场景；用户中心可以设为注册登录、权限变更、账号注销。计划用例数由该模块的需求拆解和用例设计结果决定，不沿用订单模块的数字。阈值同样需要重设：涉及资金、权限、隐私的模块，执行率与通过率的放行门槛应更严格；内部工具类模块可以适当放宽，但放宽的理由要写进判定表说明。
阈值结合风险等级设定
统一数值看似公平，实际会把高风险模块和低风险模块按同一标准处理。更可行的做法是先给覆盖对象标风险等级，再为不同等级设定不同阈值。例如核心交易规则要求执行率100%、通过率100%且证据齐全；一般功能点要求执行率100%、通过率不低于约定值；异常场景要求关键路径全部执行。风险等级由业务影响、发生概率和可恢复性共同判断，并在评审前确认，避免执行结束后再调阈值。
覆盖对象粒度与用例粒度对应
覆盖对象拆得越细，用例与对象的对应关系越清楚，判定也越容易定位缺口。一个需求条目通常对应一组用例，一个功能点对应少量用例，一个异常场景对应若干步骤用例。填写时保持“一个对象一行”，不要把多个对象合并成一行再用总数判定，否则无法看出是哪一部分没覆盖。若一个对象用例过多，可拆成多行，但每行仍需独立给出结论。
结论需要评审确认
判定表由测试人员填写，结论由评审确认。单人填写容易受执行者视角影响，尤其在有条件通过的判断上。评审时应核对阈值是否事先约定、证据是否支撑结论、有条件通过项的后续处理是否明确。评审结论可以修改填写结果，修改理由应记录在证据列或备注中，形成可追溯的判定记录。
当判定表需要多人协作填写、结论需要留痕并与发布评审衔接时，可以把覆盖对象作为测试用例的关联维度，把执行记录和证据挂在用例上，把判定结论作为评审材料输出。ONES 测试管理支持用例与需求的关联、测试执行记录和测试报告，判定表中的执行数、通过数与证据可以来自这些记录，减少手工汇总；评审结论也能随测试计划留存，便于后续回归时对照。是否采用工具承载取决于团队已有的用例管理方式，判定表本身的结构不依赖特定工具。
适用边界：哪些情况不适用这份示例
这份示例适用于以需求条目、功能点、业务流程和异常场景为对象的测试覆盖判定，适合在版本发布前做覆盖与通过情况的汇总核对。以下情况需要另设方法。
示例不涉及插桩、覆盖率工具配置和代码级覆盖统计。语句覆盖、分支覆盖、条件覆盖等指标由代码分析工具产出，判定口径与本文的用例执行口径不同，不能直接套用本表的列和阈值。
需求到研发全链路的追溯管理属于需求追溯与覆盖管理主题，本文只处理“给定覆盖对象后如何判定”，不展开需求变更、追溯矩阵和跨阶段关联的完整方法。
示例中的数字、阈值和结论均为演示情景，不对应真实项目数据。直接照搬订单模块的用例数和通过率门槛，可能与本项目的风险状况不符，使用前应重新设定阈值并经过评审确认。
安全、性能等专项测试需要单独的判定口径。安全测试关注漏洞等级与修复验证，性能测试关注响应时间、吞吐量和资源占用是否达到约定指标，这些结论不能只用用例执行数和通过数表达，应另建判定表或在本文表格之外补充专项列。
常见问题
判定表里的阈值应该由谁定、什么时候定？
阈值建议在测试执行开始前由测试负责人与业务、研发共同确认，并按覆盖对象的风险等级分别设定。执行结束后再调阈值，容易让判定结果迁就已有数据。评审时先核对阈值是否为事先约定，再核对证据是否支撑结论。
有条件通过的项，后续应该怎么跟踪？
有条件通过意味着覆盖已完整、缺口已被记录且有明确处理计划。填写时应在证据列写明未通过项或未验证项、缺陷单或处理计划、评审确认结论。发布后按约定时间回归，回归结果补记到同一行或关联记录中，形成闭环。
一个覆盖对象对应多少条用例比较合适？
没有统一数量。需求条目通常对应一组用例，功能点对应少量用例，异常场景对应若干步骤用例。关键是保持“一个对象一行”，用例与对象的对应关系清楚；若一个对象用例过多，可拆成多行，但每行独立给出结论，避免合并后用总数掩盖局部缺口。
判定表和代码覆盖率报告是什么关系？
两者口径不同。判定表统计的是计划用例的执行与通过情况，回答业务规则和场景是否被验证；代码覆盖率报告由插桩或分析工具产出，回答代码被执行的比例。本文示例只处理前者，代码级覆盖统计不在示例范围内，两类结果可以并列参考，不能互相替代。
团队规模较小、没有独立评审环节，还能用这份判定表吗？
可以使用，但需要保留结论确认动作。小团队可由测试与研发负责人共同核对判定表，重点检查阈值是否事先约定、证据是否齐全、有条件通过项是否有处理计划，并把确认结果记录在证据列或备注中。判定表的结构不依赖评审会形式，依赖的是结论有人核对、有记录可查。
