提测清单是开发在提交测试前填写的一张交接表，用来让测试人员快速掌握本次提测的范围、版本、环境、自测情况和已知风险。本文提供一份可直接复制使用的空白提测清单，覆盖基本信息、变更范围、自测结果、环境数据、风险、回退方案和交接确认七组字段，并逐项说明填写口径、必填规则和完整示例，方便团队按自身情况调整后长期使用。文中也会说明如何把提测清单落到ONES的提测工作项中流转。
要点总览（TL;DR）
- 提测清单是开发提交测试前填写的交接表，核心是让测试人员拿到清单就能开始工作，不必反复追问范围、版本和环境。
- 模板按七组字段组织：基本信息、变更范围与影响模块、自测与冒烟结果、环境与数据准备、已知问题与风险、回退方案、交接与确认。
- 必填项覆盖版本、环境、变更概述、冒烟结果、已知缺陷和回退方案，任一项为空时测试可拒收退回补齐；选填项按项目实际情况填写。
- 小型迭代可把影响模块、风险等级降为选填，核心链路或对外发布项目建议把已知限制和风险判断也列为必填，调整结论写入模板版本记录。
- 模板可按季度或大版本收集反馈，统计常空字段和未使用字段后增删，并落到协作工具的工作项描述模板中固化。
可复制空白提测清单模板
下面这张表可以直接复制到文档、表格或工作项描述中使用。七组字段按填写顺序排列，每组用一行或一个区块承载，团队复制后删掉不需要的选填行即可。表格采用“字段—填写内容”的两列结构，便于逐项对照填写。
| 分组 | 字段 | 填写内容 |
|---|---|---|
| 一、基本信息 | 提测单编号 | |
| 需求/任务名称 | ||
| 提测版本号 | ||
| 开发负责人 | ||
| 提测日期与预计测试周期 | ||
| 关联需求/缺陷链接 | ||
| 二、变更范围与影响模块 | 本次变更内容概述 | |
| 涉及模块/页面 | ||
| 影响的下游模块或接口 | ||
| 不在本次范围的内容 | ||
| 三、自测与冒烟结果 | 自测用例执行情况 | |
| 冒烟测试结果 | ||
| 自测发现并已修复的问题 | ||
| 自测未覆盖的部分及原因 | ||
| 四、环境与数据准备 | 测试环境地址/标识 | |
| 部署分支与构建号 | ||
| 依赖服务与配置变更 | ||
| 测试数据准备情况 | ||
| 五、已知问题与风险 | 已知缺陷列表 | |
| 已知限制与待确认项 | ||
| 风险等级与影响判断 | ||
| 六、回退方案 | 回退触发条件 | |
| 回退步骤 | ||
| 数据与配置回退注意事项 | ||
| 七、交接与确认 | 提测人签字/确认 | |
| 测试接收人 | ||
| 交接时间与备注 |
复制时建议保留分组名称，方便测试人员按区块核对。若团队使用在线表格，可把“填写内容”列设为待填单元格，并在表头加一行说明“标*为必填”，与下一节的必填规则对应。
每个字段填什么：字段说明与填写口径
字段说明的作用是让不同开发填出来的提测单口径一致，测试人员不必反复追问。下面按模板顺序逐组解释含义和常见写法，填写时以“测试人员能否据此开始测试”为判断标准。
| 字段 | 含义 | 填写口径与常见写法 |
|---|---|---|
| 提测单编号 | 本次提测的唯一标识 | 沿用需求号或按“项目-版本-序号”规则生成，便于检索和关联 |
| 需求/任务名称 | 本次提测对应的需求或任务 | 写需求标题，避免只写“优化”“修复”这类笼统描述 |
| 提测版本号 | 被测代码的版本标识 | 写分支名加构建号或发布版本号，确保测试能定位到具体构建 |
| 开发负责人 | 本次提测的主要开发 | 写姓名，多人协作时标注主负责人和协助人 |
| 提测日期与预计测试周期 | 交接时间和计划测试时长 | 写具体日期和预计天数，便于测试排期 |
| 关联需求/缺陷链接 | 需求单、缺陷单或设计文档地址 | 贴可点击的链接，测试据此核对验收标准 |
| 本次变更内容概述 | 这次改了什么 | 用两三句话说明改动点，按功能点分条列出 |
| 涉及模块/页面 | 改动落在哪些功能区域 | 写模块名或页面路径，测试据此确定用例范围 |
| 影响的下游模块或接口 | 改动可能波及的其他部分 | 列出被调用的接口、共享组件或关联业务，提示回归范围 |
| 不在本次范围的内容 | 明确排除的部分 | 写清哪些相关功能本次未改，避免测试误判为缺陷 |
| 自测用例执行情况 | 开发自测的覆盖程度 | 写“执行X条，通过Y条”，或按功能点说明已自测项 |
| 冒烟测试结果 | 主流程是否可用 | 写“通过/不通过”并注明冒烟覆盖的主流程 |
| 自测发现并已修复的问题 | 自测阶段修掉的问题 | 简述问题点和修复方式，提示测试重点复测 |
| 自测未覆盖的部分及原因 | 自测的空白区 | 如实写明未覆盖项和原因，如依赖环境、数据未就绪 |
| 测试环境地址/标识 | 测试在哪套环境验证 | 写环境名称或地址，多环境时注明本次部署的环境 |
| 部署分支与构建号 | 环境上部署的具体构建 | 与环境字段对应，确保测试验证的就是提测构建 |
| 依赖服务与配置变更 | 本次涉及的依赖和配置调整 | 列出新增或变更的配置项、依赖服务版本 |
| 测试数据准备情况 | 测试所需数据是否就绪 | 写“已准备/需测试自建”，并说明数据来源或账号 |
| 已知缺陷列表 | 提测时已知但未修复的问题 | 逐条列出缺陷编号、现象和影响，标注是否阻塞测试 |
| 已知限制与待确认项 | 功能限制或需求待定内容 | 写清限制条件和待确认问题，避免测试按错误预期判断 |
| 风险等级与影响判断 | 对本次提测风险的评估 | 按高/中/低标注，并说明影响的功能或用户范围 |
| 回退触发条件 | 什么情况下需要回退 | 写具体条件，如主流程不可用、严重缺陷无法短期修复 |
| 回退步骤 | 如何回退到上一版本 | 按步骤写清回退操作、涉及的分支或发布包 |
| 数据与配置回退注意事项 | 回退时的数据风险 | 注明是否有数据结构变更、配置是否需要同步还原 |
| 提测人签字/确认 | 开发确认信息真实完整 | 写姓名和确认时间，表示对填写内容负责 |
| 测试接收人 | 接收提测的测试人员 | 写姓名，多人时标注主接收人 |
| 交接时间与备注 | 交接完成时间和补充说明 | 写具体时间，备注可记录口头补充的约定 |
填写时有两个常见偏差值得注意：一是“变更内容概述”写成开发视角的技术改动，测试难以对应到功能，建议同时写清用户可见的变化；二是“已知缺陷列表”只写编号不写现象，测试需要额外查单，建议在清单里直接写一句现象描述。
必填与选填：哪些字段不能空
必填项的设计目标是保证测试人员拿到清单就能开始工作，不依赖额外沟通。下面把模板字段分为必填和选填两类，并给出缺失时的处理规则。
| 类别 | 字段 | 缺失时的处理 |
|---|---|---|
| 必填 | 提测单编号、需求/任务名称、提测版本号、开发负责人、提测日期、本次变更内容概述、涉及模块/页面、冒烟测试结果、测试环境地址/标识、部署分支与构建号、已知缺陷列表、回退触发条件与步骤、提测人确认、测试接收人 | 任一项为空，测试可拒收提测，退回开发补齐后再进入测试 |
| 选填 | 关联需求/缺陷链接、影响的下游模块或接口、不在本次范围的内容、自测用例执行情况、自测发现并已修复的问题、自测未覆盖的部分及原因、依赖服务与配置变更、测试数据准备情况、已知限制与待确认项、风险等级与影响判断、数据与配置回退注意事项、交接时间与备注 | 按项目实际情况填写，空着不阻断提测，但测试可在接收时要求补充 |
必填缺失的阻断规则建议写成明确约定：测试接收人核对清单，发现必填项为空或明显不实，直接在提测单上标注缺失项并退回，开发补齐后重新提交，测试周期从补齐时间起算。这样能避免“先提测再补信息”导致测试空转。
必填范围可以按项目规模调整。小型迭代或单点修复，可把“影响的下游模块”“风险等级”降为选填，保留版本、环境、冒烟结果和回退方案这几项底线字段；涉及核心链路、多人协作或对外发布的项目，建议把影响模块、已知限制和风险判断也列为必填。调整时以团队评审结论为准，并在模板版本记录中注明，避免不同项目各用一套口径。
填写示例：一次完整的提测记录
以下示例为演示情景，用于说明各字段如何落地，其中的项目、版本和人员信息均为虚构。示例背景设定为：某业务系统的订单模块完成一次优惠券叠加逻辑调整，开发在提交测试前填写提测清单。
| 字段 | 示例填写内容 |
|---|---|
| 提测单编号 | ORDER-2024-0312-01 |
| 需求/任务名称 | 订单结算支持多张优惠券叠加使用 |
| 提测版本号 | feature/coupon-stack 分支，构建号 20240312.3 |
| 开发负责人 | 张明（主）、李华（协助接口联调） |
| 提测日期与预计测试周期 | 2024-03-12，预计测试 3 天 |
| 关联需求/缺陷链接 | 需求单 REQ-1088，设计文档见需求单附件 |
| 本次变更内容概述 | 结算页支持选择多张优惠券并自动计算最优组合；订单详情展示优惠明细；新增优惠券叠加校验接口 |
| 涉及模块/页面 | 结算页、订单确认页、订单详情页 |
| 影响的下游模块或接口 | 优惠券核销服务、订单金额计算服务、支付回调中的金额校验 |
| 不在本次范围的内容 | 优惠券发放规则、退款时的优惠分摊逻辑本次未改 |
| 自测用例执行情况 | 执行 18 条，通过 17 条，1 条因测试数据不足未执行 |
| 冒烟测试结果 | 通过，覆盖下单、支付、订单详情主流程 |
| 自测发现并已修复的问题 | 多券叠加时金额精度丢失，已改为按分计算，建议重点复测金额展示 |
| 自测未覆盖的部分及原因 | 退款场景未自测，依赖退款服务测试环境未就绪 |
| 测试环境地址/标识 | 测试环境 test-order-02 |
| 部署分支与构建号 | feature/coupon-stack，构建号 20240312.3 |
| 依赖服务与配置变更 | 优惠券服务升级至联调版本；新增配置项 coupon.stack.enable=true |
| 测试数据准备情况 | 已准备 3 个测试账号和 6 张不同类型优惠券，可直接使用 |
| 已知缺陷列表 | BUG-2201：三张以上优惠券叠加时排序偶发不稳定，不阻塞主流程；BUG-2203：优惠明细文案在英文环境下未翻译 |
| 已知限制与待确认项 | 单笔订单最多叠加 3 张券，上限值待产品最终确认 |
| 风险等级与影响判断 | 中：影响结算金额计算，涉及支付链路，需重点回归 |
| 回退触发条件 | 结算金额计算错误导致下单失败，或支付回调校验大面积报错 |
| 回退步骤 | 关闭配置项 coupon.stack.enable，回滚至上一发布构建 20240308.1，重启订单服务 |
| 数据与配置回退注意事项 | 本次无表结构变更；回退后需清理测试环境已生成的叠加优惠订单数据 |
| 提测人签字/确认 | 张明，2024-03-12 14:30 |
| 测试接收人 | 王芳 |
| 交接时间与备注 | 2024-03-12 15:00；口头约定优先验证金额计算相关用例 |
对照字段说明可以看到，示例中的“变更内容概述”同时写了用户可见变化和新增接口，“已知缺陷列表”直接写了现象和是否阻塞，“回退步骤”落到配置项和构建号，测试人员据此可以独立开始工作。示例中的风险等级和上限值属于该项目当时的判断，其他项目填写时应按自身情况评估，不直接照搬。
模板的调整与维护方法
提测清单需要随项目类型和团队协作方式调整，否则容易变成走过场的表格。调整和维护可以从增删字段、版本管理、评审节奏和工具落地四个方面入手。
按项目类型增删字段时，先判断项目特征。纯前端页面调整，可弱化“依赖服务与配置变更”，强化“涉及页面”和“兼容性说明”；涉及接口或数据结构的改动，应保留并细化“影响的下游模块”“数据与配置回退注意事项”；对外发布或核心链路项目，建议增加“灰度与监控观察项”。增删字段时同步更新字段说明和必填规则，保持三处一致。
模板版本与变更记录建议在模板文件顶部维护一张小表，记录版本号、修改人、修改内容和生效日期。字段含义变化、必填范围调整都属于版本变更，需要通知使用方；仅修正错别字或示例可记为小版本。这样当测试人员发现清单口径不一致时，能快速定位是哪一版模板。
模板评审与更新节奏可以按固定周期进行，例如每个季度或每个大版本结束后，收集测试接收人的反馈，统计哪些字段经常为空、哪些字段从未被使用，据此决定保留、调整或删除。评审参与方包括开发负责人和测试负责人，结论写入变更记录。
模板落地到协作工具时，可以把提测清单作为提测工作项的固定描述模板或子任务字段，让开发在提交提测时按模板填写，测试在同一个工作项中接收、核对和记录结果。在ONES中，提测可以作为需求下的工作项类型管理，通过工作项描述模板固化上述七组字段，配合状态流转区分“待提测、测试中、测试完成”，并用关联关系挂接需求单和缺陷单。这样清单内容、提测状态和缺陷记录在同一处可查，减少在文档和工具之间来回对照的成本。具体字段配置和状态方案需按团队现有流程设定，本文不展开工具配置细节。
常见问题
提测清单和测试用例、测试计划是什么关系？
三者处在测试流程的不同位置。提测清单是开发向测试交接的入口材料，说明这次提测改了什么、部署在哪、自测到什么程度；测试计划安排本轮测试的范围、资源和排期；测试用例描述具体怎么验证。实际使用时，提测清单里的“涉及模块/页面”和“影响的下游模块”通常作为测试计划圈定回归范围的输入，测试人员再据此挑选或补充用例。清单本身不承载用例内容，也不替代测试计划。
提测被退回后，测试周期从什么时候开始算？
建议在团队约定中写明：测试接收人核对清单，发现必填项为空或明显不实，标注缺失项后退回，开发补齐并重新提交，测试周期从补齐时间起算。这样处理的目的是避免测试人员在信息不全的情况下空转。若团队希望保留原计划时间，可以约定退回只影响该提测单的排期，由测试负责人和开发负责人协商后调整，并把结论记录在提测单备注中。
多个开发共同提交一次提测，清单怎么填？
建议指定一名主提测人负责汇总填写，其他开发在各自负责的字段上提供内容。基本信息中的“开发负责人”写主负责人并标注协助人；变更范围按功能点分条列出，并注明每条对应的开发；自测结果和已知缺陷由各开发提供后合并。交接确认由主提测人签字，测试接收人只对主提测人反馈问题，减少多头沟通。若改动之间耦合较深，也可以拆成多张提测单分别提交，由测试按依赖顺序安排验证。
紧急修复的提测，清单可以简化到什么程度？
紧急修复可以压缩选填项，但版本号、部署分支与构建号、变更内容概述、冒烟结果、已知缺陷、回退触发条件与步骤这几项建议保留，因为它们直接决定测试能否定位构建、判断影响范围以及在出问题时快速回退。简化方式可以是先提交核心字段开始测试，测试过程中补齐其余内容，并在提测单备注中写明“紧急提测、字段后补”。事后建议复盘这次简化是否造成信息缺失，据此决定是否调整必填范围。
把提测清单放进协作工具后，还需要保留文档版本吗？
需要保留模板本身的版本记录，但单次提测的内容以工作项中的记录为准。模板版本记录用于说明字段含义和必填范围何时调整过，便于不同时期的提测单对照；单次提测的填写内容、状态流转和关联的需求、缺陷都留在工作项里，形成可追溯的记录。在ONES中，可以把提测作为需求下的工作项类型管理，用工作项描述模板固化字段，通过状态区分待提测、测试中、测试完成，并关联需求单和缺陷单，具体字段配置和状态方案按团队现有流程设定。
