提测清单和提测准入检查常被写在同一份交接规范里，内容却容易重叠或留下缺口。两者的关系可以概括为：提测清单负责完整、可核对地说明“这次交了什么、怎么验证”，提测准入检查负责依据这些信息判定“能不能开始测试”。划分边界时，把事实陈述留在清单，把判定结论放进准入检查，同一批条目不在两处重复罗列。
要点总览（TL;DR）
- 提测清单是开发方交付提测内容时逐项列明的交付物与说明，回答“这次交了什么、怎么验证”；提测准入检查是测试方按预设门槛判定“能不能开始测试”。
- 边界划分原则：清单承载可核对的事实，准入检查承载基于事实的判定；同一信息在清单中是事实陈述，在准入检查中是判定依据，两处不重复罗列。
- 准入检查由门槛条目、判定结论、责任分工与留痕组成，门槛条目从清单信息中提炼，判定分通过、有条件通过、退回三档。
- 常见误解包括把握准入条目抄进清单、清单只写“已自测”缺少可核对信息、准入检查变成测试方单方面补做验证，规范中应逐条明确。
- 提测清单与测试用例评审、准入检查与冒烟测试分别处理不同对象和阶段，规范中应写清先后顺序与职责归属。
提测清单与提测准入检查分别是什么
提测清单是开发方向测试方交付提测内容时逐项列明的交付物与说明。它回答的是“本次提测包含哪些内容、这些内容如何验证”。清单的读者是接收提测的测试人员，写作要求是完整、具体、可核对，让测试方不依赖口头沟通就能了解本次交付的全貌。
提测准入检查是测试方在接收提测时，按事先约定的门槛逐项判定是否达到可开始测试的条件。它回答的是“这次提测能不能进入测试执行”。准入检查的判定主体是测试方，判定对象是清单所载的信息，判定结果是明确的结论，例如通过、有条件通过或退回。
在提测交接的流程中，两者有先后位置。开发方先提交提测清单，测试方再依据清单开展准入检查。清单在前，是输入；准入检查在后，是使用。这个顺序决定了内容归属：清单阶段只陈述事实，判定留到准入检查阶段完成。如果顺序颠倒，测试方在信息不全时就做判定，结论容易失真；如果两者混写，清单里出现判定语，准入检查里又重复罗列交付物，规范就会臃肿且难以维护。
两者的边界：清单管交付信息，准入检查管判定
边界划分可以归纳为一条原则：清单承载可核对的事实，准入检查承载基于事实的判定。同一项信息在清单中以事实陈述的形式出现，在准入检查中以判定依据的形式被引用，两处角色不同，内容不重复。
提测清单的内容边界包括：本次交付的功能或修改点、变更说明、开发自测情况、测试环境与数据准备情况、影响范围与关联模块、已知问题与限制条件、验证入口与操作说明。这些内容的共同特征是可以被核对——测试方拿到清单后，能逐项确认“有没有、是不是这样”。清单不写“是否达到提测标准”这类结论，也不写“建议通过”这类判断。
提测准入检查的内容边界包括：门槛条目、判定结论、判定责任人与处理方式。门槛条目是从清单信息中提炼出的可判定条件，例如“自测用例是否全部执行完毕”“环境是否可访问”“已知问题是否已说明影响范围”。判定结论是对每个门槛给出的通过、有条件通过或退回。处理方式规定不同结论对应的后续动作，例如退回时由谁补充什么信息、有条件通过时哪些范围先测哪些后测。
下表对照两类内容的归属，便于在规范中直接使用：
| 信息项 | 提测清单中的形态 | 提测准入检查中的形态 |
|---|---|---|
| 变更范围 | 列明本次修改的模块与功能点 | 判定“变更范围是否已说明清楚” |
| 自测情况 | 写明自测用例数量、执行结果、未覆盖项 | 判定“自测是否达到约定门槛” |
| 测试环境 | 给出环境地址、版本、数据准备说明 | 判定“环境是否可访问、版本是否匹配” |
| 已知问题 | 列出已知缺陷及其影响范围 | 判定“已知问题是否影响本轮测试开展” |
| 判定结论 | 不出现 | 通过、有条件通过或退回 |
| 处理动作 | 不出现 | 退回补件、限定范围先测、升级协调 |
只属于清单的内容是那些描述交付事实的条目，它们本身不构成门槛，但为准入判定提供依据。只属于准入检查的内容是判定结论与处理动作，它们依赖清单信息才能成立，单独存在没有意义。规范制定时按这张对照表检查，可以避免两类材料互相抄写。
提测准入检查由哪些部分组成
准入检查的条目来源是清单信息。制定规范时，从清单的每一类信息中提炼出可判定的条件，形成门槛条目。提炼的标准是：该条件能用“是/否”或明确等级回答，且回答结果会影响是否开始测试。例如清单中“自测情况”是事实描述，提炼出的门槛可以是“核心功能自测用例执行率是否达到约定比例”。门槛条目数量宜少而关键，覆盖范围、质量、环境三类即可，条目过多会让判定流于形式。
判定方式通常分三档。通过表示所有门槛满足，测试方按计划开始执行；有条件通过表示主要门槛满足、个别条件受限，测试方在限定范围内先开展测试，同时约定补齐时间；退回表示关键门槛未满足，测试方不启动执行，由开发方补充后重新提交。三档的适用条件应在规范中写清楚，避免每次交接临时协商。
角色分工上，开发方负责提交清单并对信息真实性负责，测试方负责判定并对结论负责，出现分歧时按约定升级到双方负责人协调。判定记录需要留痕，保存判定结论、判定依据、判定人和时间，便于后续追溯“当时为什么放行”或“为什么退回”。留痕的价值在争议出现时体现：有记录才能复盘是信息缺失还是判定偏差。
在工具层面，提测交接涉及工作项状态流转和清单留痕。ONES 的工作项与文档能力可以承载这类管理动作：开发方在提测工作项中填写清单信息并流转状态，测试方在同一工作项上记录准入判定结论与依据，判定结果随工作项留痕，后续查看提测历史时能同时看到交付信息与接收结论。这一衔接适合已经用工作项管理研发流程的团队；若团队以文档为主要载体，用文档模板加评审记录同样能实现边界划分。
容易混淆的相邻概念：提测清单、准入检查与测试用例评审
提测清单与测试用例评审的区别在于对象不同。提测清单处理的是开发方交付了什么，属于交付信息；测试用例评审处理的是测试方的用例设计是否覆盖需求、步骤是否可执行，属于测试设计质量把关。两者可能在同一时间段发生，但一个针对开发交付物，一个针对测试设计产物，内容不应混写。把用例评审意见写进提测清单，会让清单承担它无法回答的问题。
准入检查与冒烟测试的区别在于阶段不同。准入检查是接收判定，发生在测试执行之前，依据是清单信息，产出是能否开始的结论；冒烟测试是接收后的初步验证，通过实际执行少量关键用例确认系统基本可用。准入检查通过不等于冒烟测试通过，冒烟测试发现问题时应回到缺陷流程处理，而不是倒推修改准入结论。规范中应明确两者的先后：先准入判定，再冒烟验证。
缺陷修复闭环与验证跟踪、测试报告与质量评估不属于本文边界。前者处理提测之后发现问题的修复与回归，后者处理测试结束后的结果汇总与质量判断。它们与提测交接相邻，但回答的问题不同，本文只界定提测环节内清单与准入检查的分工。
一个提测交接的例子与常见误解
假设一个订单模块完成一轮修改后提测。开发方提交的清单条目包括：本次修改了订单取消与退款申请两个功能点；自测执行用例 32 条，通过 30 条，2 条因依赖外部支付沙箱未执行；测试环境地址与版本号已更新；已知问题为退款申请在并发场景下偶发超时，影响范围限于批量操作；验证入口为订单详情页与退款管理页。这些条目都是事实陈述，测试方可以逐项核对。
测试方据此开展准入检查：变更范围是否说明清楚——是；自测执行率与未执行项是否已说明——是，但 2 条未执行需确认是否影响本轮范围；环境是否可访问、版本是否匹配——是；已知问题是否影响本轮测试——偶发超时限于批量操作，可先测单笔流程。综合判定为有条件通过：单笔取消与退款流程先测，批量场景待沙箱可用后补充，约定补齐时间。判定结论与依据记录在提测工作项上。这个例子中，清单没有出现“准予测试”字样，准入检查也没有重新罗列功能点，边界清晰。
常见误解之一是把握准入条目直接抄进清单，造成同一批内容在两份材料中重复维护，改一处漏一处。正确做法是清单只写事实，准入条目在规范中单独维护，判定时引用清单信息。
常见误解之二是清单只写“已自测”，缺少可核对的信息。这样的清单无法支撑准入判定，测试方只能退回或自行补做验证。清单应写明自测范围、用例数量、执行结果和未覆盖项，让判定有据可依。
常见误解之三是准入检查变成测试方单方面补做验证。准入检查是依据清单信息做判定，验证责任在开发方；测试方发现信息缺失时应退回补充，而不是替开发方完成自测或环境准备。把这条写进规范，能减少交接阶段的职责模糊。
常见问题
提测清单和提测准入检查可以合并成一份材料吗？
可以放在同一份交接规范中，但内容应分栏维护。清单部分只写事实，例如变更范围、自测情况、环境信息；准入部分只写门槛条目与判定结论。合并成一份材料时，建议用表格区分“清单信息”与“判定结论”两列，避免同一批条目在两处重复维护。若团队规模较小、交接频率不高，一份规范加一张判定表即可满足需要；交接频繁时，分开维护更便于各自更新。
开发方自测未全部执行时，准入检查应该直接退回吗？
不一定。是否退回取决于未执行项是否影响本轮测试范围。规范中可以约定：未执行项已说明原因且不影响核心流程时，判定为有条件通过，先测已覆盖范围，同时约定补齐时间；未执行项涉及核心功能或无法评估影响时，判定为退回，由开发方补充后重新提交。判定依据应记录在案，便于后续复盘。
准入检查通过后冒烟测试发现问题，应该修改准入结论吗？
不需要修改准入结论。准入检查是接收判定，依据是清单信息；冒烟测试是接收后的初步验证，通过实际执行确认系统基本可用。两者阶段不同，冒烟测试发现问题应进入缺陷流程处理，并记录问题与准入判定之间的差异，用于后续优化门槛条目。把冒烟结果倒推修改准入结论，会让判定记录失去追溯价值。
提测清单里需要写测试建议或测试重点吗？
可以写，但应作为事实性说明而非判定。例如“本次修改集中在退款申请，建议重点关注并发场景”，属于开发方对影响范围的说明，测试方可以据此安排测试重点。清单中不宜出现“建议准予通过”这类判定语，判定结论统一放在准入检查中，保持两份材料的角色清晰。
团队刚开始制定提测规范，门槛条目应该设多少条？
建议先覆盖范围、质量、环境三类，每类保留少量关键条目，例如变更范围是否说明、自测执行情况是否可核对、环境是否可访问。条目数量宜少而关键，判定才能落到实处；条目过多容易流于形式，反而增加交接成本。规范运行一段时间后，可根据退回原因和冒烟测试结果补充或调整条目。
