提测交接要把“开发认为可以测”变成“测试确认可以开始测”的一次正式交接。开发提交提测单，附上版本、范围、自测结果和已知风险；测试按准入清单核验；双方确认测试范围、环境、数据、时间窗口和问题反馈通道，最后留下可追溯的交接记录。本文按准入、流程、角色、示例和完成检查五步展开，提测单与交接记录可以在ONES工作项和文档中承载。
要点总览（TL;DR）
- 提测交接的核心动作是准入核验加交接确认：开发提交提测单并附版本、范围、自测结论和风险声明，测试按清单核验后再确认测试范围、环境、数据、时间窗口和反馈通道。
- 准入清单至少覆盖版本号、需求/缺陷清单、影响范围、自测结论、代码与构建状态、环境与数据、已知问题与风险七项，逐项有可核验的答案再提交。
- 交接按提交提测、准入核验、交接确认、打回与重提、记录归档五步推进，每步写明输入、动作、输出和完成标志，打回必须逐条写明原因。
- 开发、测试、测试负责人或项目经理各有明确交付物，交接确认记录要能按版本或需求反查到提交人、核验人、确认人和确认时间。
- 交接完成后用检查清单核对字段完整性、核验结论、范围确认、环境数据、时间窗口与记录可追溯性，并定期回看打回原因调整准入严格程度。
提测交接先定准入：开发提交前要满足什么
准入清单的作用，是让开发在点击“提测”之前完成一次自检，把明显不满足测试条件的问题挡在交接之前。清单不必很长，但每一项都要有可核验的答案，避免测试收到一个“先测着看”的版本。
下面这份清单可以直接作为提测单的必填结构，逐项勾选后再提交。
| 准入项 | 具体要求 | 核验方式 |
|---|---|---|
| 版本号 | 填写本次提测的版本号或构建号，与构建产物一一对应 | 对照构建记录或发布包命名 |
| 需求/缺陷清单 | 列出本次涉及的需求编号、缺陷编号及对应改动说明 | 与需求管理或缺陷列表逐条对照 |
| 影响范围 | 说明改动涉及的模块、接口、页面，以及可能受影响的关联功能 | 由开发填写，测试复核是否遗漏 |
| 自测结论 | 写明自测覆盖的主要场景、执行结果和未覆盖项 | 附自测记录或截图，测试抽查关键路径 |
| 代码与构建状态 | 分支已合入目标分支，构建可部署，版本可追溯 | 检查分支记录与构建产物 |
| 环境与数据 | 测试环境可用，必要的基础数据、账号、配置已就绪 | 测试在接收前实际访问确认 |
| 已知问题与风险 | 声明遗留缺陷、未完成项、临时规避方案及其影响 | 逐条记录，作为测试范围确认的输入 |
其中“已知问题与风险”最容易被省略。开发如果知道某个功能只完成了一半，或某个缺陷暂时用开关规避，应在提测单里写清楚，测试据此决定是否纳入本轮范围、是否需要单独验证规避方案。风险声明写得越具体，后续争议越少。
准入清单可以按团队节奏裁剪。迭代周期短、改动小的团队可以合并部分字段；涉及多团队协作或对外发布的版本，建议保留完整字段，并要求构建产物与提测单版本号严格对应。
交接怎么走：从提测提交到测试接收的步骤
准入条件满足后，交接按固定顺序推进。每一步都要有输入、动作和输出，完成标志明确，避免交接停在“已经通知了”的状态。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 提交提测 | 已填写的提测单、构建产物 | 开发提交提测单，通知测试负责人 | 提测单进入待核验状态 | 测试负责人收到通知并确认受理 |
| 2. 准入核验 | 提测单、构建产物、测试环境 | 测试按准入清单逐项核验，记录通过项与打回项 | 准入核验结论 | 结论为“通过”或“打回”，无悬空项 |
| 3. 交接确认 | 核验结论、测试计划草案 | 双方确认测试范围、环境、数据、时间窗口、问题反馈通道 | 交接确认记录 | 双方在记录上确认，关键信息无歧义 |
| 4. 打回与重提 | 打回原因清单 | 开发修复后重新提交，测试重新核验 | 新的提测单或补充记录 | 打回项全部关闭，重新核验通过 |
| 5. 记录归档 | 提测单、核验结论、确认记录 | 归档到统一位置，关联版本与需求 | 可追溯的交接凭证 | 后续可按版本或需求查到完整记录 |
第3步的交接确认是整条流程的关键。测试范围要写明本轮测什么、不测什么；环境要写明使用哪套测试环境及访问方式；数据要写明依赖的数据准备情况；时间窗口要写明测试开始与计划完成时间；问题反馈通道要写明缺陷提交到哪里、由谁响应、响应时限如何约定。这五项确认清楚，测试执行阶段才不容易因信息缺失而中断。
打回要有明确原因。测试在核验记录中逐条写明未通过项，例如构建无法部署、自测记录缺失、环境不可用。开发修复后重新提交时，应针对打回项逐条说明处理结果，测试据此重新核验。打回次数和原因可以保留在记录中，作为后续改进提测质量的依据。
交接记录归档后，应能按版本或需求反查：谁提交的、什么时候核验的、确认了哪些范围、有没有打回。这份凭证在出现“这个功能到底提测了没有”的争议时，是最直接的依据。
角色与交付物：开发、测试、负责人的分工
提测交接涉及三个角色，各自有明确的交付物。分工清楚，交接就不会变成某一方单方面推动的事。
| 角色 | 主要职责 | 交付物 | 完成标志 |
|---|---|---|---|
| 开发 | 准备可测版本，完成自检，声明风险 | 提测单、自测记录、风险声明 | 提测单字段完整，自测记录可查，风险逐条列明 |
| 测试 | 核验准入条件，准备测试计划与用例 | 准入核验结论、测试计划与用例准备情况 | 核验结论明确，用例覆盖本次范围 |
| 测试负责人/项目经理 | 组织交接确认，协调时间窗口，裁决争议 | 交接确认记录、争议处理结论 | 双方确认完成，争议有结论并记录 |
开发的核心交付物是提测单，它同时承担说明和承诺两个作用：说明本次改了什么，承诺自测做到什么程度。自测记录不必追求形式统一，但要能回答“测了哪些场景、结果如何、哪些没测”。
测试的交付物是核验结论和测试准备。核验结论只有通过和打回两种，避免“基本可以”这类模糊表述。测试计划与用例准备应在交接确认前完成初稿，这样确认范围时双方讨论的是具体条目，而不是抽象的功能名称。
测试负责人或项目经理负责把双方拉到同一个确认动作上，并在范围、时间窗口出现分歧时给出结论。争议裁决的结果要写进交接记录，避免会后各自理解不同。
在ONES中，测试用例可以与需求、研发任务关联，测试计划可以与迭代关联，提测单和交接确认记录可以作为工作项或文档承载，使版本、范围与测试准备在同一处对应起来。具体用哪种对象承载提测单，需要按团队实际配置确定。
一个完整的提测交接示例
以下为演示情景，用于说明提测单填写和交接确认的记录方式，不代表真实项目数据。
示例背景：某版本迭代计划提测“订单列表筛选”和“优惠券叠加规则”两项改动，开发完成自测后提交提测。
提测单填写示例：
- 版本号：v2.4.0-build118
- 需求/缺陷清单：需求 REQ-231 订单列表新增按时间与状态组合筛选；缺陷 BUG-887 优惠券叠加时金额计算错误
- 影响范围：订单列表页、订单查询接口、优惠券计算服务；关联的下单流程需回归
- 自测结论：筛选组合场景 12 项已执行，通过 11 项；优惠券叠加 6 种组合已执行，通过 6 项；未覆盖导出功能
- 代码与构建状态：分支已合入 release/2.4，构建可部署，构建号与提测单一致
- 环境与数据：测试环境已部署，测试账号与历史订单数据已准备
- 已知问题与风险：导出功能本次未改动但依赖同一查询接口，存在回归风险；BUG-887 的极端金额场景暂未覆盖
测试核验与交接确认记录示例：测试核验后确认构建可部署、自测记录可查、环境可用，准入通过。交接确认记录写明：本轮测试范围为订单列表筛选组合、优惠券叠加计算及下单流程回归，导出功能做冒烟验证；使用测试环境 A，账号与数据已就绪；测试时间窗口为两天；缺陷提交至订单项目缺陷列表，开发当日响应。双方确认后归档，并关联版本 v2.4.0 与相关需求。
打回场景示例：若测试核验时发现构建部署失败，或自测记录只写了“已自测”而无具体场景，测试在核验记录中写明打回原因，提测单退回开发。开发补充自测记录或修复构建后重新提交，测试针对打回项重新核验，通过后再进入交接确认。打回原因保留在记录中，便于后续统计哪类问题最常导致无效提测。
交接完成后怎么检查是否做到位
判断一次提测交接是否闭环，可以对照下面这份检查清单。每一项都能在记录中找到对应内容，才算做到位。
- 提测单字段完整：版本号、需求/缺陷清单、影响范围、自测结论、风险声明均有填写，版本号与构建产物对应。
- 准入核验有结论：通过或打回明确，打回项逐条写明原因，没有“待补充”长期悬置。
- 测试范围已双方确认：写明测什么、不测什么，关联的需求和缺陷可查。
- 环境与数据已确认：测试环境可用，必要数据与账号就绪，确认记录中有对应说明。
- 时间窗口与反馈通道明确：测试起止时间、缺陷提交位置、响应责任人已约定。
- 交接记录可查、责任可追：能按版本或需求反查到提交人、核验人、确认人和确认时间。
常见遗漏点集中在几处：用口头或群消息代替提测单，导致版本和范围无法追溯；测试范围只写功能名称，没写边界，执行中反复确认；环境未就绪就进入交接确认，测试开始后被迫等待；风险声明缺失，测试按“全部可测”安排计划，遇到未完成项才发现范围要调整。把这些点纳入检查清单，交接质量会逐步稳定。
团队可以把这份清单固化为提测单的必填项和交接确认的核对项，并在每个版本结束后回看打回原因和遗漏点，调整准入字段的严格程度。提测交接做到位，测试执行阶段的范围、环境和责任就有了共同依据。
常见问题
提测被打回后，开发重新提测需要重新走完整流程吗？
重新提测时，准入核验和交接确认需要重新执行，但不必从头填写所有内容。开发可以沿用原提测单，针对打回项逐条说明处理结果，更新版本号或构建号后重新提交；测试则针对打回项重新核验，通过后再进入交接确认。打回原因和重提记录建议保留在原记录中，便于后续统计哪类问题最常导致无效提测。
迭代周期很短、改动很小的团队，准入清单可以精简到什么程度？
可以合并部分字段，但建议保留三类信息：本次改了什么（需求/缺陷清单与影响范围）、自测做到什么程度（自测结论与未覆盖项）、有什么已知风险。版本号与构建产物的对应关系也应保留，否则后续追溯会出现困难。涉及多团队协作或对外发布的版本，建议恢复完整字段，并要求构建产物与提测单版本号严格对应。
交接确认时测试范围怎么写才算清楚？
测试范围要写明本轮测什么、不测什么，并关联到具体的需求和缺陷编号。只写功能名称容易在执行中反复确认边界，建议把主要场景和明确排除的项都列出来。范围确认后写入交接记录，双方确认，后续如需调整范围，应在记录中补充说明调整原因和时间。
提测单和交接记录放在哪里，才能保证后续可查？
关键是归档到统一位置，并与版本、需求建立关联，使后续能按版本或需求反查到提交人、核验人、确认人和确认时间。在ONES中，测试用例可以与需求、研发任务关联，测试计划可以与迭代关联，提测单和交接确认记录可以作为工作项或文档承载，让版本、范围与测试准备在同一处对应起来；具体用哪种对象承载，需要按团队实际配置确定。
交接时环境还没准备好，可以先确认再补吗？
不建议。环境与数据是准入核验的一部分，环境不可用时应作为打回项记录，待环境就绪后重新核验。若因排期压力先确认交接，测试开始后往往被迫等待，时间窗口和测试计划都要跟着调整。确需提前介入时，可以在记录中写明环境就绪的时间和前置条件，把等待风险显式化。
