提测准入检查要回答一个具体问题：这次提测是否具备进入测试的条件。依据可以归为四类：需求与范围材料、开发完成材料、环境与数据材料、团队约定的质量门槛。检查时先确认范围和标准，再核对交付物，最后用冒烟验证收口，并把结论与例外审批记录下来。下文给出可判定的门槛项、分步操作、角色分工和一份填写示例。
要点总览（TL;DR）
- 提测准入检查的依据分四类：需求与范围材料、开发完成材料、环境与数据材料、团队约定的质量门槛，缺一类结论就缺少支撑。
- 判定顺序固定为三步：先核对范围与标准，再核对交付物，最后做冒烟验证；前一步不成立时不必进入下一步。
- 门槛项要写成可判定字段，每项明确判定条件、判定方式和数据来源，如冒烟用例通过率、阻断级缺陷数、构建可部署、接口文档更新。
- 结论分通过、有条件通过、退回三种，例外项需产品审批，退回项要约定复提时间与责任人，全部写入检查记录。
- 检查结束后用自查条目核对依据是否齐全、结论是否留痕、记录能否按版本追溯，反复不符合的门槛项应回头调整标准或上游准备方式。
提测准入检查的核心依据与判定顺序
准入检查的依据需要同时覆盖“做什么、做完了没有、在哪里测、达到什么标准”四个问题。缺少任何一类，检查结论都会缺少支撑：只看开发说“已完成”，无法判断范围是否齐全；只看冒烟结果，无法解释哪些需求本次不测。
| 依据类别 | 包含材料 | 回答的问题 | 常见提供方 |
|---|---|---|---|
| 需求与范围 | 已评审通过的需求说明、验收标准、本次提测范围清单、不测项说明 | 这次要验证什么，哪些不在本次范围 | 产品、开发 |
| 开发完成 | 代码合并记录、构建记录、自测记录、单元测试结果、已知问题清单 | 功能是否开发完毕，遗留问题是否已说明 | 开发 |
| 环境与数据 | 提测版本号、部署环境地址、数据库变更说明、配置项变更、测试数据准备情况 | 在哪个版本、哪个环境验证，数据是否可用 | 开发、运维、测试 |
| 质量门槛 | 团队事先约定的准入标准，如冒烟用例通过率、阻断级缺陷清零、接口文档更新 | 达到什么条件才允许进入测试 | 测试与开发共同确认 |
判定顺序建议固定为三步。第一步核对范围与标准：确认提测范围清单与需求、验收标准一致，确认本次适用的准入标准已经双方确认。第二步核对交付物：逐项检查开发完成材料与环境数据材料是否齐全、内容是否与提测版本对应。第三步做冒烟验证：在目标环境部署提测版本，执行约定的冒烟用例，记录通过情况。顺序固定的好处是，前一步不成立时不必进入下一步，减少无效验证。
准入标准应在提测前由测试与开发共同确认，而不是在检查现场临时讨论。标准确认的时间点可以放在迭代计划或需求评审之后，形成书面约定，后续检查直接引用。
准入标准怎么定：可判定的门槛项与字段
“开发完成”这类表述无法直接核对，需要拆成可以勾选、可以查到数据来源的门槛项。每个门槛项至少写清三件事：判定条件、判定方式、数据来源。下表给出一组常用门槛项，团队可按项目实际增删。
| 门槛项 | 判定条件示例 | 判定方式 | 数据来源 |
|---|---|---|---|
| 冒烟用例通过率 | 约定的冒烟用例全部执行，通过率达到团队设定值 | 执行冒烟用例并统计结果 | 测试用例执行记录 |
| 阻断级缺陷数 | 阻断级、严重级未关闭缺陷数为零，或有明确处理结论 | 查询缺陷列表并按等级筛选 | 缺陷跟踪记录 |
| 构建可部署 | 提测版本构建成功，能在目标环境完成部署并启动 | 实际部署一次并确认服务可用 | 构建记录、部署记录 |
| 接口文档更新 | 本次涉及的接口变更已同步到接口文档，字段与实现一致 | 对照变更清单抽查接口文档 | 接口文档、变更说明 |
| 数据库变更说明 | 涉及表结构或数据变更的脚本已提供，并在测试环境执行成功 | 核对脚本与执行记录 | 变更脚本、执行日志 |
| 自测记录 | 开发按自测清单完成主要路径验证，记录结果与遗留问题 | 查看自测记录完整性 | 自测记录、已知问题清单 |
门槛项要随项目阶段调整。版本初期可以侧重构建可部署与主流程自测；临近发布阶段的提测，应提高冒烟通过率要求并收紧阻断缺陷条件；紧急修复类提测可以缩减范围，但需要把缩减内容写入例外审批。调整原则是：门槛变化有书面记录，且测试与开发都知情。
提测准入检查的操作步骤
下面按一次完整提测走一遍流程，每步说明输入、动作、输出和完成标志。
第一步：提交提测申请
输入是开发完成的功能与本次范围。动作是开发提交提测申请，内容至少包括：提测版本号与构建标识、部署环境、本次提测范围清单及对应需求编号、不测项说明、自测记录、已知问题清单、数据库与配置变更说明、接口文档更新情况。输出是一份可被测试核对的提测说明。完成标志是测试确认收到申请且材料清单不缺项。
第二步：核对依据
输入是提测说明与团队约定的准入标准。动作是测试按“范围与标准—交付物—环境数据”的顺序逐项核对，每项记录“符合、不符合、不适用”，不符合项写明原因。输出是检查记录表。完成标志是所有门槛项都有结论，没有空白项。
第三步：冒烟验证
输入是部署完成的提测版本与约定的冒烟用例。动作是在目标环境执行冒烟用例，记录每条用例的执行结果，失败项登记为缺陷并标注等级。输出是冒烟结果与缺陷记录。完成标志是冒烟用例执行完毕，结果可统计。
第四步：给出结论并处理
结论分三种。通过：所有门槛项符合，冒烟达到约定要求，进入正式测试。有条件通过：存在不影响主流程的问题或已审批的例外项，列明限制条件和补齐时间，进入测试但相关范围暂缓验证。退回：存在阻断级问题、构建不可部署或关键依据缺失，退回开发并约定复提时间与责任人。三种结论都要写入检查记录，退回项还要同步到提测单状态。
在工具承载上，提测申请、检查记录和结论可以放在同一工作项下流转。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，检查记录中的范围清单和冒烟用例可以对应到具体需求与用例；未通过的用例可快速创建缺陷任务，在测试与研发团队间流转。准入结论与例外审批作为记录留存，便于后续追溯本次提测依据了哪些材料。
角色分工与交付物
准入检查涉及三个角色，各自产出不同材料，交界处的确认动作要明确。
| 角色 | 主要职责 | 交付物 | 交接确认 |
|---|---|---|---|
| 开发 | 完成开发与自测，准备提测材料，处理退回项 | 提测说明、自测记录、已知问题清单、变更说明、构建与部署记录 | 提测申请提交后确认材料齐全 |
| 测试 | 核对依据、执行冒烟、给出准入结论、维护检查记录 | 检查记录表、冒烟结果、准入结论、缺陷记录 | 结论发出后确认开发已知悉 |
| 产品 | 确认需求与验收标准，审批范围缩减与例外项 | 需求与验收标准确认记录、例外审批记录 | 例外审批在结论发出前完成 |
分工中容易模糊的是例外审批。范围缩减、门槛放宽、已知问题带病提测，都应由产品确认业务影响，测试记录审批结论。开发负责在约定时间内补齐，测试在复提时核对补齐情况。
示例：一次提测准入检查的记录
以下为演示情景，用于说明记录如何填写，不代表真实项目数据。
| 记录项 | 填写内容 |
|---|---|
| 提测版本与范围 | 版本 V2.4.0，构建号 20240612-03；范围包括订单查询改版、导出功能优化，共关联需求 6 项；支付流程本次不测，已在范围清单注明 |
| 需求与范围依据 | 需求说明与验收标准已评审通过；范围清单与需求编号一致，符合 |
| 开发完成依据 | 代码合并记录与构建记录齐全；自测记录覆盖主流程；单元测试结果已附；已知问题清单列 2 项一般问题，符合 |
| 环境与数据依据 | 测试环境部署成功，服务可访问；数据库变更脚本已在测试环境执行；测试数据已准备，符合 |
| 质量门槛核对 | 冒烟用例 32 条，执行 32 条，通过 30 条，通过率未达约定值；阻断级缺陷 0 个；接口文档已更新；构建可部署 |
| 未通过项 | 冒烟失败 2 条，均为导出功能字段显示问题，登记为一般缺陷，已创建缺陷任务 |
| 例外审批 | 导出功能相关范围暂缓验证，产品确认可先测订单查询部分，审批记录附在检查记录中 |
| 结论与复提约定 | 有条件通过；导出功能缺陷修复后由开发通知测试复验，责任人：开发负责人；复验通过后恢复该范围验证 |
这份记录的价值在于：结论有依据，例外有审批，未通过项有责任人和后续动作。复提时不需要重新讨论背景，直接对照记录核对即可。
完成检查：准入记录是否合格
检查结束后，用下面这组条目自查本次准入检查是否做完整。每条都应有明确答案，答“否”的条目需要补做或说明原因。
- 四类依据是否齐全：需求与范围、开发完成、环境与数据、质量门槛，每类都有对应材料。
- 每个门槛项是否都有结论：符合、不符合或不适用，没有空白项。
- 冒烟用例是否执行完毕并记录结果，失败项是否登记为缺陷并标注等级。
- 结论是否明确为通过、有条件通过或退回，并写入检查记录。
- 例外项是否经过产品审批，审批记录是否与检查记录放在一起。
- 退回项或有条件通过的限制项，是否约定复提时间与责任人。
- 检查记录是否与提测版本号、需求编号、用例和缺陷关联，后续能否按版本追溯。
- 本次适用的准入标准是否有书面版本，与上次检查相比的调整是否有记录。
这组条目同时可以作为流程改进的输入：如果多次检查都在同一门槛项上出现不符合，说明该门槛的设定或上游准备方式需要调整，而不是在每次检查时重复放行。
常见问题
提测准入标准应该在什么时间点确认，由谁拍板？
准入标准建议在提测之前确认，时间点可以放在迭代计划或需求评审之后，由测试与开发共同确认并形成书面约定，后续检查直接引用。产品参与需求与验收标准的确认，并对范围缩减、门槛放宽等例外项做审批。把标准讨论放到检查现场，容易出现临时放宽或反复争论，检查记录也缺少可对照的依据。
紧急修复类提测能否简化准入检查？
可以缩减检查范围，但缩减内容要写入例外审批。常见做法是保留构建可部署、主流程冒烟和阻断级缺陷核对，暂缓与本次修复无关的范围验证，并在记录中注明暂缓项和补齐时间。缩减不等于不记录：结论、审批人、复验责任人都要落到检查记录里，复提或复验时对照记录核对。
冒烟用例通过率没达到约定值，是否一定退回？
不一定，要看失败项的性质和影响范围。失败集中在非主流程、可登记为一般缺陷且不影响本次核心范围验证时，可以走有条件通过，列明限制条件和补齐时间；失败涉及主流程、构建不可部署或关键依据缺失时，应退回开发并约定复提时间。无论哪种结论，失败用例都应登记为缺陷并标注等级，结论写入检查记录。
检查记录需要关联哪些对象，后续才能按版本追溯？
记录至少要关联提测版本号与构建标识、本次范围对应的需求编号、执行的冒烟用例以及登记出的缺陷。这样复提或复验时可以直接按版本查到当时依据了哪些材料、哪些项不符合、例外由谁审批。使用 ONES 测试管理时，测试用例可与需求、任务关联，测试计划与迭代关联，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转，准入结论与审批记录随工作项留存。
同一门槛项在多次检查中反复不符合，应该怎么处理？
先区分是执行问题还是标准问题。如果是开发侧准备不足，明确补齐动作和责任人；如果多次检查都卡在同一项，说明该门槛的设定或上游准备方式需要调整，例如判定口径不清、数据来源拿不到、标准与当前项目阶段不匹配。调整后要有书面记录并同步测试与开发，避免每次检查重复放行同一问题。
