提测交接要解决的是“版本交到测试手上时，责任和标准是否清楚”。把交接内容写成可核对的交接单，把交付要求写成可判定的准入标准，开发、测试、产品三方按同一份记录确认，提测才不至于变成口头通知加临时补材料。下面给出一套可直接落地的字段框架、操作步骤、角色分工与检查清单。
要点总览（TL;DR）
- 提测交接用一份交接单固定六类信息：版本与构建号、需求与变更范围、自测结论、环境与数据准备、已知缺陷与风险、计划测试窗口，每类都写明填写人和确认人。
- 交接按四步走：开发提交申请与自测证据、测试按准入条件给出接收或退回结论、双方确认范围优先级与时间窗口、记录归档后进入执行。
- 责任按角色划分：开发负责人交版本与自测报告，测试负责人出准入核验结论与排期确认，产品/项目负责人确认范围、裁决优先级并审批例外放行。
- 准入条件要可判定，如主流程自测通过、构建可部署、变更范围可追溯、阻塞级缺陷清零；退回写明依据条目，补充后按同一份交接单二次核验。
- 交接完成前按清单核对字段完整性、准入逐项结论、确认记录、退回与例外记录以及记录可追溯性，全部满足再进入测试执行。
提测交接要固定哪五类信息
交接单的作用是把“谁交、交什么、交到什么程度”变成可逐项勾选的记录。字段不必多，但每一类都要有明确的填写人和确认人，缺失时也有对应处理方式，避免交接现场靠追问补齐。
| 字段 | 填写人 | 确认人 | 缺失时的处理 |
|---|---|---|---|
| 提测版本与构建号 | 开发负责人 | 测试负责人 | 无构建号不予受理，退回补充；构建号需与部署包一致 |
| 需求与变更范围 | 开发负责人 | 产品/项目负责人 | 范围未列明时，测试方按“范围不明”退回，由产品确认后再提 |
| 自测结论 | 开发负责人 | 测试负责人 | 无自测记录视为未完成自测，直接退回 |
| 环境与数据准备 | 开发负责人 | 测试负责人 | 环境不可用或数据缺失时，记录为阻塞项，约定补齐时间后再验收 |
| 已知缺陷与风险 | 开发负责人 | 测试负责人 | 未列已知问题按隐瞒处理，退回并记录；影响主流程的风险需产品知悉 |
| 计划测试窗口 | 测试负责人 | 开发负责人 | 窗口未确认不进入执行，由双方在交接单上补齐起止时间 |
字段缺失的处理原则是“缺什么退什么”，而不是整单作废重来。测试方在核验时逐项标注缺失项，开发方只补对应内容，减少来回沟通成本。每个字段的确认动作要留下记录，确认人一栏不能空着，否则责任无法回溯到具体的人。
按四步完成一次提测交接
四步流程的关键是每步都有明确的输入、动作、输出和完成标志，交接双方知道当前走到哪一步、下一步由谁推动。
第一步：开发方提交提测申请及自测证据
输入是待提测的构建产物、需求与变更清单、自测记录。动作是开发负责人按交接单字段逐项填写，附上自测用例执行结果和已知问题清单。输出是一份完整的提测申请。完成标志是交接单字段无空缺、自测证据可打开核对。
第二步：测试方按准入条件核验并给出结论
输入是提测申请与准入条件清单。动作是测试负责人逐条核对：构建能否部署、主流程自测是否通过、变更范围是否可追溯、阻塞级缺陷是否清零。输出是“接收”或“退回”的明确结论，退回时写明依据的准入条目和缺失项。完成标志是结论已记录在交接单上，并通知到开发负责人。
第三步：双方确认测试范围、优先级与时间窗口
输入是已接收的提测申请和需求优先级信息。动作是测试负责人提出测试范围与排期建议，开发负责人确认变更影响面，产品/项目负责人对优先级冲突做出裁决。输出是确认后的测试范围、优先级顺序和测试起止时间。完成标志是三方在交接单上完成确认，时间窗口写入记录。
第四步：交接记录归档并进入测试执行
输入是已完成确认的交接单。动作是将交接单与对应的测试计划、用例集关联归档，测试方开始按计划执行。输出是可追溯的交接记录和已启动的测试任务。完成标志是交接单状态变为“已交接”，测试执行有对应的计划承接。
在工具承载上，ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，交接单可以作为工作项或文档与测试计划放在同一空间中，使交接时点、版本状态和后续执行记录保持对应关系。
角色分工与各自交付物
责任落到角色，才不会在退回时出现“以为对方会补”的空档。三方在交接中的职责边界和产出如下。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 开发负责人 | 准备可部署版本，完成自测，说明变更与已知问题 | 构建产物与构建号、自测报告、变更说明、已知问题清单 |
| 测试负责人 | 按准入条件核验，给出接收或退回结论，确认测试范围与排期 | 准入核验结论、测试范围与排期确认、退回依据记录 |
| 产品/项目负责人 | 确认需求范围，裁决优先级冲突，审批例外放行 | 需求范围确认、优先级裁决记录、例外放行审批记录 |
退回的责任归属要写清楚：因字段缺失或自测不足被退回，由开发负责人负责补齐并重新提交；因范围不清被退回，由产品/项目负责人澄清后再提。升级路径同样需要约定，例如同一版本连续两次因同一原因被退回，由项目负责人介入协调，避免反复退回消耗测试窗口。
ONES 测试管理支持为不同用户组配置不同权限，也可为用例库、测试计划单独配置权限，便于把提测核验、范围确认等动作限定在对应角色范围内。
准入标准与退回规则怎么定
准入标准要写成能判定“通过或不通过”的条目，每条都有判定依据，避免“基本完成”“大致可用”这类无法核验的表述。
- 主流程自测通过：依据是自测用例执行记录，主流程用例全部通过。
- 构建可部署：依据是构建号与部署包一致，测试环境部署成功。
- 变更范围可追溯：依据是变更清单能对应到需求或任务条目。
- 阻塞级缺陷已清零：依据是已知问题清单中无阻塞主流程的未修复项。
退回的判定条件是上述任一条目不满足，或交接单关键字段缺失。退回时测试方需写明具体条目和缺失内容，开发方补充后按同一份交接单重新提交，测试方针对退回项做二次核验，已通过项不重复全量检查。这样退回成为流程的正常分支，而不是双方拉扯的起点。
例外放行需要审批人签字并记录放行范围，例如某阻塞级缺陷已有临时规避方案、影响面可控，由产品/项目负责人审批后放行，并在测试执行阶段作为风险项持续跟踪。例外记录要写明放行理由、影响范围和跟踪责任人，防止例外逐渐变成默认做法。
示例：一次被退回的提测如何走完闭环
以下为演示情景，用于说明字段填写与退回处理方式。
某版本计划提测订单模块的优惠券叠加功能。开发负责人提交交接单：构建号 build-20240612-03，变更范围为优惠券叠加计算与展示，自测结论为主流程用例通过，已知问题列出“叠加后金额展示偶发延迟”，环境为测试环境已部署，计划测试窗口为两天。测试方核验时发现两处问题：变更清单未关联对应需求条目，无法确认范围边界；已知问题中“偶发延迟”未说明触发条件和影响范围，且该问题涉及主流程金额展示，按准入条件属于阻塞级未清零。
测试方给出退回结论，依据为“变更范围不可追溯”和“阻塞级缺陷未清零”两条，并在交接单上标注缺失项。开发方补充需求关联关系，将延迟问题定位为特定优惠券组合下的计算顺序问题，修复后更新构建号为 build-20240613-01，重新提交自测记录和问题修复说明。测试方二次核验只针对退回项：需求关联已补齐，延迟问题已修复且自测复现通过，其余已通过项维持原结论，给出接收结论。
最终交接记录包含：新构建号、关联需求条目、修复说明、二次核验结论、确认后的测试范围与时间窗口、双方确认人和确认时间。记录归档后进入测试执行，退回与重新提交的全过程都可追溯。
交接质量的完成检查
一次交接是否合格，可以按以下清单逐项核对，全部满足再进入测试执行。
- 交接单字段完整：版本与构建号、变更范围、自测结论、环境与数据、已知问题、测试窗口六类信息均有内容，无空缺项。
- 准入条件逐项核对：主流程自测、构建可部署、范围可追溯、阻塞级缺陷清零四条均有判定依据和核验结论。
- 责任人与确认记录齐全：每个字段的填写人和确认人已记录，接收或退回结论有明确责任人。
- 退回与例外有记录：退回写明依据条目和缺失项，重新提交有二次核验结论；例外放行有审批人和放行范围。
- 记录可追溯：交接单与测试计划、用例执行记录关联，能回溯交接时点的版本状态和确认过程。
把这套字段、流程和检查清单固定下来，提测交接就从一次口头通知变成有记录、可判定、能追溯的协作动作。ONES 测试管理可将交接记录与测试计划、用例执行、缺陷任务放在同一流程中，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转，使交接结论与后续执行保持连贯。
常见问题
提测被退回后，开发方需要重新走完整流程吗？
不需要。退回后按同一份交接单补充缺失内容，测试方针对退回项做二次核验，已通过项维持原结论。例如因变更范围不可追溯被退回，开发方补齐需求关联关系后重新提交，测试方只核对范围关联这一项，不必把自测结论、环境准备等已通过项全部重查一遍。这样退回成为流程的正常分支，减少重复核验消耗的测试窗口。
例外放行的边界怎么把握，什么情况下可以带缺陷提测？
例外放行适用于缺陷已有临时规避方案、影响面可控且不阻断主流程的情况，由产品/项目负责人审批并记录放行范围。放行记录要写明理由、影响范围和跟踪责任人，并在测试执行阶段作为风险项持续跟踪。如果同一类问题反复申请例外，说明准入标准或开发自测环节需要调整，应回到准入条件本身复核，避免例外逐渐变成默认做法。
团队规模较小、没有独立产品负责人时，范围确认和优先级裁决由谁承担？
可以由项目负责人或测试负责人兼任，但要在交接单上明确写清兼任的角色，避免出现“以为对方会确认”的空档。兼任时建议把范围确认和优先级裁决分开记录：范围确认依据需求条目，优先级裁决依据本次提测的业务影响，两项都留下确认人和时间。角色可以合并，确认动作和记录不能省略。
交接单和测试计划、用例执行记录怎么关联，后续才能追溯？
交接单归档时与对应的测试计划、用例集建立关联，记录提测版本与构建号、确认后的测试范围和时间窗口。测试执行阶段的用例结果、缺陷记录挂接到同一测试计划下，回溯时可以从交接单查到当时的版本状态和确认过程。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，交接记录可以作为工作项或文档与测试计划放在同一空间中，保持交接时点与后续执行记录的对应关系。
交接记录需要保存多久，哪些内容必须留痕？
保存期限按团队的质量追溯要求确定，通常至少覆盖该版本从提测到发布后的问题回溯周期。必须留痕的内容包括：构建号与部署包的一致性记录、自测结论、准入逐项核验结论、接收或退回的依据条目、退回后的补充内容与二次核验结论、例外放行的审批人与放行范围、三方确认人和确认时间。字段填写人一栏不能空着，否则责任无法回溯到具体的人。
