测试退出准则用来回答一个具体问题：测试做到什么程度可以停、由谁确认可以停。它是一组事先约定、可验证的放行条件，需要写清指标口径、阈值、证据来源和判定人。本文按条件构成、制定步骤、角色分工、版本示例和完成检查五个部分，给出一套可以直接落地的制定方法。
要点总览（TL;DR）
- 测试退出准则由缺陷收敛、用例执行、关键场景通过、遗留问题处置、评审确认五类条件组成，前四类提供客观数据，第五类由人对数据和风险做确认。
- 制定按五步推进：确认范围与风险等级、设定阈值与统计口径、明确证据来源、在测试计划评审中定稿冻结、执行期跟踪并在退出评审时逐项核对。
- 测试负责人组织准则制定与退出评审，开发负责人给出遗留缺陷处置意见，产品/业务负责人确认关键场景与风险接受，质量或项目管理者归档证据与结论。
- 未达标不等于一定不放行，但放行必须有明确的处置路径和风险接受记录，且执行期不得临时调整阈值。
- 准则定稿前用完成检查清单核对：可量化、有证据来源、有判定人、未达标有处置路径、结论留痕、变更经评审。
测试退出准则由哪些条件组成
一份可执行的退出准则通常由五类条件组成：缺陷收敛、用例执行、关键场景通过、遗留问题处置、评审确认。前四类提供客观数据，第五类提供人对数据和风险的确认。五类条件缺一不可：只有缺陷数据没有评审，判定容易变成数字游戏；只有评审没有数据，结论无法复核。
每类条件都要落到具体对象上，并写明指标口径。口径要说明统计范围，例如缺陷按严重级别分别统计、用例按优先级分别统计，避免执行期各人算法不一致。
| 条件类别 | 指标示例 | 证据来源 | 判定人 |
|---|---|---|---|
| 缺陷收敛 | 致命与严重缺陷关闭率100%，一般缺陷关闭率达到约定阈值，新增缺陷趋势连续若干天下降 | 缺陷管理系统中的状态、级别、时间记录 | 测试负责人 |
| 用例执行 | 计划内用例执行率100%，高优先级用例通过率达到约定阈值 | 测试用例库与执行记录 | 测试负责人 |
| 关键场景通过 | 核心业务流程、关键集成路径按清单全部通过 | 场景清单与执行结果、验收记录 | 产品/业务负责人 |
| 遗留问题处置 | 每个未关闭缺陷有明确处置意见：修复、延期、规避或接受，并注明影响范围 | 缺陷记录中的处置结论与责任人 | 开发负责人提出，产品负责人确认 |
| 评审确认 | 退出评审会完成，结论与依据形成记录 | 评审纪要、签字或系统审批记录 | 测试负责人组织，相关角色确认 |
条件与测试范围、风险等级对应。面向核心交易链路的高风险版本，关键场景清单更长、缺陷阈值更严；内部工具的小版本可以适当简化，但简化本身要写进准则，不能在执行期临时放宽。风险等级建议在测试计划阶段就与需求方确认，作为设定阈值的输入。
制定退出准则的操作步骤
制定过程从范围确认开始，到准则定稿冻结结束，执行期只按已定稿的口径跟踪。以下五步给出每步的输入、动作、输出和完成标志。
步骤一：确认测试范围与风险等级
输入是需求文档、变更说明和风险清单。动作是列出本次测试覆盖的功能、接口和场景，标注每项的风险等级，明确哪些内容不在本次范围内。输出是一份范围与风险清单。完成标志是产品、开发、测试三方对范围无异议。
步骤二：为每类条件设定阈值与统计口径
输入是范围与风险清单、历史版本的质量数据。动作是逐类确定指标、阈值和统计口径，例如缺陷按什么级别统计、用例按什么优先级统计、趋势观察窗口取多长。输出是条件框架表。完成标志是每个指标都能用一句话说清“怎么算、算到多少算达标”。
步骤三：明确证据来源与数据记录方式
输入是条件框架表。动作是为每项条件指定数据来自哪个系统或文档、由谁在什么时点记录、以什么形式留存。输出是证据来源清单。完成标志是每项条件都能在执行期找到对应记录，且记录方式不依赖个人记忆。
步骤四：在测试计划评审中定稿并冻结版本
输入是条件框架表和证据来源清单。动作是把准则并入测试计划，在评审会上逐条确认，形成带版本号的定稿。输出是已评审的退出准则。完成标志是评审记录留存，准则版本号可追溯。
步骤五：执行期按口径跟踪，退出评审时逐项核对
输入是定稿准则和测试执行数据。动作是执行期按同一口径持续记录，临近结束时组织退出评审，逐项核对并记录结论。输出是退出判定记录。完成标志是每项条件都有“达标/未达标”结论及对应证据。
准则定稿后如需调整，走变更评审并保留原版本，避免执行期口径漂移。跟踪和归档环节可以借助ONES的工作项与文档能力承载：把退出条件作为检查项挂在测试计划下，执行数据随工作项状态更新，评审结论沉淀在文档中，便于退出评审时逐项对照。
角色分工与各阶段交付物
退出准则涉及四类角色，分工的核心是让“定规则的人”和“判结果的人”有明确边界，同时保证风险接受由业务方拍板。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 测试负责人 | 组织准则制定，维护统计口径，组织退出评审，给出测试侧判定意见 | 条件框架表、执行数据汇总、退出评审纪要 |
| 开发负责人 | 推动缺陷修复，对遗留缺陷给出技术处置意见和影响判断 | 缺陷修复记录、遗留问题处置意见 |
| 产品/业务负责人 | 确认关键场景验收结果，对接受的风险签字确认 | 关键场景验收记录、风险接受说明 |
| 质量或项目管理者 | 归档证据，记录退出结论，跟踪未达标项的后续处理 | 证据归档目录、退出结论记录、后续跟踪清单 |
分工要写进准则本身，而不是停留在口头约定。每个判定人对应哪几项条件、在什么时点给出结论，都应在条件框架表中体现。遗留问题的风险接受由产品/业务负责人确认，测试负责人提供数据支撑，两者职责不混同。
示例：一次版本测试的退出判定
以下为演示情景，用于说明逐项核对的方式，不代表真实项目数据。
背景：某业务系统发布一个包含支付流程调整的版本，风险等级定为高。测试范围包括支付主流程、退款流程和订单查询，关键场景清单共12项。
| 条件 | 准则要求 | 实际结果 | 结论 |
|---|---|---|---|
| 缺陷收敛 | 致命与严重缺陷关闭率100%；一般缺陷关闭率不低于90%；新增缺陷连续3天下降 | 致命与严重缺陷全部关闭；一般缺陷关闭率93%；新增缺陷连续3天下降 | 达标 |
| 用例执行 | 计划用例执行率100%；高优先级用例通过率100% | 执行率100%；高优先级用例通过率100% | 达标 |
| 关键场景 | 12项关键场景全部通过 | 11项通过，1项退款异常提示文案场景未通过 | 未达标 |
| 遗留问题 | 每个未关闭缺陷有处置意见 | 未通过场景对应1个一般缺陷，开发给出修复方案，产品确认可延期至下个版本并接受提示文案暂不准确的风险 | 已处置 |
| 评审确认 | 退出评审完成并留记录 | 评审会完成，结论为“有条件通过”，附延期修复项 | 完成 |
判定过程：关键场景一项未达标，按准则不能直接判定通过。处置方式是开发给出修复方案，产品负责人确认风险可接受并记录在案，评审会据此给出“有条件通过”结论，同时把延期修复项列入后续跟踪清单。整个判定中，缺陷统计口径与准则定稿时一致，未因临近发布而调整阈值。这个示例说明：未达标不等于一定不放行，但放行必须有明确的处置路径和风险接受记录。
完成检查：退出准则是否可执行
准则定稿前和退出判定完成后，都可以用下面这份清单逐项核对。
- 每项条件都有可量化的指标和明确的统计口径，不同人按同一口径计算能得到相同结果。
- 每项条件都写明了证据来源，执行期能实际取到对应记录。
- 每项条件都有指定的判定人，判定时点清晰。
- 未达标项有处置路径：修复、延期、规避或风险接受，且接受方明确。
- 退出结论有记录，包含逐项核对结果、证据位置和参与确认的角色。
- 准则有版本号，变更经过评审，历史版本可追溯。
- 准则中的阈值与本次测试的风险等级相匹配，高风险范围没有套用低风险阈值。
清单全部通过，说明准则具备被执行和复核的条件；任何一项缺失，都建议在测试计划评审阶段补齐，而不是留到退出评审时临时解释。
常见问题
退出准则定稿后，执行中发现阈值设得不合理，可以临时调整吗？
不建议在执行期直接调整阈值。更稳妥的做法是走变更评审：说明调整原因、影响哪些条件、由谁确认，形成新版本并保留原版本记录。这样退出评审时能说清每个阈值是何时、因何确定的。如果确实遇到准则未覆盖的新风险，可以在评审中作为例外事项单独记录处置意见，与常规阈值调整分开处理。
小版本或内部工具的测试，退出准则可以简化到什么程度？
可以简化条件数量和阈值严格度，但简化本身要写进准则，并在测试计划评审时确认。例如内部工具版本可以只保留缺陷收敛、用例执行和评审确认三类条件，关键场景清单缩短。需要保留的是每项条件的指标口径、证据来源和判定人，这三项缺失会让判定无法复核。风险等级低的版本用低阈值是合理的，前提是风险等级在计划阶段已与需求方确认。
关键场景未通过但业务方愿意接受风险，退出结论应该怎么写？
结论写“有条件通过”并附条件，而不是直接写“通过”。记录中要包含：未通过的具体场景、对应缺陷、开发给出的处置方案、产品/业务负责人的风险接受说明、延期修复的跟踪责任人和时间点。这样结论既反映了实际状态，也保留了后续追责和复核的依据。测试负责人提供数据支撑，风险接受由业务方确认，两者在记录中分开体现。
缺陷收敛条件里的“新增缺陷趋势下降”，观察窗口取多长比较合适？
观察窗口取决于版本周期和缺陷发现节奏，常见做法是取连续3到5天，或在版本最后阶段按轮次观察。关键是窗口长度在准则定稿时就写清楚，执行期按同一口径统计，避免临近发布时缩短窗口让趋势看起来更好。如果版本周期很短，可以改用“连续两轮回归新增缺陷数不增加”这类按轮次的口径，同样要事先约定。
退出评审需要哪些人参加，缺席时判定是否有效？
退出评审至少需要测试负责人、开发负责人和产品/业务负责人参与，质量或项目管理者负责记录与归档。判定人缺席时，其负责的条件无法完成确认，建议改期或由被授权人代为确认并留下授权记录。评审的价值在于让数据核对和风险接受同时发生，缺少任一方的确认，结论的可追溯性都会打折扣。
