测试报告通过的标准怎么定：缺陷收敛、覆盖率与遗留风险评估

测试报告通过的标准，常见两种写法：一是要求 Bug 清零，二是设一个用例通过率。前者容易在收尾阶段反复讨论，后者容易掩盖关键需求没测到的事实。更稳妥的做法，是把通过标准拆成三组证据：Bug 是否收敛、覆盖是否到位、遗留风险是否有人接受，再给出一条判定顺序。

一、先明确：测试报告通过的标准是什么

1. 单一指标为什么不够

一个版本剩下 12 个 Bug，能不能发？如果这些 Bug 都在低频场景，且有规避方案，风险可能可控；如果其中 1 个会导致支付重复扣款，结论就不同。Bug 数量本身不能说明影响范围。

覆盖率同样如此。用例执行率 100%，只说明计划内用例跑完了，不说明需求覆盖是否完整；代码覆盖率 80%，也不说明剩下 20% 是否包含核心交易链路。

2. 通过标准是出口准则的具体化

ISTQB 基础级大纲把出口准则，也叫测试结束标准，解释为：正式完成一项既定任务所需满足的一组条件。它的作用是防止未完成的工作被当成已经完成。

ISO/IEC/IEEE 29119-3:2021 为测试文档提供模板和示例，其中包括测试完成报告。报告需要记录测试依据、执行结果、偏差和结论。

这两条标准指向同一个要求：通过标准要事先约定，能解释，也能复核。 本文说的通过标准，是测试报告中的质量结论，供发布评审使用；最终是否发布，还要结合业务、合规和运营条件。

3. 三类证据和一条判定顺序

测试报告通过的标准至少要回答三类问题：Bug 是否在收敛、测试是否覆盖了该覆盖的范围、剩下的 Bug 是否有人愿意带着条件接受。

判定顺序建议固定为：阻断或致命问题否决、关键需求覆盖、收敛趋势、遗留风险。顺序固定，评审时才不会在细节上反复讨论。

二、Bug 收敛：看趋势，也要看统计口径

1. 四个观察信号

本文把 P0/P1 作为严重级别使用，优先级另行判断；团队也可以按自己的分级替换。

• P0 清零，P1 数量持续下降并进入逐条风险评估。
• 新增 Bug 数连续下降，按天或按轮次看趋势，不看累计总数。
• 关闭数持续大于新增数，至少连续两个统计周期。
• 重开率不高于团队基线。重开率高，先查修复质量或验证口径。

2. 观察期怎么设

观察期要覆盖最后一次代码变更之后的验证。两周迭代可用 3 到 5 个工作日；月度版本至少覆盖一轮完整回归。重点在覆盖范围，不在天数。

3. 三种看似收敛的情况

集中批量关闭、把 Bug 统一改为延期、把一个 Bug 拆成多个小单，都会让趋势看起来更好，但没有降低发布风险。

统计关闭数时，只算验证通过并关闭的 Bug；延期、拒绝、重复不计入。 重开率可以按重开 Bug 数除以同期已关闭 Bug 数计算，团队要固定统计方式。

三、覆盖率：需求、用例、代码三层各看什么

1. 需求覆盖：先锁定基线

需求覆盖回答该测的需求有没有测到。先锁定需求基线，再统计关联了已评审用例的需求。关键需求应达到 100% 覆盖，非关键需求按风险协商。 关键需求指核心交易、资金、数据安全、合规或高频主流程，评审前要锁定清单。版本中途新增或变更需求，要重新计入分母。

关联用例只说明有覆盖记录，还要看用例评审、执行结果和失败用例去向。

2. 用例执行：失败用例要有去向

用例执行率回答计划内用例有没有跑完，通过率回答跑完的结果如何。执行率应接近 100%，未执行用例要记录阻塞原因和影响范围。失败用例需要有去向：转成 Bug，或者写明不转的原因。

通过率不是越高越好。通过率异常高，可能说明用例设计偏浅，或者失败用例没有如实记录；这时要检查边界、异常场景和失败用例去向。

3. 代码覆盖：看新增代码，作辅助证据

代码覆盖回答代码有没有被执行到。新增代码的分支覆盖率更能反映本次变更的验证程度。它不能替代需求覆盖：代码被执行到，不代表业务规则被验证过。

四、遗留 Bug 风险：先处置单条，再判断版本

1. 评估一条遗留 Bug 的五个问题

