提测清单是开发方在提交测试前填写的交接表，测试方据此判断能否开始测试。一份可用的清单通常包含五类信息：提测基本信息、本次变更范围、自测与准入证据、测试所需条件、风险与回退说明。下面给出一份可直接复制到文档或表格中的空白模板，并逐字段说明填写要求、划分必填与选填，最后用一份完整示例演示实际写法，供团队按项目情况裁剪维护。
要点总览（TL;DR）
- 提测清单是开发方提交测试前填写的交接表，核心包含五类信息：提测基本信息、本次变更范围、自测与准入证据、测试所需条件、风险与回退说明。
- 必填与选填按“缺失后测试方能否判断准入或开展测试”划分：影响准入判断和执行的字段必填，只影响信息完整度的可归选填；必填缺失时测试方可拒收退回补充。
- 填写时把变更范围写到功能点、自测结论如实标注未覆盖场景、已知问题逐条写现象和影响，清单才具备可执行性。
- 模板可按项目类型裁剪选填字段，新增字段需先判断是否影响准入判断，并配套版本与变更记录，出现重复退回或漏测时安排复盘。
可复制空白提测清单模板
下表可直接复制到在线文档、表格或工单描述中使用。分组顺序按填写人的思路排列：先交代这次提的是什么，再说明改了什么、自己验证到什么程度、测试需要什么条件、出问题怎么退。填写栏留空，由提测人逐项补齐。
| 分组 | 字段名 | 填写栏 |
|---|---|---|
| 一、提测基本信息 | 提测单编号 | |
| 项目 / 产品名称 | ||
| 提测版本号 | ||
| 提测人及联系方式 | ||
| 提测时间 | ||
| 计划测试起止时间 | ||
| 二、本次变更范围 | 关联需求 / 缺陷编号 | |
| 改动模块与功能点 | ||
| 影响范围（关联模块、接口、数据） | ||
| 本次不包含的内容 | ||
| 代码分支 / 提交记录 | ||
| 三、自测与准入证据 | 自测结论 | |
| 冒烟测试结果 | ||
| 已知问题清单 | ||
| 自测环境与数据说明 | ||
| 四、测试所需条件 | 测试环境地址 | |
| 测试账号与角色 | ||
| 测试数据准备情况 | ||
| 依赖服务与版本 | ||
| 配置开关 / 灰度策略 | ||
| 五、风险与回退说明 | 已知限制与风险 | |
| 回退方式 | ||
| 回退验证人 | ||
| 紧急联系人 |
复制时保留分组列，便于测试方按块核对；如果团队使用工单系统，可把每个分组做成一个字段区块或子标题，填写栏对应字段值。模板本身不预设项目规模，小项目可只填必填项，大项目再补充选填内容。
每个字段填什么：字段说明
字段说明解决“知道要填，但不知道填到什么程度”的问题。下表逐字段给出含义与填写要求，填写时以“测试方能否据此判断和行动”为标准，避免写成只有开发自己看得懂的备注。
| 字段名 | 含义 | 填写要求 |
|---|---|---|
| 提测单编号 | 本次提测的唯一标识，便于后续追溯 | 按团队规则生成，如“项目缩写-版本-序号”；同一版本多次提测时递增 |
| 项目 / 产品名称 | 提测所属的业务对象 | 写到测试方能定位的层级，避免只写公司名或部门名 |
| 提测版本号 | 本次提交测试的构建版本 | 与构建产物、代码分支上的版本标识一致，不用“最新版”这类模糊说法 |
| 提测人及联系方式 | 本次提测的负责人 | 写姓名加可即时联系的方式，便于测试过程中快速确认问题 |
| 提测时间 | 开发方完成提测动作的时间 | 精确到日期和时段，作为测试响应时长的起点 |
| 计划测试起止时间 | 期望测试方执行的窗口 | 给出可执行的区间；若与测试方排期冲突，由双方在提测时确认 |
| 关联需求 / 缺陷编号 | 本次变更对应的需求单、缺陷单 | 逐条列出编号，不合并成“若干需求”；编号需在需求或缺陷系统中可查 |
| 改动模块与功能点 | 本次实际改动的代码与功能位置 | 按模块列功能点，说明改了什么行为，而非只写“优化”“调整” |
| 影响范围 | 改动可能波及的关联模块、接口、数据 | 列出需要回归的周边功能；不确定时写明“待确认”并说明原因 |
| 本次不包含的内容 | 明确排除在本次测试之外的部分 | 写清未完成或不在本次范围的功能，防止测试方按全量预期验收 |
| 代码分支 / 提交记录 | 本次构建对应的代码来源 | 给出分支名与关键提交标识，便于问题定位时对照代码 |
| 自测结论 | 开发方自测的整体结果 | 给出通过、部分通过、未通过的明确结论，并说明覆盖了哪些场景 |
| 冒烟测试结果 | 主流程能否跑通的基本验证 | 列出执行的冒烟项与结果；未执行的项目要注明原因 |
| 已知问题清单 | 提测时已发现但未修复的问题 | 逐条写现象、影响范围、是否有临时规避方式，不写“一些小问题” |
| 自测环境与数据说明 | 开发自测所用的环境与数据 | 说明与测试环境的差异，避免测试方按自测结论直接放行 |
| 测试环境地址 | 测试方应使用的环境入口 | 给出可访问地址及环境类型（如联调、预发），注明是否需要特殊网络 |
| 测试账号与角色 | 测试所需的账号及权限角色 | 按角色列出账号或申请方式；涉及敏感信息时写申请渠道，不直接贴明文密码 |
| 测试数据准备情况 | 测试所需数据的就绪状态 | 说明数据已造好、需测试方自造或依赖外部导入，并给出关键数据位置 |
| 依赖服务与版本 | 本次功能依赖的其他服务及其版本 | 列出服务名与版本，注明依赖是否已部署到测试环境 |
| 配置开关 / 灰度策略 | 控制功能生效的开关与灰度范围 | 写明开关名称、默认状态、测试时如何开启，以及灰度覆盖的用户范围 |
| 已知限制与风险 | 可能影响测试判断的限制条件 | 写清限制触发的条件和对测试结论的影响，便于测试方决定是否带风险执行 |
| 回退方式 | 测试或上线出问题时的退回手段 | 说明回退到哪个版本、由谁操作、预计耗时；涉及数据变更时说明数据回退方式 |
| 回退验证人 | 回退后负责确认状态的人 | 写姓名与角色，确保回退后有明确的人确认系统恢复 |
| 紧急联系人 | 测试期间可即时响应的人 | 至少一名开发负责人，注明可联系时段 |
必填与选填怎么划分
划分依据只有一条：该字段缺失时，测试方是否还能判断“能不能开始测试”或“能不能开展测试”。会影响准入判断和测试执行的归为必填，只影响信息完整度、可在测试过程中补充的归为选填。这个标准让必填项保持精简，避免清单变成负担。
| 类别 | 字段 | 划分理由 |
|---|---|---|
| 必填 | 提测单编号、项目 / 产品名称、提测版本号、提测人及联系方式、提测时间 | 缺少任一项，测试方无法确认提测对象和责任人，无法建立测试记录 |
| 必填 | 关联需求 / 缺陷编号、改动模块与功能点、影响范围 | 决定测试范围和回归边界，缺失则无法设计测试内容 |
| 必填 | 自测结论、冒烟测试结果、已知问题清单 | 是准入判断的直接证据，缺失时无法判断主流程是否可用 |
| 必填 | 测试环境地址、测试账号与角色、依赖服务与版本 | 缺少则测试无法实际执行 |
| 必填 | 已知限制与风险、回退方式、紧急联系人 | 影响风险判断和异常处置，属于测试开始前必须知晓的条件 |
| 选填 | 计划测试起止时间 | 用于排期协调，可在提测后由双方确认 |
| 选填 | 本次不包含的内容、代码分支 / 提交记录 | 提升追溯效率，缺失不阻断测试开始 |
| 选填 | 自测环境与数据说明、测试数据准备情况 | 帮助测试方理解差异，可在执行中补充 |
| 选填 | 配置开关 / 灰度策略、回退验证人 | 与具体发布方式相关，按项目需要填写 |
必填项缺失时，测试方可以拒收并退回开发方补充，退回时逐项列出缺失字段，避免来回多轮。团队也可以约定“先收后补”的例外：仅当缺失项不影响主流程验证、且开发方在约定时间内补齐时，测试方可带条件接收，并在提测记录中标注缺失字段和补齐时间。例外要有明确的责任人和时限，否则容易变成默认放行。
填写示例：一次完整的提测
以下示例为演示情景，版本号、需求编号、账号信息均为虚构，用于展示各字段的实际写法，字段顺序与空白模板一一对应。
| 分组 | 字段名 | 填写内容 |
|---|---|---|
| 一、提测基本信息 | 提测单编号 | ORDER-2.4.0-01 |
| 项目 / 产品名称 | 订单中心 | |
| 提测版本号 | v2.4.0-build.0312 | |
| 提测人及联系方式 | 张明（开发），企业通讯工具可即时联系 | |
| 提测时间 | 3月12日 15:30 | |
| 计划测试起止时间 | 3月13日—3月15日 | |
| 二、本次变更范围 | 关联需求 / 缺陷编号 | 需求 REQ-1042（订单拆单规则调整）；缺陷 BUG-2317（拆单后金额展示错误） |
| 改动模块与功能点 | 订单拆单服务：按仓库可用库存拆分订单；订单详情页：展示拆分后子订单金额 | |
| 影响范围 | 下单主流程、库存扣减接口、订单列表页金额汇总；需回归历史订单详情展示 | |
| 本次不包含的内容 | 拆单后的逆向退款流程，计划下个版本提测 | |
| 代码分支 / 提交记录 | 分支 feature/order-split，关键提交 8f3c2a1 | |
| 三、自测与准入证据 | 自测结论 | 部分通过：拆单主流程与金额展示已自测通过，多仓库并发场景未覆盖 |
| 冒烟测试结果 | 下单、支付、订单详情三项冒烟均通过；库存扣减接口冒烟通过 | |
| 已知问题清单 | 1. 拆单后订单列表页金额汇总存在约1秒延迟，刷新后正常；2. 多仓库并发拆单时偶发子订单顺序不一致，不影响金额 | |
| 自测环境与数据说明 | 自测使用联调环境，库存数据为手工造数，与测试环境数据量级不同 | |
| 四、测试所需条件 | 测试环境地址 | 测试环境订单中心入口（内网访问，需开通测试网段权限） |
| 测试账号与角色 | 买家账号 2 个、仓库管理员账号 1 个，通过测试账号申请单获取 | |
| 测试数据准备情况 | 已准备 3 个仓库的库存数据；历史订单数据由测试方按脚本导入 | |
| 依赖服务与版本 | 库存服务 v1.8.2、支付网关 v3.1.0，均已部署至测试环境 | |
| 配置开关 / 灰度策略 | 开关 order.split.enabled，默认关闭，测试时对测试账号开启；灰度范围仅测试账号 | |
| 五、风险与回退说明 | 已知限制与风险 | 多仓库并发拆单顺序不稳定，测试结论需注明该场景；金额汇总延迟在数据量大时可能延长 |
| 回退方式 | 关闭 order.split.enabled 开关即回到原拆单逻辑，无需回滚代码；涉及已拆订单需人工核对 | |
| 回退验证人 | 李华（测试负责人） | |
| 紧急联系人 | 张明（开发负责人），测试期间 9:00—19:00 可联系 |
这份示例的写法要点有三处：变更范围写到功能点而非模块名，让测试方能直接设计用例；自测结论如实写出未覆盖场景，避免测试方误以为已全量验证；已知问题逐条写现象和影响，便于测试方判断是否带风险执行。填写人可对照这三处检查自己的清单是否具备可执行性。
模板的调整与维护方法
模板拿到后不必原样长期使用。调整的目标是让字段与团队实际交接内容匹配，同时保持必填项对准入判断的支撑作用。调整按以下步骤进行。
按项目类型裁剪字段
先按项目特征分类，再决定字段取舍。前端页面类项目通常弱化依赖服务与配置开关，强化影响范围与多端兼容说明；后端服务类项目保留依赖服务、接口影响与回退方式；涉及数据变更的项目必须保留测试数据准备情况和数据回退说明。裁剪时只删选填项，必填项按准入判断保留；如果某必填项在多个项目中确实不适用，先改为选填并观察一个迭代，再决定是否删除。
新增字段的判断标准
新增字段前问三个问题：这个信息是否影响测试方判断能否开始测试；缺失时是否会导致返工或漏测；能否在现有字段中补充说明而不新增。三个问题中至少一个为“是”，且现有字段无法承载时，才新增字段。新增字段同时确定必填或选填归属，并写入字段说明，避免模板与说明脱节。
模板版本与变更记录
模板本身需要版本管理。每次调整记录变更日期、变更人、调整字段、调整原因和生效范围，例如“3月20日新增配置开关字段，因灰度发布项目增多”。版本号可与提测单编号规则关联，使每份提测记录能对应到当时使用的模板版本，便于回溯。
定期复盘的触发条件
出现以下情况时安排复盘：连续多个提测因同一字段缺失被退回；测试方多次在测试中才发现影响范围遗漏；模板字段连续两个迭代无人填写；项目类型发生明显变化，如新增灰度发布或数据迁移场景。复盘输出为字段增删改清单和版本记录，而不是重新讨论一遍原则。
当提测清单从文档迁移到研发管理工具中流转时，清单里的需求编号、缺陷编号和版本信息需要与需求、任务、测试计划建立关联，否则提测记录容易与后续执行脱节。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，形成测试流程闭环；测试计划可规划执行并分配用例执行人，未通过的用例可快速创建缺陷任务，在测试与研发团队间流转。团队可以把提测清单作为提测环节的交接文档，把其中的需求、缺陷编号对应到系统中的工作项，使提测通过后的测试执行和缺陷跟踪有据可查。缺陷修复闭环与验证跟踪、测试报告与质量评估属于相邻环节，本文不展开，团队可在提测交接完成后按各自流程衔接。
常见问题
提测清单里的必填项缺失，测试方一定要拒收吗？
默认做法是拒收并退回开发方补充，退回时逐项列出缺失字段，减少来回轮次。团队也可以约定带条件接收的例外：缺失项不影响主流程验证，且开发方在约定时间内补齐，测试方可以先接收并在提测记录中标注缺失字段和补齐时间。例外要写明责任人和时限，否则容易变成默认放行。
小项目或紧急提测时，能不能只填必填项？
可以。模板本身不预设项目规模，必填项对准入判断起支撑作用，选填项用于提升追溯和排期效率。紧急提测时先保证必填项完整，选填项可在测试过程中补充。需要注意的是，影响范围、已知问题清单这类必填项即使时间紧也应填写，它们直接决定测试方能否设计用例和判断风险。
提测清单和缺陷单、测试用例之间怎么衔接？
提测清单负责交接：说明这次提的是什么、改了什么、测试需要什么条件。测试方据此设计用例并执行，执行中发现的问题进入缺陷流程，修复后回到验证环节。清单中的需求编号、缺陷编号应与需求系统、缺陷系统中的记录对应，避免提测记录与后续执行脱节。缺陷修复闭环与验证跟踪、测试报告与质量评估属于相邻环节，按团队各自流程衔接。
同一版本多次提测，清单怎么处理？
每次提测生成独立的提测单编号，按“项目缩写-版本-序号”递增，例如同一版本第二次提测用序号02。每次提测单独填写变更范围和自测证据，不覆盖上一次记录，便于追溯每个构建对应的改动内容。如果第二次提测只修复了上一轮的部分缺陷，在关联缺陷编号中逐条列出，并说明本次不包含的内容。
把提测清单放进研发管理工具流转，需要注意什么？
关键是让清单里的编号与系统中的工作项对应起来。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，测试计划可规划执行并分配用例执行人，未通过的用例可快速创建缺陷任务在测试与研发团队间流转。团队可以把提测清单作为提测环节的交接文档，把需求、缺陷编号对应到系统中的工作项，使提测通过后的测试执行和缺陷跟踪有据可查。
