开发提测交接要讲清楚四件事：测什么、怎么测、测哪里、出问题找谁。具体包括变更范围与需求来源、影响模块与回归范围、构建与部署信息、自测结论与已知问题、接口与数据变更、测试账号与权限、日志入口、风险依赖以及提测响应人。这份清单适合开发发起提测、测试受理核对时逐项使用，每项都配有通过标准和证据形式；ONES可用于承载提测单与交接记录。
要点总览（TL;DR）
- 提测交接要交清四类信息：测什么（变更范围与需求来源）、怎么测（构建版本、环境、账号与数据）、测哪里（影响模块与回归范围）、出问题找谁（提测人与响应人）。
- 每项检查都要配可观察的通过标准和证据形式，例如版本号与环境一致、主流程自测有记录、关联需求单可追溯，避免“已完成”这类无法核验的描述。
- 环境不可访问、范围不明、主流程自测未过、账号不可用属于阻断项，应退回补交；非核心已知问题等可带条件放行，但需记录风险与责任人。
- 提测完成的判定条件是阻断项全部满足、放行项已记录、测试已给出受理结论，判定结果与核对记录留在提测单中。
- 清单挂载在提测单或工作项上，按待提测、已提测、测试受理、退回补交流转，交接记录与后续测试执行衔接。
谁在什么时点使用这份提测交接清单
提测交接涉及两个角色：提测人是开发，负责准备并提交信息；接收人是测试，负责核对并决定受理或退回。清单的价值在于让双方对“何时算提测”形成同一判断，避免开发认为“代码写完就是提测”，测试却因信息不全无法开始。
清单在三个时点发挥作用。提测发起时，开发按清单逐项自查并填写提测单；测试受理时，测试按清单核对，确认信息完整、环境可用；退回补交时，测试指出缺失项，开发补齐后重新提交。三个时点对应三种状态，每次状态变化都应有记录。
| 时点 | 主导角色 | 动作 | 产出 |
|---|---|---|---|
| 提测发起 | 开发（提测人） | 按清单自查，填写提测单并附证据 | 状态为“已提测”的提测单 |
| 测试受理 | 测试（接收人） | 核对版本、范围、环境与已知问题 | 受理结论：通过或退回 |
| 退回补交 | 开发 | 补齐缺失项，更新提测单 | 重新提交的提测单及补交说明 |
清单应挂载在提测单或对应工作项中，作为提测单的检查区块或附件，而不是散落在聊天记录里。这样提测信息、核对结论和责任人都在同一处可查。
提测前开发需备齐的检查项
开发在发起提测前，需要把以下五类信息准备齐全。每一项都应有明确的填写内容，而不是“已完成”之类的笼统描述。
| 检查项 | 通过标准 | 证据形式 |
|---|---|---|
| 变更范围与需求/缺陷单关联 | 列出本次变更涉及的需求单号、缺陷单号，说明改动功能点；无关联单号的变更需注明原因 | 提测单中的关联单号列表、变更说明 |
| 构建版本、分支、制品与环境 | 版本号唯一可识别；分支与制品对应；目标环境地址可访问，部署已完成 | 构建记录链接、制品包名、环境地址 |
| 自测结论与已知问题清单 | 主流程自测通过并有记录；已知问题逐条列出，标注影响范围与是否阻塞测试 | 自测记录、已知问题列表 |
| 接口、数据库、配置变更说明 | 新增或变更的接口有文档或字段说明；数据库变更含脚本与回滚方式；配置项列出变更内容 | 接口文档链接、变更脚本、配置清单 |
| 测试账号、权限与数据准备 | 测试所需账号已开通且可登录；角色权限满足用例要求；测试数据已准备或说明生成方式 | 账号清单、权限说明、数据准备说明 |
影响模块与回归范围需要单独说明：本次改动可能波及哪些已有功能，测试应重点回归哪些路径。这一项常被忽略，导致测试只验证新功能而漏掉关联模块。日志与问题定位入口也应一并提供，包括日志路径、查询方式或监控面板地址，方便测试发现问题时先自行定位。
测试受理时的核对与退回检查项
测试受理提测时，按以下顺序核对，任一项不满足即进入退回判断。
| 核对项 | 核对动作 | 不满足时的处理 |
|---|---|---|
| 版本与环境可访问性 | 按提测单地址访问环境，确认版本号与提测单一致，部署可正常启动 | 环境不可访问或版本不符，退回 |
| 需求与变更范围可追溯 | 核对关联需求单、缺陷单是否存在且状态合理，变更说明能对应到具体功能点 | 范围不明或无法追溯，退回补充 |
| 已知问题是否影响主流程 | 逐条查看已知问题，判断是否阻塞核心用例执行 | 存在阻塞主流程的问题且无替代方案，退回 |
| 账号与数据可用 | 用提供的账号登录，验证权限与数据满足首批用例 | 账号不可用或数据缺失，退回补充 |
退回时应写明缺失项和补交要求，而不是笼统回复“信息不全”。补交完成后，开发更新提测单并重新提交，测试重新核对受影响的项目即可，不必全量重来。受理通过后，测试启动测试计划，提测单状态更新为“测试受理”。
每项检查的通过标准与证据形式
通过标准的写法决定清单能否真正使用。合格的标准是可观察、可判断的：换一个人来看，能得出相同结论。例如“版本号与制品在目标环境可部署并访问”可以判断，“开发已完成自测”无法判断。
证据形式应与检查项匹配，常见的有四类：提测单字段（如版本号、关联单号）、构建记录（流水线链接、制品包）、自测记录（用例执行结果、截图）、链接类材料（接口文档、日志面板、环境地址）。证据不必复杂，但要能支撑结论。
| 检查项 | 通过标准示例 | 证据 | 负责人 | 检查时点 |
|---|---|---|---|---|
| 构建与环境 | 版本号唯一，目标环境可访问且版本一致 | 构建记录链接、环境地址 | 开发 | 提测发起前 |
| 变更范围 | 每个改动功能点对应需求单或缺陷单 | 关联单号列表 | 开发 | 提测发起前 |
| 自测结论 | 主流程用例执行通过并有记录 | 自测记录或截图 | 开发 | 提测发起前 |
| 已知问题 | 逐条列出，标注影响范围与阻塞判断 | 问题列表 | 开发 | 提测发起前 |
| 受理核对 | 环境、范围、账号三项核对通过 | 受理结论记录 | 测试 | 测试受理时 |
负责人和检查时点要写进清单本身，避免出现“大家都以为对方检查过”的情况。开发负责提测前各项的准备与自查，测试负责受理时的核对，两类责任在提测单上分开记录。
阻断项与提测完成条件
并非所有缺项都需要阻断提测。区分阻断项与可带条件放行项，能让流程既守住底线又不至于过度卡顿。
必须阻断的缺项包括：版本不可部署或环境不可访问；变更范围不明、无法追溯到需求或缺陷单；主流程自测未通过；测试账号不可用导致核心用例无法执行；数据库或接口变更缺少必要说明且影响测试判断。这些情况下一旦放行，测试无法有效开展工作，应直接退回。
可带条件放行的事项包括：非核心模块的已知问题、部分测试数据需在使用中生成、次要配置项说明待补。放行时需在提测单中记录风险内容、影响范围和责任人，并由测试确认接受。
| 类别 | 典型情形 | 处理方式 |
|---|---|---|
| 阻断项 | 环境不可访问、范围不明、主流程自测未过、账号不可用 | 退回补交，补齐后重新提交 |
| 可放行项 | 非核心已知问题、次要说明待补 | 记录风险与责任人，测试确认后受理 |
提测完成的判定条件是：阻断项全部满足，可放行项已记录，测试已给出受理结论。判定结果连同核对记录留在提测单中，作为后续测试执行和责任追溯的依据。
用工作项承载提测交接记录
把清单落到协作工具中，关键是让提测单成为一个可流转、可追溯的工作项。提测单应包含这些字段：关联需求与缺陷、版本号、分支与制品、目标环境、变更说明、自测结论、已知问题、测试账号、风险与依赖、提测人与响应人。附件用于存放构建记录、自测截图和变更脚本。
状态按“待提测—已提测—测试受理—退回补交”流转，每次流转记录操作人和时间。退回补交时保留原提测单，补充说明写在同一条记录中，便于对比前后差异。受理通过后，提测单与测试计划关联，测试执行中发现的缺陷可回链到提测单，形成从交接、执行到问题反馈的连续记录。
ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，可将提测单关联的需求单、测试计划放在同一流程中；未通过的用例可快速创建缺陷任务，在测试与研发团队间流转。若团队需要按角色控制提测单和用例库的可见与编辑范围，也可通过用户组权限配置实现。具体字段与状态配置需结合团队实际流程在工具中设置。
常见问题
提测被退回后，开发需要重新走一遍完整清单吗？
不需要全量重来。退回时测试应写明缺失项和补交要求，开发补齐后在原提测单上更新并附补交说明，测试只重新核对受影响的项目，例如环境恢复后核对版本与环境一致性，账号补齐后验证登录与权限。原提测单保留，补交内容写在同一记录中，便于对比前后差异。
小改动或紧急修复也要按这份清单交接吗？
清单可以按变更规模裁剪，但阻断项的判断标准不宜放宽。紧急修复时，变更范围和关联缺陷单、目标环境与版本、主流程自测结论、测试账号这几项仍应提供；影响模块与回归范围可以简写为“仅影响某功能点”并说明依据。裁剪后的清单应在提测单中注明适用条件，由测试确认接受，避免事后对交接范围产生分歧。
已知问题较多时，哪些可以带条件放行？
判断依据是问题是否阻塞核心用例执行。非核心模块的已知问题、部分测试数据需在使用中生成、次要配置说明待补，可以在记录风险内容、影响范围和责任人后由测试确认放行。若已知问题会导致主流程无法走通，或缺少替代验证路径，则应作为阻断项退回。放行记录留在提测单中，后续测试执行时据此区分“已知问题”和“新发现缺陷”。
提测单和测试计划之间如何衔接？
受理通过后，提测单应与对应的测试计划关联，测试按计划分配用例执行人并启动执行。执行中未通过的用例可创建缺陷任务，缺陷回链到提测单，形成从交接、执行到问题反馈的连续记录。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，也支持未通过的用例快速创建缺陷任务；具体字段与关联方式需结合团队流程在工具中配置。
清单里的证据需要多正式，截图可以吗？
证据的作用是支撑结论，形式与检查项匹配即可。构建记录用流水线链接或制品包名，环境用可访问的地址，自测结论用用例执行记录或截图，接口与数据库变更用文档链接和变更脚本，账号与权限用账号清单和权限说明。截图可以作为自测记录的证据，但应能看出执行的是哪条用例、结果如何，单张无上下文的截图难以支撑判断。
