制定测试准入准则，关键是把“可以开始测试”从口头判断变成一组可核验的条件：先明确各测试阶段的准入对象与责任人，再为每类条件定义证据、判定方式和例外处理，最后嵌入提测流程与评审节点。本文给出准入准则的字段框架、分阶段条件、制定步骤、角色分工与完成检查清单，并说明如何借助ONES把条件落到需求、任务与测试工作项的状态和检查项上。
要点总览（TL;DR）
- 准入准则的最小结构是六个字段：适用阶段、条件、判定标准、证据、责任人、例外处理；条件本身归为需求与设计基线、代码与构建状态、环境与数据、缺陷收敛、可测性与文档五类。
- 单元、集成、系统、验收四个阶段的准入对象不同，条件应逐级递进：前序阶段已确认且未变化的条件直接引用结论，发生变化的条件重新检查，避免所有阶段套用同一套条件。
- 制定过程分五步：梳理提测问题与返工原因、起草条件并定义判定方式与证据、评审定稿发布、嵌入提测流程与工具节点、试点校准阈值。
- 测试负责人牵头起草与执行检查，开发、产品/需求负责人提供证据，项目经理协调例外审批；检查人与例外批准人分开，例外记录包含风险、补偿措施与复盘要求。
- 准则可用与否看九项检查：判定标准一致、证据可追溯、硬性与可协商已区分、阶段匹配、责任到角色、例外路径清晰、已嵌入流程、完成试点校准、有版本与修订记录。
准入准则由哪些条件构成
一条可执行的准入准则，应当能回答四个问题：谁在什么阶段检查什么、依据什么证据判定、不满足时怎么办。把这四个问题拆成字段，就得到准入准则的最小结构。缺少任一字段，准则都容易退化为“开发说可以测了”这类主观判断。
建议每条准则至少包含以下字段：
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 适用阶段 | 明确该条件用于单元、集成、系统还是验收测试 | 系统测试 |
| 条件 | 一句话描述需要满足的状态 | 本轮构建通过冒烟用例 |
| 判定标准 | 可客观判定的阈值或状态，避免“基本完成”这类表述 | 冒烟用例通过率100%，无阻断级缺陷 |
| 证据 | 检查时可查看、可留存的材料 | 冒烟测试报告、构建记录 |
| 责任人 | 负责检查并给出结论的人 | 测试负责人 |
| 例外处理 | 不满足时的处理路径与批准人 | 由项目经理批准，记录风险与补偿测试 |
在字段之上，条件本身可以归为五类，覆盖从需求到可测性的完整链条：
- 需求与设计基线：需求已评审通过并形成基线，验收标准明确，设计文档覆盖本次变更范围。
- 代码与构建状态：代码已合入指定分支，构建成功且版本可追溯，冒烟用例通过。
- 环境与数据：测试环境可用且版本与目标一致，测试数据准备就绪，依赖的外部服务可访问。
- 缺陷收敛：上一轮遗留的阻断级、严重级缺陷已关闭或已评估，新增缺陷趋势可控。
- 可测性与文档：接口说明、部署说明、变更说明齐备，日志与配置可获取，测试所需入口已开放。
这五类条件还需要区分硬性阻断与可协商两类。硬性阻断条件不满足时不得进入测试，例如构建失败、核心环境不可用、存在未评估的阻断级缺陷；可协商条件允许在记录风险后带条件进入，例如部分边缘场景数据未就绪、非核心文档待补。区分标准应写进准则本身，避免每次检查时临时争论。
按测试阶段拆分准入条件
不同测试阶段的准入对象不同，条件不能整套照搬。单元测试关注代码提交本身，集成测试关注接口与模块联调，系统测试关注完整构建与端到端环境，验收测试关注业务可用性与用户场景。阶段越往后，条件越依赖前序阶段的产出，形成递进关系。
| 测试阶段 | 准入对象 | 典型准入条件 | 与前序阶段的承接 |
|---|---|---|---|
| 单元测试 | 单次代码提交或合并请求 | 代码通过静态检查，单元用例随代码提交，构建成功 | 无前序依赖，是后续阶段的基础 |
| 集成测试 | 多个模块或服务的联调版本 | 接口契约确认，联调环境可用，依赖服务已部署对应版本 | 复用单元阶段的构建通过结论 |
| 系统测试 | 完整构建的待测版本 | 冒烟通过，需求基线冻结，环境与数据就绪，遗留缺陷已评估 | 承接集成阶段接口验证结论 |
| 验收测试 | 面向业务场景的候选版本 | 系统测试主要用例通过，严重缺陷清零或有批准例外，验收场景与数据准备完成 | 承接系统测试的缺陷收敛结论 |
递进与复用的处理方式是：前序阶段已确认且未发生变化的条件可以直接引用结论，例如构建版本号、需求基线版本；发生变化的条件需要重新检查，例如环境升级、需求变更后需重新确认验收标准。这样既避免重复劳动，也防止用旧结论掩盖新风险。
需要避免的做法是所有阶段套用同一套条件。单元测试阶段要求完整环境与验收数据并不现实，验收阶段只检查代码提交状态也无法支撑业务判断。阶段化配置的意义在于让每个阶段的检查成本与风险相匹配。
制定步骤：从梳理到定稿
制定准入准则是一个从现状问题出发、逐步收敛为可执行条款的过程。以下步骤给出每步的输入、动作、输出与完成标志，团队可按规模裁剪，但建议保留梳理问题与试点校准两个环节。
第一步：梳理现有提测问题与返工原因
输入为近几个迭代的提测记录、缺陷单、返工记录和测试阻塞记录。动作是归类问题来源，例如构建失败、环境不可用、需求不清、缺陷未收敛、文档缺失，统计各类问题出现的频次与影响。输出是一份问题分类清单。完成标志是每类问题都有具体案例支撑，而非凭印象罗列。
第二步：起草条件并逐条定义判定方式与证据
输入是第一步的问题清单和现有测试流程说明。动作是针对高频问题起草条件，按前述字段逐条填写判定标准、证据、责任人和例外处理，并标注硬性或可协商。输出是准则初稿。完成标志是每条条件都能指出由谁、看什么材料、按什么标准判定。
第三步：评审定稿与发布
输入是准则初稿。动作是组织测试、开发、产品与项目管理人员评审，重点确认判定标准是否可操作、例外路径是否清晰、责任是否落到具体角色。输出是评审通过的正式版本。完成标志是各方对硬性条件与例外审批人无异议，版本号与生效日期明确。
第四步：嵌入提测流程与工具节点
输入是正式准则。动作是把条件对应到提测单、评审节点或工作项状态上，使检查动作在流程中发生，而不是事后补记录。输出是带检查项的提测流程。完成标志是提测时系统或流程能提示未满足的条件，检查结论可留存。
在工具承载上，ONES可以把准入条件落到需求、任务与测试工作项的状态和检查项中：提测单关联本轮构建与需求基线，检查项逐条勾选并附证据，未满足的硬性条件阻止状态流转，例外则通过审批记录保留风险说明。这样准则不再是一份独立文档，而是提测动作的一部分。
第五步：试点校准阈值
输入是新流程下的首轮或前两轮执行数据。动作是观察条件是否过严导致频繁例外、是否过松导致测试阻塞，调整阈值与硬性/可协商的划分。输出是校准后的准则版本。完成标志是例外比例与测试阻塞情况处于团队可接受范围，且调整有记录可追溯。
角色分工与交付物
准入准则的制定与执行涉及多个角色，职责不清会导致检查流于形式或例外随意放行。建议按下表明确分工，规模较小的团队可以合并角色，但检查与批准不宜由同一人完成。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 测试负责人 | 牵头起草准则，组织评审，执行准入检查并给出结论 | 准则初稿、检查记录、准入结论 |
| 开发负责人 | 确认代码与构建条件，提供构建记录与变更说明，处理不满足项 | 构建记录、变更说明、缺陷修复说明 |
| 产品/需求负责人 | 确认需求基线与验收标准，判断需求变更对准入的影响 | 需求基线版本、验收标准 |
| 项目经理 | 协调例外审批，跟踪未满足条件的处理进度 | 例外审批记录、风险说明、处理计划 |
例外审批的责任人应在准则中写明。常见做法是由项目经理批准可协商条件的例外，涉及范围或进度重大影响时升级至项目决策层；硬性阻断条件原则上不设例外，确需突破时须由测试负责人与项目经理共同确认并记录补偿措施。例外记录应包含未满足条件、风险描述、补偿测试安排和复盘要求。
示例：一个系统测试准入准则
以下示例展示系统测试阶段的准入准则如何填写为可检查条目，团队可参照结构调整为自身项目版本。
| 条件 | 判定标准 | 证据 | 类型 | 例外处理 |
|---|---|---|---|---|
| 需求基线冻结 | 本轮范围需求均已评审通过，变更已登记 | 需求基线版本号、变更记录 | 硬性 | 不适用 |
| 构建可用 | 待测版本构建成功，版本号可追溯 | 构建记录、版本清单 | 硬性 | 不适用 |
| 冒烟通过 | 冒烟用例通过率100%，无阻断级缺陷 | 冒烟测试报告 | 硬性 | 不适用 |
| 环境就绪 | 测试环境版本与待测版本一致，依赖服务可访问 | 环境检查记录 | 硬性 | 不适用 |
| 测试数据 | 核心业务场景数据可用，覆盖主要流程 | 数据准备清单 | 可协商 | 项目经理批准，记录缺失场景并安排补充 |
| 遗留缺陷 | 上一轮阻断级、严重级缺陷已关闭或已评估 | 缺陷列表与评估结论 | 可协商 | 项目经理批准，明确规避方案与回归安排 |
| 文档齐备 | 接口说明、部署说明、变更说明可获取 | 文档链接或附件 | 可协商 | 项目经理批准，约定补齐时间 |
示例中硬性条件集中在需求、构建、冒烟与环境四项，它们直接决定测试能否有效开展；可协商条件集中在数据、缺陷与文档，允许在风险可控时带条件进入。例外记录统一写入提测单，包含未满足项、批准人、风险说明与补偿安排，并在迭代复盘中回看例外是否集中出现在某类条件上，作为下一轮校准的依据。
完成检查：准则是否可用
准则定稿前，用以下清单逐项核对。任何一项无法给出肯定回答，都说明准则还需要补充或调整。
- 每条条件都有明确的判定标准，不同人按同一标准检查能得出一致结论。
- 每条条件都指明证据材料，且证据可以在提测流程中留存和追溯。
- 硬性条件与可协商条件已明确区分，划分理由可以解释。
- 每个阶段的条件与其准入对象匹配，没有直接套用其他阶段的条件。
- 责任人落到具体角色，检查人与例外批准人已分开。
- 例外处理路径清晰，记录包含风险、补偿措施与复盘要求。
- 准则已嵌入提测流程或工具节点，检查动作在流程中发生而非事后补录。
- 已完成至少一轮试点，并根据例外比例与测试阻塞情况校准过阈值。
- 准则有版本号与生效日期，变更时有修订记录。
把这套字段、分阶段条件、制定步骤与检查清单落地后，测试准入就从个人经验判断转变为团队可重复执行的机制。后续每个迭代只需回看例外记录与阻塞情况，对阈值做小幅校准，准则就能持续贴合项目实际。
常见问题
团队规模小、角色合并时，准入检查怎么保证不流于形式？
小团队可以合并起草与评审角色，但检查动作与例外批准建议保留分离：由一人执行准入检查并给出结论，另一人（如项目经理或技术负责人）批准可协商条件的例外。硬性阻断条件不满足时，检查人直接判定不进入测试，不需要额外审批。角色合并后，把“谁检查、谁批准”写进准则本身，并在提测单上留下检查人与批准人记录，避免同一人既检查又放行。
试点后发现例外比例过高，应该先放宽条件还是先改流程？
先看例外集中在哪类条件。如果集中在可协商条件（如测试数据、文档），说明阈值或准备节奏需要调整，可以放宽判定标准或提前准备时间；如果集中在硬性条件（如构建、冒烟、环境），说明提测前的工程动作没有做到位，应改流程而不是放宽准则。调整时保留原版本与修订记录，下一轮试点继续观察例外比例与测试阻塞情况，确认调整有效后再固化。
需求在测试过程中发生变更，已通过的准入结论还有效吗？
与变更范围相关的条件需要重新检查。需求基线版本变化后，需求与设计基线、验收标准相关的准入结论失效，应重新确认；构建、环境等条件如果未受影响，可以引用原结论。建议在准则中写明“变更触发重新检查”的规则，并在提测单上关联需求基线版本号，使变更发生时能快速定位哪些条件需要复核。
准入准则和提测单、测试计划是什么关系？
准入准则是规则层，定义每个阶段要满足什么条件、由谁检查、依据什么证据；提测单是执行载体，逐条承载检查项与结论；测试计划则安排本轮测试的范围、资源与进度。三者衔接的方式是把准则条件对应到提测单的检查项上，检查通过后再进入测试计划的执行环节。准则独立成文便于评审与修订，提测单只引用准则版本，避免两处内容不一致。
没有工具支撑时，准入检查如何留存证据？
可以用提测单模板承载检查项，每条条件对应一栏，填写判定结论并附证据链接或附件，例如构建记录、冒烟报告、环境检查记录、缺陷列表。例外单独记录未满足项、批准人、风险说明与补偿安排。关键是证据与条件一一对应、可追溯到具体版本，形式可以是文档或表格。后续引入工具时，再把检查项迁移到工作项状态与审批节点上，准则内容本身不需要重写。
