提测清单的更新和维护，关键在于把它当作一份有状态、有责任人、有触发条件的活台账：字段固定、状态流转清晰、每次变更留痕并通知到测试与开发双方。本文按“定义字段与状态—明确谁在何时更新—走通一次提测示例—建立定期核对与收口—完成检查”的顺序，给出可直接套用的表格和操作规则，适用于测试负责人或研发协作负责人建立并持续维护一份可信的提测清单。
要点总览（TL;DR）
- 先固定字段与状态：提测版本/批次、范围与需求单号、构建号、自测结论、提测人、提测时间、测试负责人设为必填，状态按待提测、已提测待验证、验证中、验证通过、打回、关闭流转，每个状态写明进入与退出条件。
- 更新按事件触发而非定期想起：提测、开始验证、给出结论、打回重提、关闭五个时点各对应一次明确更新，由提测人与测试负责人分别负责。
- 打回后重提复用原记录并追加一轮提测信息，保留每轮构建号与缺陷单号，回溯时能看清同一批次改了几轮、每轮改了什么。
- 维护靠固定节奏：每日或每轮测试结束时核对验证中、超时未接收和打回未跟进的记录，版本收口时逐条处置未关闭记录，收口后不再新增。
- 用字段完整性、状态准确性、更新时效、历史留痕、与执行结果一致性五项做完成检查，任一项不通过就回到对应环节补录。
提测清单该包含哪些字段和状态
提测清单首先要解决“记什么”和“进度怎么表示”两个问题。字段设计的原则是：凡是影响测试能否开始、结论能否追溯的信息都设为必填；只影响个别批次判断的信息设为选填。状态设计的原则是：每个状态都有明确的进入条件和退出条件，避免同一状态在不同人手里含义不同。
必填与选填字段
| 字段 | 填写要求 | 必填/选填 | 说明 |
|---|---|---|---|
| 提测版本/批次 | 版本号加批次序号，如 V2.3-批次1 | 必填 | 清单的主键之一，同一版本可分多批提测 |
| 提测范围与需求单号 | 列出本批次包含的需求、修复单号及简要说明 | 必填 | 决定测试范围，也是与需求、任务关联的依据 |
| 代码分支或构建号 | 分支名或构建产物编号 | 必填 | 保证测试对象可定位、可复现 |
| 自测结论 | 开发自测通过项与已知问题 | 必填 | 测试开始前的前置判断依据 |
| 提测人 | 实际提交提测的开发人员 | 必填 | 打回与重提时的对接人 |
| 提测时间 | 提交提测的具体时间 | 必填 | 用于计算验证时效 |
| 测试负责人 | 本批次验证的测试人员 | 必填 | 状态推进的责任人 |
| 环境与依赖 | 测试环境、依赖服务、数据准备情况 | 选填 | 环境特殊或存在外部依赖时填写 |
| 风险说明 | 已知风险、影响范围、规避建议 | 选填 | 存在高风险改动时填写 |
状态取值与流转条件
| 状态 | 进入条件 | 退出条件 |
|---|---|---|
| 待提测 | 批次已登记，开发尚未提交提测 | 开发提交提测并补齐必填字段，转入已提测待验证 |
| 已提测待验证 | 提测信息完整，测试负责人已确认接收 | 测试负责人开始执行验证，转入验证中 |
| 验证中 | 测试已开始执行用例 | 给出验证结论：全部通过转验证通过；发现问题需返工转打回 |
| 验证通过 | 本批次范围内用例执行完成且无阻断问题 | 完成关闭核对后转入关闭 |
| 打回 | 验证中发现阻断或范围性问题，需开发修复后重提 | 开发修复并重新提测，复用原记录追加新一轮，回到已提测待验证 |
| 关闭 | 验证通过且核对信息补齐 | 终态，不再流转，仅可查询 |
状态字段只允许按上表方向流转，回退只发生在“打回—重提”这一条路径上。任何一次状态变更都要同时写入变更时间和操作人，这是后续核对时效与留痕的基础。
谁在什么时点更新清单
清单长期不更新，通常不是没人负责，而是没有把更新绑定到具体事件上。可行的做法是按事件触发：每发生一个关键事件，由对应角色完成一次明确更新，而不是依赖定期“想起来去改”。
| 触发事件 | 更新角色 | 更新动作 | 更新后状态 |
|---|---|---|---|
| 登记新批次 | 提测人 | 填写版本批次、范围与需求单号、分支或构建号、自测结论、提测时间 | 待提测 |
| 正式提交提测 | 提测人 | 补齐必填字段，通知测试负责人 | 已提测待验证 |
| 开始验证 | 测试负责人 | 确认接收，记录开始验证时间 | 验证中 |
| 给出验证结论 | 测试负责人 | 填写通过范围、遗留问题及对应缺陷单号 | 验证通过或打回 |
| 打回后重提 | 提测人 | 追加新一轮提测信息：修复内容、新构建号、重提时间 | 已提测待验证 |
| 关闭 | 测试负责人 | 补齐关闭核对信息，确认无未处置记录 | 关闭 |
更新时点要与测试执行节奏对齐：提测人应在提交提测的同一时间完成登记，测试负责人在接收和给出结论的当天完成状态更新。若验证跨多日，可在每轮测试结束时补充一次进展说明，状态保持不变。
打回后重新提测，建议复用原记录并追加一轮提测信息，而不是新建一条记录。复用原记录可以保留同一批次的返工次数和每轮构建号，回溯时能看清“这批改了几轮、每轮改了什么”；新建记录则会让同一批次的历史被拆散。若返工范围已实质变成另一个批次，再按新批次单独登记。
一次提测的完整更新示例
以下为演示情景，用于说明每次更新应写什么，不对应真实项目数据。
背景：版本 V2.3 包含三个需求和两个缺陷修复，开发决定分两批提测，第一批为两个需求加一个修复。
第一次登记
提测人登记记录：版本批次填“V2.3-批次1”；提测范围列明需求单号 REQ-101、REQ-102 与修复单号 BUG-208；分支填 feature/v2.3-batch1；自测结论写“主流程自测通过，REQ-102 的导出功能未覆盖”；提测时间填写提交时刻；测试负责人填当轮测试人员。此时状态为待提测，提交后转为已提测待验证。
验证中发现问题
测试负责人开始执行后，状态改为验证中，并记录开始时间。执行中发现 REQ-102 导出功能存在数据缺失，属于范围性问题，于是为该问题创建缺陷单并回填单号，状态改为打回，同时在记录中写明打回原因、影响范围和需修复项。此时清单回答的是“这批被打回了、因为什么”，具体修复过程由缺陷单承载。
重提与历史保留
开发修复后重提，复用原记录追加第二轮：修复内容写“修复导出数据缺失”，新构建号替换为最新构建，重提时间填写提交时刻，状态回到已提测待验证。原第一轮的提测信息、打回原因和缺陷单号保留在记录中，形成两轮历史。
关闭时补齐核对信息
第二轮验证通过后，测试负责人将状态改为验证通过，再补齐关闭核对：本批次范围内用例执行完成、遗留问题均已关联缺陷单并确认处置方式、无未关闭的阻断问题。核对完成后状态改为关闭，记录进入只读查询状态。
维护机制：定期核对与版本收口
单条记录更新到位，只能保证个体准确；整份清单长期可信，还需要固定的核对节奏和收口规则。
每日或每轮测试结束时做一次清单核对，动作包括：检查处于验证中的记录是否都有当日进展说明；检查已提测待验证的记录是否超过约定时限仍未开始验证；检查打回记录是否已有人跟进修复。核对产出是一份待处理清单，而不是口头提醒。
版本收口时，对未关闭记录逐条处置：能关闭的补齐核对信息后关闭；确实无法在本版本完成的，写明延期原因和目标版本，避免记录悬空。收口完成后，该版本清单不再接受新增记录。
清单与测试用例执行记录、缺陷记录要保持可对应的关系：清单回答“哪个批次、什么状态、谁负责”，用例执行记录回答“覆盖了哪些范围、结果如何”，缺陷记录回答“发现了什么问题、是否闭环”。三者通过需求单号、构建号和缺陷单号互相引用，核对时才能交叉验证。清单归档后按版本批次保留，历史查询以版本号和需求单号为入口。
在工具承载上，这类登记与状态流转可以放在工作项与测试管理流程中完成。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，形成测试流程闭环；支持自定义用例属性以适配不同业务场景；支持为不同用户组以及用例库、测试计划单独配置权限。将提测批次作为工作项登记、把验证结论与缺陷任务关联，可以让清单状态与执行记录、缺陷记录保持在同一流程内。具体字段配置与权限设置需结合所选版本核验。
完成检查：清单是否可用的判断标准
判断清单维护是否到位，可以按以下检查表逐项核对。任一项不通过，回到对应环节补录，而不是在检查表上标注“已知悉”。
| 检查维度 | 检查项 | 不通过时的处理 |
|---|---|---|
| 字段完整性 | 所有记录必填字段无空缺，提测范围能对应到需求或修复单号 | 由提测人补齐缺失字段 |
| 状态准确性 | 每条记录的状态与实际情况一致，无长期停留在验证中却无进展的记录 | 由测试负责人核实后更新状态或补充进展 |
| 更新时效 | 提测、开始验证、给出结论均在约定时限内完成更新 | 查明延迟原因，补录并记录延迟情况 |
| 历史留痕 | 打回重提的记录保留各轮提测信息、构建号和缺陷单号 | 补录缺失轮次信息，禁止覆盖历史 |
| 结果一致性 | 清单状态与用例执行记录、缺陷记录可对应，验证通过的批次无未处置阻断问题 | 交叉核对后修正清单或推动缺陷处置 |
检查频率可与维护节奏一致：每轮测试结束做一次轻量核对，版本收口做一次完整检查。检查结果直接决定该版本清单能否归档，也决定下一批次提测时是否需要先补齐上一批的遗留记录。
常见问题
提测清单和缺陷单、测试用例执行记录之间怎么分工，避免重复记录？
三者回答不同问题，通过单号互相引用即可，不需要互相复制内容。提测清单回答“哪个批次、什么状态、谁负责”，记录版本批次、提测范围、构建号、提测人与测试负责人；用例执行记录回答“覆盖了哪些范围、结果如何”；缺陷记录回答“发现了什么问题、是否闭环”。
操作上，提测清单只回填需求单号、构建号和缺陷单号，具体修复过程留在缺陷单里。核对时以需求单号和构建号为线索交叉验证，清单状态与执行结果不一致时，先查执行记录再修正清单。
团队规模小、提测频率低，还需要这么细的字段和状态吗？
可以按实际协作成本裁剪，但裁剪的是字段数量，不是状态含义。小团队可把环境与依赖、风险说明保持选填，甚至暂时不设；必填字段建议保留提测版本/批次、提测范围、构建号、提测人、提测时间和测试负责人，这几项决定了测试对象能否定位、结论能否追溯。
状态可以合并，例如把已提测待验证与验证中合并为一个状态，但合并后要写清进入和退出条件，避免同一状态在不同人手里含义不同。团队扩大或提测批次增多时，再拆回更细的状态。
提测被打回多次，记录越积越长，怎么处理才不影响查询？
打回重提复用原记录、追加轮次，是保留返工历史的前提，不建议每轮新建记录。记录变长后，可在记录内按轮次分段，每段固定写修复内容、新构建号、重提时间和对应缺陷单号，最新一轮放在最前或最后并保持一致。
如果返工范围已实质变成另一个批次，例如新增了原范围之外的需求，就按新批次单独登记，并在原记录中注明拆分去向。这样既保留了原批次的返工次数，也不会让一条记录承载两个批次的范围。
版本收口时还有记录停在验证中，应该关闭还是延期？
先判断这条记录卡在哪一步。若验证已实际完成、只是状态未更新，补齐结论和核对信息后关闭；若验证确实未完成，写明未完成原因、已覆盖范围和目标版本，按延期处置，不要为了收口强行关闭。
延期记录要在下一版本提测前先处理，避免上一批遗留记录与新批次混在一起。收口完成后该版本清单不再接受新增记录，只保留查询。
用工具承载提测清单时，需要关注哪些配置点？
关注三件事：清单字段能否按批次登记并区分必填与选填；状态能否按约定方向流转并记录变更时间与操作人；清单能否与需求、用例执行记录和缺陷任务建立关联，便于交叉核对。
ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，形成测试流程闭环；支持自定义用例属性以适配不同业务场景；支持为不同用户组以及用例库、测试计划单独配置权限。将提测批次作为工作项登记、把验证结论与缺陷任务关联，可以让清单状态与执行记录、缺陷记录保持在同一流程内。具体字段配置与权限设置需结合所选版本核验。
