测试退出准则要回答的是“什么情况下可以停止测试并进入下一阶段”。可执行的做法是分层定义退出对象，把通过率、缺陷收敛、遗留缺陷等级与数量、覆盖率等写成可核验的阈值和统计口径，明确谁有权判定、谁复核、什么条件下允许带条件退出，并把判定证据与例外记录归档。本文给出字段表、指标写法、制定步骤、角色分工、判定示例和自查清单。
要点总览（TL;DR）
- 退出准则按单元、集成、系统、验收分层定义，每条准则写明判定指标、阈值、统计口径、数据来源、判定人与复核人，并区分硬性条件与软性条件。
- 指标要落到可计算的分子分母：执行率与通过率明确阻塞用例的处理方式，遗留缺陷按严重等级设上限，覆盖率作为补充门槛，缺陷收敛趋势用于辅助判断。
- 制定流程分五步：梳理层级与阶段、选取指标设阈值、评审确认判定权与例外流程、在测试计划中固化执行、归档证据并复盘阈值。
- 判定权与复核权分离，带条件退出由产品或业务负责人承担风险决定，测试负责人提供证据与风险说明，所有审批记录归档。
- 定稿前用自查清单核对可量化、口径唯一、角色明确、例外有路径、阈值与风险匹配并定期回看。
退出准则先定在哪一层：分层框架与核心字段
一份退出准则如果只写“系统测试通过后退出”，执行时就会陷入各说各话。合理的做法是按测试层级分别定义退出对象：单元测试关注代码级验证是否完成，集成测试关注模块间接口与数据流是否稳定，系统测试关注端到端功能与非功能表现，验收测试关注业务场景是否满足交付要求。每一层级的责任范围不同，判定人和证据来源也应不同。
每个层级的准则条目应包含以下字段，缺一项就可能在判定时产生争议：
| 字段 | 填写要求 | 示例（示意） |
|---|---|---|
| 适用层级 | 单元/集成/系统/验收，一条准则只对应一个层级 | 系统测试 |
| 判定指标 | 可统计的指标名称，避免“质量良好”这类描述 | 用例通过率 |
| 阈值 | 数值加比较关系，注明是否硬性 | ≥95%，硬性 |
| 统计口径 | 分子分母如何取数、统计时间窗 | 本轮计划内用例，截至判定日 |
| 数据来源 | 唯一指定的记录位置 | 测试计划执行记录 |
| 判定人 | 有权宣布该层级退出的角色 | 测试负责人 |
| 复核人 | 核对证据与口径的角色 | 质量管理者 |
| 例外处理 | 未达标时的可选路径与审批要求 | 带条件退出需产品负责人签字 |
字段之外，还要区分硬性条件与软性条件。硬性条件是“必须满足”，例如致命和严重缺陷清零、关键用例全部执行且通过；软性条件是“可评估”，例如缺陷收敛趋势向好、一般缺陷密度低于基线。硬性条件不满足时原则上不能退出，软性条件不满足时可以进入风险评审，由判定人结合发布窗口决定是否带条件退出。把两者混在一起写，会让准则失去约束力。
指标与阈值怎么写：从通过率到缺陷收敛
指标写不实，阈值就无从谈起。以下逐类说明定义方式与常见写法，表中数值均为示意值，团队应结合自身历史数据校准。
用例执行率与通过率
执行率的分子是已执行用例数，分母是本轮计划执行的用例总数，计划外临时补充的用例应单独统计，避免稀释分母。通过率的分子是通过用例数，分母是已执行用例数；被阻塞、被跳过的用例不计入通过率分母，但要在报告中单列数量。常见写法是“执行率100%，通过率≥95%，阻塞用例为0”。
缺陷类指标
遗留缺陷按严重等级设上限，比笼统的缺陷密度更有约束力。典型写法是：致命、严重遗留缺陷为0；一般遗留缺陷不超过约定数量且均有修复计划；轻微缺陷可延后处理。缺陷密度可作为辅助指标，按每千行代码或每个功能点统计，适用于有稳定基线的团队。缺陷收敛趋势用于退出前的辅助判断：连续若干轮回归中新增缺陷数持续下降、修复率上升，说明质量趋于稳定；若新增缺陷仍高位波动，即使通过率达标也应谨慎退出。
覆盖率类指标
需求覆盖率适用于系统测试和验收测试，统计已覆盖需求条目占本轮范围需求的比例，前提是需求条目拆分到可验证粒度。代码覆盖率适用于单元测试和集成测试，常见阈值是行覆盖和分支覆盖分别设定下限。覆盖率反映“测了多少”，不反映“测得对不对”，因此适合作为硬性门槛的补充，不宜单独作为退出依据。
| 指标 | 适用层级 | 口径要点 | 示意阈值 |
|---|---|---|---|
| 用例执行率 | 系统、验收 | 已执行/计划执行，阻塞单列 | 100% |
| 用例通过率 | 系统、验收 | 通过/已执行，阻塞不计入分母 | ≥95% |
| 致命与严重遗留缺陷 | 各层级 | 按严重等级计数，含未关闭 | 0 |
| 一般遗留缺陷 | 系统 | 计数并附修复计划 | ≤5个且有计划 |
| 缺陷收敛趋势 | 系统 | 连续回归轮次的新增与修复对比 | 新增连续两轮下降 |
| 需求覆盖率 | 系统、验收 | 已覆盖需求/范围内需求 | 100% |
| 代码覆盖率 | 单元、集成 | 行覆盖与分支覆盖分别统计 | 行≥80%，分支≥70% |
阈值设定依据主要有三类：历史基线，即同类项目过往版本的实测水平；风险等级，面向核心交易或安全相关模块的阈值应更严；发布类型，紧急修复版本与常规迭代版本的退出要求可以不同，但差异要事先写明，不能在判定时临时放宽。
制定与执行步骤：从草案到生效
准则从草案到生效需要经过五个步骤，每步都有明确的输入、动作、输出和完成标志。
步骤一：梳理测试层级与阶段划分。输入是测试策略与项目计划。动作是确认本项目涉及哪些测试层级、各阶段的起止时间和交付对象。输出是层级清单与阶段边界说明。完成标志是每个层级都有对应的责任团队和判定时点。
步骤二：选取指标并设定阈值。输入是历史缺陷数据、过往版本的执行记录和本轮风险评级。动作是按层级挑选指标，逐条写出统计口径、数据来源和阈值，并标注硬性或软性。输出是指标阈值草案。完成标志是每条准则都能用现有记录直接算出结果，不存在需要人工估算的指标。
步骤三：评审并确认判定权与例外流程。输入是草案和角色清单。动作是组织测试、开发、产品、质量管理方评审，确认每个层级的判定人和复核人，约定带条件退出的审批路径和记录方式。输出是评审通过的准则文档和例外流程说明。完成标志是所有相关角色对判定权无异议，例外路径有明确审批人。
步骤四：在测试计划中固化并执行判定。输入是生效的准则文档。动作是把准则条目写入测试计划，在阶段结束前按口径取数、逐条比对，形成判定结论。输出是退出判定记录。完成标志是每条硬性条件都有对应的证据，软性条件有评估意见。
步骤五：归档判定证据并复盘阈值合理性。输入是判定记录和本轮实际数据。动作是把证据、例外审批和结论归档，版本结束后回看哪些阈值过松或过严。输出是归档记录和阈值调整建议。完成标志是下一轮准则修订有据可依。
这些步骤中的取数、比对和留痕如果靠手工表格维护，容易出现口径不一致。ONES 测试管理支持测试计划与迭代关联、用例分配执行人，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转，测试报告可自动生成并支持自定义模板。团队可以把执行记录、缺陷状态和报告作为退出判定的证据来源，减少判定时反复核对数据的工作。是否内置退出准则模板或审批流，需要在选型时单独确认。
角色分工与交付物：谁定、谁判、谁复核
判定权模糊是退出准则失效的常见原因。各角色在制定与执行中的职责和产出如下：
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 测试负责人 | 起草准则、组织评审、汇总判定证据、提出退出建议 | 准则文档、测试报告、判定证据清单 |
| 开发负责人 | 确认缺陷修复状态、评估遗留缺陷的技术风险 | 缺陷修复说明、遗留缺陷风险评估 |
| 产品/业务负责人 | 确认业务影响、决定是否接受带条件退出 | 风险接受记录、带条件退出审批 |
| 质量或项目管理者 | 复核统计口径与流程合规、审批例外 | 复核意见、例外审批记录 |
分工的基本原则是：起草与判定可以由测试负责人承担，但复核必须由不直接负责该阶段执行的角色完成，避免自评自判。带条件退出的决定权应落在能承担业务风险的产品或业务负责人身上，测试负责人提供证据和风险说明，不单独决定放行。所有审批记录与判定结论一并归档，作为后续复盘和审计的依据。
示例：一个系统测试阶段的退出判定
以下为演示情景，数值均为示意值，不对应任何真实项目。
某版本进入系统测试收尾，范围为本轮迭代的全部功能需求。判定日取数结果：计划用例200条，已执行200条，执行率100%；通过188条，阻塞0条，通过率94%；致命和严重遗留缺陷0个；一般遗留缺陷7个，其中5个有修复计划、2个待排期；需求覆盖率100%；连续两轮回归新增缺陷从12个降至5个。软性条件中，一般遗留缺陷数量超过约定的5个上限。
逐项对照：执行率、致命与严重缺陷清零、需求覆盖率三项硬性条件满足；通过率94%低于95%的硬性阈值，一般遗留缺陷数量也超出软性上限。此时不能直接判定通过。处理路径有两条：一是延期一轮回归，补齐未通过用例的修复验证；二是走带条件退出，由测试负责人提交风险说明，产品负责人确认剩余缺陷不影响核心业务场景并签字接受，质量管理者复核口径无误后记录例外。若选择带条件退出，判定结论应写明放行范围、遗留缺陷清单、修复时限和责任人。
判定证据清单包括：测试计划执行记录、缺陷列表及严重等级分布、回归轮次的新增与修复对比、覆盖率统计、例外审批记录。证据齐全且口径一致，判定结论才站得住。
完成检查：准则可用性的自查清单
准则定稿前，用以下清单逐项核对，每项都有明确的通过标准：
| 检查项 | 通过标准 |
|---|---|
| 每条准则是否可量化、可取证 | 能直接算出数值，且证据有指定存放位置 |
| 统计口径与数据来源是否唯一 | 同一指标只有一种算法，换人计算得到相同结果 |
| 判定人与复核人是否明确到角色 | 每个层级都有判定角色和独立复核角色，无空缺 |
| 例外与带条件退出是否有审批路径 | 写明审批人、记录形式和放行范围 |
| 硬性与软性条件是否分开标注 | 每条准则标明必须满足或可评估 |
| 阈值是否与风险等级匹配 | 高风险模块的阈值不低于常规模块 |
| 是否安排定期回看 | 版本或阶段结束后有阈值合理性复盘动作 |
清单全部通过，说明准则具备可执行性；存在“待定”“视情况”之类表述的条目，应在评审阶段补齐，否则会在判定现场变成争议点。
常见问题
紧急修复版本可以沿用常规迭代的退出阈值吗？
可以沿用框架，但阈值差异要事先写明。紧急修复版本通常范围小、时间紧，团队可能放宽一般缺陷数量或覆盖率要求，同时保持致命与严重缺陷清零、关键用例全部通过等硬性条件不变。关键是差异在准则定稿时就写清楚，并注明适用条件，避免在判定现场临时放宽口径。
通过率达标但缺陷收敛趋势不好，应该退出吗？
建议暂缓判定。通过率反映已执行用例的结果，缺陷收敛趋势反映质量是否趋于稳定。如果连续回归中新增缺陷仍高位波动，说明修复可能引入新问题或测试范围尚未稳定。此时可以延长一轮回归观察趋势，或由判定人组织风险评审，把趋势数据作为带条件退出的评估依据之一。
带条件退出后，遗留缺陷由谁跟踪闭环？
带条件退出的审批记录中应写明遗留缺陷清单、修复时限和责任人。通常由开发负责人安排修复，测试负责人在后续回归中验证关闭，产品负责人确认修复结果不影响已放行的业务场景。质量或项目管理者在复盘时核对清单是否按期闭环，避免带条件退出变成事实上的无期限延期。
不同测试层级的判定人可以由同一人承担吗？
起草和判定可以由测试负责人统一承担，但复核角色需要独立。单元测试与集成测试的判定往往由开发团队内部完成，系统测试与验收测试由测试负责人判定，复核交给不直接负责该阶段执行的质量或项目管理者。层级越多，越要避免同一人既执行又复核，否则例外记录容易流于形式。
退出准则定好后多久需要修订一次？
建议每个版本或阶段结束后回看一次阈值合理性，至少在每个发布周期复盘时检查。触发修订的常见情形包括：连续多个版本某项阈值从未构成约束、遗留缺陷反复超出上限、发布类型或风险等级发生变化。修订要经过与原准则相同的评审流程，保留版本记录，避免口径在判定中途变更。
