测试退出准则的核心，是把“质量目标是否达成、剩余风险是否可接受”写成可量化、可核验的判定条件。本文给出一套条目框架、从目标推导到评审定稿的操作步骤、角色分工、完整示例和完成检查清单，帮助测试负责人为一个版本或项目制定能真正用于放行决策的退出准则。
要点总览（TL;DR）
- 退出准则由覆盖率、缺陷收敛、用例通过率、遗留缺陷、非功能指标、回归完成度等条目组成，每条写清指标定义、阈值、统计口径、数据来源、责任人和判定时点。
- 制定过程分五步：从测试目标与风险推导方向、设定阈值与口径、确定证据来源与判定时点、约定例外与放行流程、评审确认并纳入测试计划。
- 测试负责人牵头制定与判定，开发负责人确认修复状态与技术风险，产品/业务负责人确认业务风险，质量或发布审批角色批准例外放行。
- 强制项未达标原则上不能退出测试，参考项用于提供判断依据；例外放行需有申请、风险说明、审批意见和放行后跟踪项。
- 定稿前用检查清单核对：条目可量化、口径唯一、数据可获取、责任人明确、例外流程写清、与目标风险对应、评审记录留存。
测试退出准则由哪些条目组成
退出准则由一组判定条目构成，每条回答一个具体问题：测试是否做得足够、缺陷是否收敛、关键功能是否可靠、剩余风险是否被看见并接受。条目数量控制在能支撑放行决策的范围内，通常6到10条即可，条目过多会让判定变成填表。
常见的条目类型包括：需求或代码覆盖率、缺陷收敛趋势、关键用例通过率、遗留缺陷等级与数量、非功能指标（性能、安全、兼容性等按项目需要选取）、回归完成度。这些条目分别对应“测到了没有”“问题在减少吗”“核心路径稳不稳”“剩下的问题能不能接受”“非功能底线守住了吗”“改动有没有引入新问题”。
每条准则必须写清六个字段，缺一个就可能在判定时产生争议：
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 指标定义 | 用一句话说明指标含义，避免同名不同义 | 关键用例通过率＝最近一轮全量回归中P0/P1用例通过数÷执行总数 |
| 阈值 | 给出具体数值或明确状态，不用“较高”“基本完成” | 关键用例通过率100%，P2用例通过率≥98% |
| 统计口径 | 说明统计范围、时间窗口、去重规则 | 统计最近一次全量回归；同一用例多次执行取最后一次结果 |
| 数据来源 | 指明从哪个系统、哪份报告取数 | 测试管理工具中的用例执行记录、缺陷管理系统中的缺陷列表 |
| 责任人 | 指定对该条目数据准确性负责的人 | 测试负责人或对应模块测试Owner |
| 判定时点 | 说明在什么节点核对这条准则 | 发布评审会前一个工作日冻结数据 |
条目还要区分强制项与参考项。强制项未达标原则上不能退出测试，例如P0用例全部通过、无未关闭的致命或严重缺陷；参考项用于提供判断依据，例如缺陷发现速率已明显下降、自动化回归覆盖主要链路。区分二者的目的是让评审聚焦在真正影响放行的条件上，避免所有指标都被当成一票否决。
制定退出准则的操作步骤
制定过程从测试目标出发，到准则被评审确认并纳入测试计划结束。下面五步按顺序执行，每步都给出输入、动作、输出和完成标志。
第一步：从测试目标与风险分析推导准则方向
输入是本次版本的测试目标、需求范围、变更内容和风险分析结论。动作是识别本次发布最怕出什么问题：是核心交易链路变更、是数据结构调整、还是仅界面文案修改。输出是一份“风险—验证方式—判定方向”的清单。完成标志是每个主要风险都能对应到至少一条候选准则方向，且没有准则与目标无关。
第二步：为每个条目设定阈值与统计口径
输入是第一步的候选方向和历史数据（上一版本的缺陷密度、用例通过率、遗留缺陷情况）。动作是为每条准则写出指标定义、阈值和统计口径，阈值参考历史基线并留出合理余量。输出是准则条目初稿。完成标志是每条准则都能被两个人独立计算出一致结果，不存在“看情况”的表述。
第三步：确定证据来源与判定时点
输入是准则条目初稿和团队现有工具链。动作是逐条确认数据从哪里取、由谁在什么时间点冻结，并检查数据是否真实可得。输出是带数据来源和判定时点的准则表。完成标志是每条准则都有明确的数据出处和责任人，且判定时点早于发布决策会。
第四步：约定未达标时的例外与放行流程
输入是准则表。动作是写明某条强制项未达标时如何处理：由谁提出例外申请、需要哪些风险说明和缓解措施、由谁审批、放行后如何跟踪。输出是例外审批规则。完成标志是任何一条强制项未达标时，团队都知道下一步找谁、提交什么、多久能得到答复。
第五步：评审确认并纳入测试计划
输入是完整的准则表与例外规则。动作是组织测试、开发、产品负责人评审，确认阈值合理、口径无歧义、职责可执行，并将准则写入测试计划或版本质量计划。输出是评审通过的退出准则。完成标志是评审记录留存、准则版本确定，且测试执行阶段按同一份准则跟踪。
角色分工与各阶段交付物
退出准则要落地，需要明确谁定、谁统计、谁判定、谁批准例外。角色划分可以按团队规模调整，但职责不能空缺。
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 测试负责人 | 牵头制定准则，组织数据统计，主持判定评审 | 退出准则文档、测试执行与缺陷统计报告、判定结论 |
| 开发负责人 | 确认缺陷修复状态与技术风险，参与阈值合理性评审 | 缺陷修复说明、遗留缺陷技术影响评估 |
| 产品/业务负责人 | 确认业务风险可接受程度，参与例外审批 | 业务风险评估意见、例外放行的业务确认 |
| 质量或发布审批角色 | 审核准则执行情况，批准或驳回例外放行 | 放行审批记录、例外处理结论 |
各环节的交付物形成一条链：准则制定阶段产出准则文档和评审记录；数据统计阶段产出用例执行报告、缺陷清单和趋势数据；判定评审阶段产出逐条判定结论和遗留风险说明；例外审批阶段产出例外申请、审批意见和放行后的跟踪项。每个交付物都应能对应到具体责任人和时间点，避免评审会上临时找数据。
当准则条目、缺陷状态和评审记录分散在多个表格中时，判定容易变成口头确认。把退出准则作为版本质量计划的一部分，在研发管理工具中建立对应的工作项或检查项，让每条准则关联到用例执行记录、缺陷列表和评审结论，可以让判定过程留下可追溯的记录。ONES 支持在工作项中维护检查项、关联缺陷与测试记录，并保留评审与审批过程，适合承载这类需要逐条核对的管理动作；具体配置方式按团队现有流程设计。
示例：一个版本的退出准则怎么写
以下为演示情景，用于说明准则的填写与判定方式，不代表任何真实项目数据。
背景：某业务系统发布一个包含订单流程调整和两个新报表的版本，测试范围包括订单创建、支付回调、退款和报表导出，回归范围覆盖受影响的上下游接口。
| 条目 | 阈值 | 统计口径 | 数据来源 | 类型 |
|---|---|---|---|---|
| P0/P1用例通过率 | 100% | 最近一轮全量回归，按最后一次执行结果计 | 测试管理工具执行记录 | 强制 |
| P2用例通过率 | ≥98% | 同上，未通过项需有缺陷单或明确说明 | 测试管理工具执行记录 | 强制 |
| 致命/严重缺陷 | 0个未关闭 | 统计截至判定时点所有未关闭的致命、严重级缺陷 | 缺陷管理系统 | 强制 |
| 一般缺陷遗留 | ≤5个，且均有规避方案 | 仅统计影响本版本变更范围的缺陷 | 缺陷管理系统 | 强制 |
| 缺陷收敛 | 最近3天新增缺陷数持续下降 | 按发现日期统计每日新增，排除环境问题 | 缺陷管理系统趋势 | 参考 |
| 支付回调性能 | P95响应时间≤500ms | 压测环境，连续3轮取稳定值 | 性能测试报告 | 强制 |
| 自动化回归 | 核心链路自动化用例全部通过 | 最近一次 nightly 执行结果 | 自动化测试报告 | 参考 |
判定时，测试负责人提前一个工作日冻结数据，逐条核对：P0/P1用例全部通过；P2通过率99.2%，两条未通过用例已关联缺陷单；致命严重缺陷为0；一般缺陷遗留4个，均有临时规避方案；性能压测P95为420ms；缺陷新增趋势连续三天下降；自动化回归全部通过。所有强制项达标，参考项正常，判定可以退出测试。
若一般缺陷遗留为7个，则触发例外流程：测试负责人整理遗留缺陷清单和影响说明，产品负责人确认业务可接受，发布审批角色批准后放行，并将7个缺陷列入下个版本的修复计划跟踪。例外结论和跟踪项一并记录在评审记录中。
完成检查：准则是否可执行
准则定稿前，用下面这份清单逐项核对。任何一项不满足，都应在评审前修正。
- 每条准则都有具体数值或明确状态，没有“基本完成”“较高”这类表述。
- 每条准则的统计口径唯一，换一个人按同样口径能算出相同结果。
- 每条准则的数据来源真实可获取，且在判定时点前能够冻结。
- 每条准则都有明确责任人，责任人知道自己在什么时间提供什么数据。
- 强制项与参考项已区分，强制项未达标时的例外申请、审批和跟踪流程已写清。
- 准则条目与本次测试目标和主要风险一一对应，没有与目标无关的凑数条目。
- 准则已经过测试、开发、产品相关角色评审，评审记录留存。
- 准则已纳入测试计划或版本质量计划，并约定版本范围变化时的更新方式。
满足以上条件的准则，才能在发布评审会上直接用于判定，而不是会后再补数据、再讨论标准。
常见问题
强制项和参考项应该怎么划分？
划分依据是这条准则未达标时是否直接改变放行结论。P0/P1用例全部通过、无未关闭的致命或严重缺陷、关键非功能指标达标，这类条目一旦不满足就意味着核心质量目标未达成，应列为强制项。缺陷收敛趋势、自动化回归覆盖情况等条目用于提供判断依据，适合列为参考项。
划分时要注意两点：强制项数量不宜过多，否则例外审批会变成常态；参考项也要写清阈值和口径，避免判定时被随意解读。团队可以在评审时逐条确认，把每条准则归入强制或参考，并记录理由。
阈值定多少合适，没有历史数据怎么办？
有历史数据时，阈值参考上一版本或近几个版本的基线，并留出合理余量，例如P2用例通过率历史在98%到99%之间，可以把阈值定在98%。没有历史数据时，可以从测试目标和风险出发先定一个可讨论的初始值，在第一个版本执行后复盘调整。
阈值要避免两个极端：定得过松，准则失去判定作用；定得过严，每次发布都触发例外审批。建议在评审时让测试、开发、产品三方共同确认，并写明阈值调整的条件和审批方式。
判定时点应该设在什么时候？
判定时点应早于发布决策会，给数据核对和例外审批留出时间。常见做法是在发布评审会前一个工作日冻结数据，测试负责人按准则逐条核对，发现未达标项立即启动例外流程。
如果判定时点太靠近发布，数据来不及核对，例外审批也会被压缩成口头确认。对于需要多轮压测或长时间观察的条目，例如性能指标和缺陷收敛趋势，还要把数据采集的起始时间提前写进准则，确保判定时点能拿到完整数据。
版本范围中途变化，退出准则要不要跟着改？
要改，但应走变更确认而不是临时口头调整。版本范围变化后，先判断新增或删减的内容是否影响原有风险和测试目标，再决定是否增加条目、调整阈值或改变判定时点。
建议在准则中约定更新方式：由测试负责人提出调整说明，经原评审角色确认后更新准则版本，并保留变更记录。这样判定时使用的是最新确认过的准则，评审会上也能说清每条准则的由来。
例外放行后需要跟踪哪些内容？
例外放行后至少跟踪三类内容：遗留缺陷的修复计划与责任人、缓解措施的执行情况、以及下个版本对这些问题的验证安排。例外申请中写明的风险说明和审批意见应一并留存，作为后续复盘依据。
跟踪项要有明确的关闭条件，例如遗留缺陷在下个版本修复并通过回归验证。若跟踪项长期未关闭，应在下一次发布评审时重新评估其影响，避免例外放行积累成长期风险。