• 触发条件有多容易？高频主流程还是低频边界？
• 影响范围有多大？只影响展示，还是影响资金、数据、权限或合规？
• 有没有规避手段？用户侧、运营侧或技术侧能否绕开？
• 修复和验证成本有多高？会不会引入更大范围的变更？
• 如果不修，谁来监控、监控什么指标、什么时候回滚？

遗留 Bug 要看影响，不只看数量。

2. 单条 Bug 的四类处置

单条 Bug 可以有条件接受；多条有条件接受是否构成本版本的有条件通过，要回到第五节的判定表。

3. 风险接受记录写什么

记录至少包含：Bug 编号、影响、规避方案、责任人、截止版本、监控指标、回滚条件。没有责任人和截止版本的遗留风险，往往会被拖延。

五、把三类指标合成一张测试结论表

1. 判定顺序不能反

测试报告通过的标准不能只看单项指标。先看否决项，再看覆盖底线，然后看收敛趋势，最后处理遗留风险。判定顺序固定，评审才不会偏离重点。

2. 三级测试结论与可放宽的范围

高风险不等于高优先级；涉及资金、数据、安全、合规的 Bug，即使优先级不高，也按高风险处理。这里的收敛成立，指第 2 节四个观察信号同时满足。

涉及资金、数据安全、权限或合规的 P0/P1，不进入有条件通过。

表中的结论是测试报告建议，不是最终发布决定。确认角色按组织授权调整。

3. 阈值第一次怎么定

阈值来自团队基线，不来自通用数字。 可以分三步：

1. 取近 3 个稳定版本、统计方式一致的数据，包括 P0/P1 数量、重开率、关键需求覆盖率和遗留 Bug 数。
2. 设初始线：P0 为 0；P1 原则上为 0，非核心 P1 逐条评估；重开率参考基线的中间水平；关键需求覆盖 100%。
3. 连续 2 到 3 个版本复盘误判，再调整阈值。

例如，近三版重开率在 3% 到 5%，可把 5% 作为初始上限；没有历史数据时，先用 P0=0、P1 逐条评估、关键需求 100% 作为起点。

六、测试报告怎么写，评审会才能做决定

1. 报告的六个部分

报告先给结论，再给证据。

1. 结论：建议通过、有条件通过或不通过，并列出未满足条款。
2. 范围与基线：版本、构建、需求基线、测试环境、未覆盖范围。
3. 数据窗口：测试单包含哪些轮次，统计时间范围。
4. 三类证据：Bug 收敛、三层覆盖率、遗留 Bug 清单。
5. 风险接受：规避方案、责任人、截止版本、回滚条件。
6. 确认记录：测试、开发、产品、业务各自确认的内容。

2. 数据要能对上

数据对不上，评审时就很难形成一致结论。禅道测试管理把需求、用例、测试单、Bug 和测试报告放在同一套结构中；在产品发布管理中再把构建关联到需求和 Bug，报告里的数字才容易追溯到同一版本。

据禅道官方资料，其项目管理软件已服务国内 100 万+团队。把测试数据放在同一套流程里，已经有不少团队在做。

3. 一个完整案例

某版本 P0=0，P1=1，属于不影响核心链路且有规避方案的问题，关键需求覆盖 100%，重开率 4%，遗留风险按影响和发生概率评为中风险 2 条。按上面的表，结论是有条件通过；下一版要关闭该 P1，并补齐监控和截止版本。

七、落地清单

• 锁定需求基线，明确本次版本不测什么。
• 固定统计窗口，各项指标用同一时间范围。
• 统一 Bug 分级口径，把 P0/P1 定义写进团队规范。
• 给每条遗留 Bug 建风险接受记录，不接受口头放行。
• 版本结束后复盘：哪些是漏测，哪些是误判，下一版改哪条标准。

标准写清楚，评审会才有真正的决策。 测试报告通过的标准，最终要回答的是：哪些风险已经被看见、被评估、被接受，哪些还没有。

八、常见问题

1. 领导要求按期上线，但标准没达到怎么办？

先列出未满足的条款和对应风险，再给出三个选项：补测试或修复后发布、带条件发布、申请调整发布时间。测试报告是决策输入，不是最终放行单；放行由产品、业务和技术负责人共同确认。

2. 多个团队并行开发，一张测试报告够用吗？

可以保留一张总报告，但测试单和风险清单要按产品、模块或团队拆开，跨团队接口要有联调验证记录。

3. 测试报告通过后上线出问题，责任怎么算？

报告记录的是当时已知的风险、判断依据和确认人，不能替代后续责任认定。上线后出现新问题，要按变更、环境、监控和应急响应复盘，区分已知风险和新增问题。