测试退出准则要能支撑“现在可以停测”的判断，而不是只列几条原则。下面给出一个演示情景：某版本完成功能测试与回归测试后，团队依据一份填好的退出准则决定是否结束测试。示例覆盖准则条目、判定口径、证据来源、责任人和未达标处理，并说明换项目时如何调整。文中数值均为演示取值，不对应真实项目。
要点总览（TL;DR）
- 测试退出准则示例围绕一个具体测试对象，把退出条件写成可核验的条目：覆盖完成度、用例执行与通过、缺陷收敛与遗留处置、关键非功能验证、回归完成、交付物齐备。
- 每条准则由条件、判定口径、证据来源、责任人和未达标处理五部分组成，判定口径说明怎样算达标，证据来源说明拿什么证明。
- 缺陷收敛看趋势而非总数，遗留缺陷按严重程度分级处置，通过率需说明统计范围与重测规则，证据来源要指向可查询的具体记录。
- 迁移时保留五段式结构，按测试层级调整条目，按风险调整阈值与审批层级，准则评审与变更要留记录。
- 示例数值均为演示取值，专项测试需补充专门准则，外部约定优先于内部准则，满足准则不等于质量风险清零。
示例目标：这份退出准则要回答什么
示例假设一个中等规模的版本迭代：包含若干新增功能、对既有功能的修改，以及一轮完整回归。测试层级覆盖系统测试与回归测试，验收测试由业务方另行组织。退出准则要在这个范围内回答三个问题：测试活动能否结束、遗留问题如何处置、由谁确认结束。
第一个问题对应“停测判断”。准则需要说明覆盖范围是否测完、用例执行到什么程度、缺陷是否收敛到可接受水平。第二个问题对应“遗留处置”。未修复缺陷不能简单计入“已知问题”，要按严重程度给出修复、规避、延期或风险接受的明确结论。第三个问题对应“确认责任”。测试负责人、开发负责人和产品负责人各自确认什么内容，需要在准则中写清，避免停测决定停留在口头层面。
这份示例是演示情景，用于展示填写结构和表述方式，不代表任何真实项目的测试结论。示例中的百分比、缺陷数量和天数均为演示取值，实际使用时按项目情况重新设定。
完整示例：一份填好的测试退出准则
下表是一份填好的退出准则。每条准则由条件、判定口径、证据来源、责任人和未达标处理五部分组成。判定口径说明“怎样算达标”，证据来源说明“拿什么证明”，未达标处理说明“差一点时怎么办”。
| 编号 | 退出条件 | 判定口径（演示取值） | 证据来源 | 责任人 | 未达标处理 |
|---|---|---|---|---|---|
| E1 | 测试范围覆盖完成 | 本期需求清单中的功能点全部有对应用例，覆盖率100%；需求变更已同步更新用例 | 需求—用例覆盖对照表、需求变更记录 | 测试负责人 | 缺口功能补测后重新评审；无法补测的列入风险接受清单 |
| E2 | 用例执行率达标 | 计划内用例执行率≥98%，未执行用例均有书面原因 | 测试执行记录、未执行说明 | 测试负责人 | 补充执行或由产品负责人确认豁免 |
| E3 | 用例通过率达标 | 执行用例通过率≥95%；失败用例已修复并重测通过，或转为缺陷跟踪 | 执行结果统计、重测记录 | 测试负责人 | 分析失败集中模块，补充一轮针对性测试 |
| E4 | 缺陷收敛 | 最近5个工作日新增严重及以上缺陷为0，缺陷关闭率持续上升，无长期挂起的高优先级缺陷 | 缺陷趋势图、按严重程度统计的缺陷清单 | 测试负责人与开发负责人 | 延长测试周期，定位收敛停滞原因 |
| E5 | 遗留缺陷分级处置 | 致命、严重级遗留缺陷为0；一般级遗留缺陷均有规避方案和修复计划；轻微级可延期 | 遗留缺陷清单及处置结论 | 产品负责人确认，测试负责人汇总 | 严重级缺陷未清零则不进入退出评审 |
| E6 | 关键非功能验证 | 本期涉及的性能、兼容性、权限等验证项全部执行，结果符合既定指标 | 专项测试报告 | 测试负责人 | 未覆盖项列入下期计划并评估对本期的影响 |
| E7 | 回归完成 | 回归用例集执行完毕，核心业务流程回归通过率100% | 回归执行记录 | 测试负责人 | 核心流程回归未通过则阻断退出 |
| E8 | 交付物齐备 | 测试报告、缺陷统计、遗留问题清单、测试总结已提交并完成评审 | 文档库中的评审记录 | 测试负责人 | 补齐文档后再提交退出评审 |
表格之外还需一段结论性说明：本次测试满足E1至E8中的哪些条目、哪些条目以风险接受方式通过、接受人是谁、接受的有效期到何时。这段说明与表格共同构成完整的退出记录。
逐项解释：每条准则为什么这样写
缺陷收敛为什么看趋势而不是总数
缺陷总数受需求规模和测试投入影响，单看总数无法判断质量是否稳定。示例中E4采用“最近5个工作日新增严重及以上缺陷为0”加“关闭率持续上升”的组合，目的是观察缺陷发现速度是否下降、修复速度是否跟上。如果新增缺陷仍在高位，说明测试尚未触及稳定状态，此时停测容易把问题带到线上。趋势口径需要固定统计周期和严重程度范围，否则不同人算出的结果不一致。
遗留缺陷为什么按严重程度分级写
把所有遗留缺陷统一写成“已知问题”会掩盖风险差异。示例按致命、严重、一般、轻微四级分别给出处置要求：前两级要求清零，一般级要求有规避方案和修复计划，轻微级允许延期。这样写的目的是让每个遗留缺陷都有明确结论，而不是留待上线后再讨论。分级标准应引用团队已有的缺陷严重程度定义，避免在退出准则中另立一套口径。
通过率为什么要说明统计范围和重测规则
通过率的分母不同，结果差别很大。示例在E3中明确“执行用例通过率”，即分母是已执行用例，而非全部计划用例；同时要求失败用例“修复并重测通过，或转为缺陷跟踪”。如果不写重测规则，修复后的用例可能被重复计入通过数，导致通过率虚高。填写时应说明：统计截止时间、是否包含重测、失败转缺陷后是否仍计入分母。
证据来源为什么要指向具体记录
“测试已完成”“缺陷已处理”这类口头确认无法复核。示例中每条准则都指向可查询的记录：覆盖对照表、执行记录、缺陷清单、专项报告、评审记录。填写证据来源时，应写明记录的名称和存放位置，使评审人能够自行核对。证据来源与判定口径要对应，口径说覆盖率100%，证据就应能逐条列出功能点与用例的对应关系。
当这些准则在协作工具中执行时，用例执行记录、缺陷状态和评审结论需要能按版本汇总。ONES 的测试管理可承载测试用例与执行记录，缺陷可与需求、迭代关联，测试报告和评审记录可沉淀为文档，便于在退出评审时按条目调取证据。是否使用工具承载不影响准则本身的写法，关键是证据可追溯、结论可复核。
可迁移规律：换一个项目怎么改
示例的价值在结构，不在具体数值。迁移时保留“条件—口径—证据—责任人—未达标处理”五段式，再按测试层级和风险等级调整内容。
按测试层级调整条目
- 单元测试：退出条件侧重覆盖率与静态检查结果，证据为覆盖率报告和检查记录，责任人通常是开发负责人。
- 集成测试：侧重接口连通性、数据一致性和异常场景，证据为接口测试记录和联调问题清单。
- 系统测试：可沿用示例的主体条目，覆盖功能、回归和关键非功能验证。
- 验收测试：侧重业务场景走查和用户确认，证据为验收记录和业务方签字，责任人为产品负责人或业务代表。
按风险调整阈值与审批层级
涉及资金、权限或对外服务的模块，可提高通过率要求、收紧遗留缺陷分级，并把退出确认提升到更高层级审批。内部工具类版本可适当放宽执行率要求，但未执行用例的原因仍需书面记录。阈值调整应写明依据，例如“本期涉及支付流程，严重级遗留缺陷要求清零”，而不是笼统写“高风险项目从严”。
准则评审与变更要留记录
退出准则应在测试计划阶段完成评审，参与方包括测试、开发和产品。执行过程中如需调整阈值或增删条目，应记录变更原因、变更人和生效时间，并在退出评审时说明。变更记录本身也是证据的一部分，能解释最终结论与初始计划之间的差异。
适用边界：示例不能直接照搬的地方
示例中的百分比、天数和缺陷数量均为演示取值，直接套用可能与本项目规模、迭代周期和质量目标不匹配。使用前应结合历史数据设定阈值，例如参考前几个版本的执行率和缺陷收敛速度，而不是照抄95%或5个工作日。
示例覆盖功能测试与回归测试的通用判断。安全测试、性能测试等专项需要补充专门准则，例如漏洞等级分布、响应时间指标和压测通过标准，这些内容不能由通用条目替代。若项目受监管要求或合同条款约束，外部约定的测试完成标准优先于内部准则，退出评审时应逐条对照。
满足退出准则表示计划内的测试活动已完成、遗留风险已有明确处置结论，质量风险并未因此清零。上线后的监控、灰度观察和快速回滚预案仍应保留。退出准则是停测判断的依据，也是风险交接的记录，把这两层含义写清楚，准则才真正可用。
常见问题
退出准则里的阈值应该定多少，有没有通用标准？
没有适用于所有项目的通用阈值。示例中的98%执行率、95%通过率、5个工作日无新增严重缺陷都是演示取值，用于展示写法。实际设定时可参考本项目前几个版本的历史数据：执行率长期在什么水平、缺陷通常在测试第几周收敛、遗留缺陷一般如何处理。阈值应能区分“正常完成”和“明显未完成”，定得过松失去判断意义，定得过紧会导致每次评审都在讨论豁免。
退出准则应该在什么时候制定，测试开始后还能改吗？
建议在测试计划阶段完成初稿并评审，参与方包括测试、开发和产品。测试执行中如果发现原阈值不合理，例如需求范围发生较大变更或发现某模块缺陷集中，可以调整，但要记录变更原因、变更人和生效时间，并在退出评审时说明。变更记录本身是证据的一部分，能解释最终结论与初始计划之间的差异。临时在退出评审会上才提出修改阈值，容易让评审变成讨价还价。
遗留缺陷由谁决定接受，接受之后还要做什么？
示例中遗留缺陷的处置结论由产品负责人确认、测试负责人汇总，严重级缺陷未清零不进入退出评审。风险接受不是终点：接受时应写明接受人、接受理由和有效期，一般级遗留缺陷还需有规避方案和修复计划。上线后这些缺陷应继续跟踪，按计划修复并验证。如果接受有效期到期仍未修复，需要重新评估是否影响后续版本。
单元测试、验收测试的退出准则能直接套用这份示例吗？
结构可以复用，条目需要调整。单元测试侧重覆盖率和静态检查结果，证据是覆盖率报告和检查记录，责任人通常是开发负责人；验收测试侧重业务场景走查和用户确认，证据是验收记录和业务方签字，责任人是产品负责人或业务代表。系统测试可以沿用示例主体条目。把系统测试的通过率口径直接搬到单元测试，统计对象和分母都不同，结论没有可比性。
准则全部达标了，是不是就可以放心上线？
退出准则回答的是“计划内的测试活动是否完成、遗留风险是否已有明确处置结论”，质量风险并未因此清零。上线后的监控、灰度观察和快速回滚预案仍应保留。对于涉及资金、权限或对外服务的模块，即使准则达标，也建议安排上线后的重点观察期。把退出准则理解为停测判断依据和风险交接记录，比把它当作质量保证书更符合实际。
