提测是研发把完成开发自测的版本或功能提交给测试团队，并附上版本范围、变更说明、测试环境与准入条件，由测试方确认是否接收并开始测试的交接动作。它标志测试执行的起点，核心是“提交—确认—接收”的交接，理解提测需要同时看清它包含什么、不包含什么，以及它与冒烟测试、转测、验收之间的区别。
要点总览（TL;DR）
- 提测是研发把完成自测的版本或功能提交给测试方，并附上版本范围、变更说明、测试环境和准入条件，由测试方确认接收或退回的交接动作。
- 提测覆盖“提交—确认—接收”这一段交接，开发自测细节、测试执行、缺陷修复闭环和测试报告属于相邻环节。
- 一次合格的提测包含版本与变更范围、提测说明与自测结论、测试环境与依赖、准入条件与接收标准、双方责任人五类要素。
- 提测与冒烟测试、转测、验收的区别在于发生时机、主导方和解决的问题不同，混用会造成责任边界模糊。
- 常见误解是把提测当成开发完成、测试开始或可省略的口头通知，后果是漏测、退回无记录和无效验证。
提测的准确定义
提测是研发方向测试方发起的一次交接请求：研发提交一个可测试的版本、功能或变更范围，测试方依据随附信息判断是否具备测试条件，并给出接收或退回的结论。这个定义包含三个关键点：发起方是研发，接收方是测试，动作性质是交接而非测试本身。
提测的对象通常是一个版本、一组功能或一次变更范围，而不是某一行代码或某一个孤立缺陷。提测的结果有两种：测试方确认接收，版本进入测试执行；测试方判断条件不足，退回研发补充说明或修复阻塞问题。无论哪种结果，提测都完成了一次明确的责任交接，让“开发做完了”转化为“测试可以开始了”。
需要区分的是，提测描述的是交接动作，测试执行描述的是接收之后的验证活动。把提测理解为“提交测试”这一动作本身，比理解为“测试阶段”更准确，也更便于在团队协作中界定谁在什么时候做什么。
提测包括什么、不包括什么
提测的边界可以用一句话概括：它覆盖“提交—确认—接收”这一段交接，不覆盖交接之前的开发自测细节，也不覆盖接收之后的测试执行与缺陷闭环。明确这条边界，能避免把提测单当成万能表单，也能避免把测试阶段的所有问题都归到提测环节。
提测不等于开发完成。开发完成是研发侧的内部状态，提测则要求研发把完成情况转化为测试方可验证的信息，包括变更范围、自测结论、环境地址和已知风险。缺少这些信息，测试方无法判断版本是否具备测试条件，提测就退化为一句口头通知。
提测也不等于开始测试。测试方接收提测之后，才进入测试执行；接收之前的检查、退回和补充，都属于提测环节。缺陷修复闭环与验证跟踪、测试报告与质量评估是提测之后的相邻环节，本文不展开其具体流程和编制方法，只在与提测衔接处点到为止。
| 环节 | 与提测的关系 | 本文处理方式 |
|---|---|---|
| 开发自测 | 提测的前置条件，其结果作为提测说明的一部分 | 作为准入信息提及，不展开自测方法 |
| 提测交接 | 本文核心，包含提交、确认、接收或退回 | 重点解释定义、要素与流程 |
| 测试执行 | 提测被接收后开始 | 仅说明起点关系，不展开用例设计 |
| 缺陷修复与验证 | 测试执行中发现的缺陷进入修复闭环 | 属相邻主题，本文不展开 |
| 测试报告与质量评估 | 测试执行后的总结环节 | 属相邻主题，本文不展开 |
一次提测由哪些要素组成
一次合格的提测需要准备五类要素。它们共同回答测试方最关心的几个问题：测什么、凭什么判断可以测、在哪里测、达到什么条件才算接收、找谁对接。要素齐全的提测能显著减少来回沟通，要素缺失则容易在接收环节被退回。
| 要素 | 包含内容 | 作用 |
|---|---|---|
| 版本与变更范围 | 版本号、涉及的功能模块、需求或任务清单、影响范围 | 让测试方确定测试对象和回归范围，避免漏测或重复测 |
| 提测说明与自测结论 | 本次改动说明、开发自测覆盖情况、已知问题与风险 | 把研发侧的完成情况转化为测试方可判断的信息 |
| 测试环境与依赖 | 环境地址、账号、数据准备方式、依赖服务或配置 | 保证测试方拿到版本后能直接开始验证 |
| 准入条件与接收标准 | 冒烟通过、阻塞缺陷清零、关键功能可用等约定 | 作为测试方接收或退回的判断依据 |
| 提测人与测试接收人 | 双方责任人及沟通方式 | 明确交接责任，便于退回和补充时快速对接 |
这五项要素中，准入条件与接收标准最容易被省略，也最影响交接效率。团队可以在项目内约定一套通用的接收标准，再针对特殊版本补充附加条件。标准的作用是让接收判断有据可依，而不是增加审批层级；标准的具体内容由团队根据业务风险约定，行业层面并不存在统一的提测准入认证要求。
当提测信息需要被记录和流转时，团队通常会用提测单或类似的交接记录承载上述要素，并在项目管理或测试管理工具中关联对应的版本、需求和测试任务。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，也支持测试计划的规划和执行、将用例分配执行人，这些能力可以承接提测被接收之后的测试组织工作；提测单本身的具体承载方式需结合团队实际配置确定。
提测与冒烟测试、转测、验收的区别
提测常与几个相邻概念混用，混用的后果是责任边界模糊。下面按“发生在什么时候、由谁主导、解决什么问题”三个口径做对照。
| 概念 | 发生时机 | 主导方 | 核心作用 |
|---|---|---|---|
| 提测 | 开发自测完成后、测试执行开始前 | 研发发起，测试确认 | 完成版本交接，确认是否具备测试条件 |
| 冒烟测试 | 提测被接收前后均可进行 | 测试方为主 | 用少量关键用例快速判断版本基本可用性 |
| 转测 | 版本从一个测试阶段或环境移交到下一个 | 按团队约定 | 描述测试阶段之间的移交，范围可大于单次提测 |
| 验收测试 | 测试执行后期、发布前 | 业务方或客户方 | 确认版本是否满足业务需求并具备发布条件 |
提测与冒烟测试的关系最紧密：冒烟测试常被用作提测的准入检查，冒烟不通过则提测被退回。两者的区别在于，提测是交接动作，冒烟测试是验证动作；提测可以由研发发起，冒烟测试通常由测试方执行。
提测与转测的用法差异主要在范围。提测强调研发向测试的提交，转测强调版本在测试流程中的阶段移交，一个转测节点可能包含多次提测，也可能发生在测试团队内部。团队在使用时应在项目约定中固定用词，避免同一动作出现多种叫法。
提测与验收测试的区别在目的和主导方。提测解决“能不能开始测”，验收测试解决“能不能发布”；提测由研发和测试对接，验收测试通常由业务方或客户方参与。把验收测试的要求提前塞进提测标准，会让提测变得过重；把提测当成验收，则会遗漏业务侧的确认。
一个提测例子与常见误解
以下是一个演示情景，用于说明提测的完整过程。某团队完成订单模块的优惠券叠加功能开发，研发在自测通过后发起提测：提交版本号与变更范围，说明涉及的下单、结算两个页面，附上自测覆盖的主要场景和一处已知的边界问题，提供测试环境地址与测试账号，并按团队约定声明冒烟用例已通过。测试方接收后先核对变更范围与环境可用性，运行冒烟用例，确认关键路径可用，随后正式接收提测并安排测试执行。若冒烟发现下单主流程不可用，测试方退回提测，研发修复后重新提交，这一轮退回同样属于提测环节的正常结果。
这个例子中有三个常见误解值得纠正。
第一个误解是“提测即开发完成”。开发完成只是研发侧的状态，提测要求把完成情况整理成测试方可验证的信息。省略变更范围和自测结论，测试方只能凭经验猜测测什么，容易漏测受影响模块，回归范围也会失控。
第二个误解是“提测即测试开始”。提测被接收才进入测试执行，接收前的核对和冒烟是提测环节的一部分。把两者混为一谈，会让测试方在环境不可用或主流程不通时被迫“先测起来”，实际是在替研发承担准入判断的责任。
第三个误解是“提测单可以省略，口头说一声就行”。口头提测缺少版本范围、环境信息和接收结论的记录，退回时说不清缺什么，事后也难以追溯某个版本何时具备测试条件。用一份结构化的提测记录承载要素，并在工具中关联版本、需求和测试任务，能让交接状态可查。ONES 测试管理支持未通过的用例快速创建缺陷任务，缺陷任务在测试与研发团队间流转，也支持自动生成测试报告，这些能力承接的是提测接收之后的执行与反馈环节，与提测交接本身形成前后衔接。
误解带来的后果是具体的：漏测导致问题流入发布环节，退回无记录导致责任不清，准入标准缺失导致测试方反复做无效验证。把提测当作一次有输入、有判断、有结论的交接来对待，这些后果大多可以在交接环节被拦住。
常见问题
提测被退回后，应该重新提测还是直接进入测试？
退回意味着测试方判断当前版本不具备测试条件，需要研发补充信息或修复阻塞问题后重新提交。重新提测时应针对退回原因逐项说明处理结果，例如补充变更范围、修复主流程缺陷、更新环境地址，而不是只重新发一条通知。测试方再次核对后给出接收结论，这一轮往返仍属于提测环节。
如果退回原因只是说明信息缺失、版本本身可用，团队也可以约定由研发补充材料后直接确认接收，减少重复提交。具体采用哪种方式，取决于团队对交接记录完整性的要求。
团队规模较小、研发和测试坐在一起，还需要正式的提测记录吗？
沟通成本低的团队可以简化提测形式，但版本范围、自测结论和接收结论这三项信息仍建议留下记录。它们的价值不在于审批，而在于事后能回答“这个版本什么时候具备测试条件”“当时测了哪些范围”。简化可以体现在记录载体上，例如用一条任务评论代替独立表单，而不是完全省略。
当版本节奏加快、多人并行或出现线上问题时，缺少记录的代价会明显上升。团队可以根据版本频率和协作人数决定记录的详细程度。
冒烟测试应该在提测接收前做还是接收后做？
两种做法都存在，取决于团队把冒烟定位为准入检查还是接收后的第一轮验证。放在接收前，冒烟结果直接作为接收或退回的判断依据，交接更严谨；放在接收后，提测先完成交接，冒烟作为测试执行的第一步，流程更轻。
无论放在哪一侧，都应明确冒烟不通过时版本回到研发，而不是由测试方继续往下测。把这一条写进团队约定，可以避免接收判断和测试执行的责任混在一起。
提测准入标准应该由谁制定？
准入标准通常由研发和测试共同约定，测试方提出可验证的条件，研发方确认这些条件在提交时能够满足。标准内容与业务风险相关，例如核心交易类功能可能要求主流程冒烟通过、阻塞缺陷清零，内部工具类功能可以放宽。
标准宜少而明确，便于每次提测时快速判断。行业层面并不存在统一的提测准入认证要求，团队按自身业务约定即可，并随版本情况定期回顾调整。
提测信息在工具中如何承载，才能和后续测试衔接？
常见做法是用提测单或交接记录承载版本范围、自测结论、环境和接收结论，并在工具中关联对应的版本、需求和测试任务，让交接状态可查。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，也支持测试计划的规划和执行、将用例分配执行人，可以承接提测被接收之后的测试组织工作；提测单本身的具体承载方式需结合团队实际配置确定。
衔接的关键是让提测记录与测试计划指向同一个版本，避免测试方在执行时找不到对应的变更范围。
