验收测试计划模板：业务场景、验收准则与签字记录

验收测试计划模板的核心是一张“业务场景—验收准则”主表，再配业务方职责表和签字记录表。主表逐条写清场景、触发条件、前置数据、执行步骤、预期结果和可度量的验收准则；职责表明确业务方、测试方、开发方在评审、执行、判定、签字四个环节的分工；签字记录表留存结论、日期与遗留问题。下面给出可直接复制的空白表、字段口径、必填规则和一条完整填写示例。

要点总览（TL;DR）

• 验收测试计划模板由三张表组成：业务场景与验收准则主表、业务方职责分工表、验收结论与签字记录表，三张表通过场景编号关联。
• 主表必填场景编号、场景名称、触发条件、前置数据、执行步骤、预期结果、验收准则、判定方式和责任人，缺任一项不进入验收排期。
• 验收准则要写成包含对象、条件和阈值的判断句，用数量、时间、状态或比例替代“正常”“流畅”这类模糊表述。
• 签字记录在每轮验收执行后填写，包含验收轮次、结论、遗留问题、签字人与日期；有条件通过时遗留问题转为必填。
• 模板按项目规模裁剪选填字段和场景数量，判定口径保持不变；需求变更后追加签字轮次，不覆盖原记录。

可复制空白模板：三张表组成一份验收测试计划

三张表分工明确：主表回答“验什么、怎么算通过”，职责表回答“谁在哪个环节做什么”，签字表回答“谁在何时确认了什么结论”。填写时先完成主表，再据主表场景分配职责，最后在验收执行后补签字记录。三张表通过“场景编号”关联，主表一条场景对应职责表中的一行分工和签字表中的一条结论记录。

表一：业务场景与验收准则主表

场景编号	业务场景名称	关联需求	触发条件	前置数据	执行步骤	预期结果	验收准则（可度量）	判定方式	证据	责任人
AC-001
AC-002
AC-003

表二：业务方职责分工表

场景编号	角色	评审	执行	判定	签字	备注
AC-001	业务方
AC-001	测试方
AC-001	开发方

表三：验收结论与签字记录表

场景编号	验收轮次	验收结论	遗留问题	业务方签字	测试方签字	签字日期
AC-001
AC-002

字段说明：每个字段填什么、怎么判定

字段说明与上表表头一一对应。填写时先保证场景类字段描述清楚“在什么条件下做什么”，再保证准则类字段能被第三方按同一口径复核。准则写得含糊，签字环节就容易反复。

业务场景类字段

• 场景编号：全文唯一标识，建议用“AC-序号”，职责表和签字表引用同一编号。
• 业务场景名称：用业务语言描述用户要完成的一件事，例如“新客户首次下单并完成支付”，避免写成功能模块名。
• 关联需求：填写需求编号或需求标题，便于追溯场景来源和后续变更影响。
• 触发条件：场景开始的前提，例如“客户状态为待激活且已提交订单”。
• 前置数据：执行前需准备好的账号、订单、配置或历史数据，注明数量和状态。
• 执行步骤：按操作顺序编号，写到他人可照做即可，不展开脚本细节。
• 预期结果：描述系统与业务上应出现的状态，包括页面提示、数据变化和通知对象。

验收准则类字段

• 验收准则（可度量）：写成可观察、可计数的判断句，包含对象、条件和阈值。例如“订单状态在支付成功后10秒内变为已支付，且库存扣减数量等于订单数量”。
• 判定方式：说明如何得出结论，如比对页面数据与后台记录、核对通知内容、抽样检查若干条记录。
• 证据：写明留存什么，如截图、导出数据、日志片段或签字确认单，注明保存位置。
• 责任人：对该场景验收结论负责的人，通常为业务方指定代表。

可度量准则的写法要点：用数量、时间、状态或比例替代“正常”“流畅”“符合预期”；一条准则只判断一件事；阈值来源写清是需求约定还是业务惯例，避免验收时临时改口径。

职责与签字类字段

• 角色：业务方、测试方、开发方，按场景分别填写，不按部门笼统代替。
• 评审/执行/判定/签字：四个环节分别填“主责”“参与”或“知会”，明确谁做决定、谁提供支持。
• 验收结论：填“通过”“有条件通过”或“不通过”，有条件通过须在遗留问题中写明条件。
• 遗留问题：记录未关闭事项、责任人和计划关闭时间。
• 签字与日期：由实际确认人签署并填写日期，代签需注明授权关系。

当验收场景、准则和签字记录需要在多个角色间流转时，可以把主表作为项目协作工具中的工作项清单承载：每条场景对应一个工作项，准则和证据放在字段或文档中，判定后更新状态并附上签字记录，业务方在同一处查看进度，减少表格多版本并存。ONES 的项目工作项与文档能力可用于这种承载方式，具体配置按团队现有流程设定。

必填与选填：哪些字段缺失就不能进入验收

必填字段的作用是保证每条场景都能被独立复核和签字。缺少必填项的场景不进入验收执行，先补填再排期；选填字段按项目类型补充，不影响验收成立。

表	必填字段	选填字段	缺失处理
主表	场景编号、业务场景名称、触发条件、前置数据、执行步骤、预期结果、验收准则、判定方式、责任人	关联需求、证据	缺任一必填项，该场景退回补充，不进入验收排期
职责表	场景编号、角色、判定环节责任人、签字环节责任人	评审、执行环节分工、备注	缺判定或签字责任人，视为职责未落实，不得开始验收
签字表	场景编号、验收轮次、验收结论、签字人、签字日期	遗留问题	结论为“有条件通过”时，遗留问题转为必填

选填字段的适用情形：关联需求在需求管理系统已有记录时可只填编号；证据在低风险内部场景可简化为“判定人留存”，对外交付或涉及资金、合规的场景应写明具体证据。补填规则是“谁提出谁补充、责任人确认”，补填后由测试方复核一次再放行。

填写示例：一条业务场景从描述到签字

以下示例演示一条场景在三张表中的完整记录，字段与前述表头一致。示例为演示情景，数值仅用于说明写法。

字段	填写内容
场景编号	AC-001
业务场景名称	新客户首次下单并完成在线支付
关联需求	REQ-1023 新客户下单流程
触发条件	客户账号状态为已激活，购物车中有1件可售商品
前置数据	测试客户账号1个、可售商品1件（库存10）、支付沙箱账号1个
执行步骤	1. 登录客户账号；2. 将商品加入购物车；3. 提交订单；4. 选择在线支付并完成付款；5. 查看订单状态与库存
预期结果	订单生成并显示“已支付”，库存由10减为9，客户收到下单成功通知
验收准则（可度量）	支付成功后10秒内订单状态变为“已支付”；库存扣减数量等于订单数量1；通知在支付成功后1分钟内送达
判定方式	比对订单页面状态、后台库存记录与通知记录，三项同时满足判为通过
证据	订单详情截图、库存导出记录、通知截图，存放于验收记录目录
责任人	业务方代表（订单业务负责人）

该场景在职责表中记录为：业务方负责判定与签字，测试方负责执行与证据留存，开发方在评审环节确认前置数据可用。在签字表中记录为：第一轮验收结论“通过”，无遗留问题，业务方与测试方于验收当日签字。若首轮发现库存未扣减，则结论填“不通过”，遗留问题写明“库存扣减缺失，开发方于X日前修复后复验”，第二轮再签。

调整与维护：按项目规模裁剪并随版本更新

模板需要按项目情况裁剪，但裁剪的是选填字段和场景数量，不是判定口径。小规模内部项目可减少证据细度、合并职责表行；对外交付、涉及资金或合规的项目应保留完整证据和双人签字。

• 按规模裁剪：场景少于10条的项目可省略职责表中的评审分工列，在备注中说明；跨团队项目保留全部四环节分工。
• 按验收类型裁剪：功能验收侧重状态与数据准则；性能或容量验收在主表准则中补充响应时间和并发量口径，判定方式改为抽样测量。
• 版本更新与留痕：需求变更时先改主表对应场景，记录变更日期、变更人和影响范围；已签字的场景变更后需重新判定并追加签字轮次，不覆盖原记录。
• 最小字段集：复用模板时至少保留场景编号、场景名称、触发条件、执行步骤、预期结果、验收准则、判定方式、责任人，以及签字表的结论、签字人和日期。
• 定期回顾：每个版本验收结束后清理失效场景，把反复出现的准则口径沉淀为团队约定，下次复用时直接引用。

维护动作可以落到固定的协作节奏：版本发布前由测试负责人检查主表必填项是否齐全，验收结束后核对签字表是否覆盖全部场景，遗留问题转入下一轮跟踪。将场景清单、准则和签字记录放在同一项目空间中维护，能让变更留痕和复验轮次有据可查，ONES 的工作项状态流转与文档版本记录可承担这一环节，具体字段和流程按团队习惯配置。

常见问题

验收测试计划里的业务场景要写到多细才算够用？

判断标准是他人能否照着执行并得出同一结论。一条场景至少写清触发条件、前置数据、执行步骤和预期结果，让不熟悉该业务的测试人员也能独立操作。场景名称用业务语言描述用户要完成的一件事，例如“新客户首次下单并完成支付”，比写成功能模块名更容易让业务方确认范围。步骤写到操作顺序清楚即可，具体脚本和自动化实现放在测试用例层面，不必塞进验收计划。

验收准则和需求里的功能描述有什么区别？

需求描述说明系统要提供什么，验收准则说明用什么可观察的结果判定它已经可用。准则要包含对象、条件和阈值，例如“支付成功后10秒内订单状态变为已支付，库存扣减数量等于订单数量”。一条准则只判断一件事，阈值来源写清是需求约定还是业务惯例。这样在签字环节，业务方和测试方按同一口径复核，减少临时改判。

业务方在验收中只负责最后签字吗？

签字只是最后一个环节。职责表把业务方的工作拆到评审、执行、判定、签字四步：评审阶段确认场景和准则是否覆盖真实业务；执行阶段提供前置数据或业务侧配合；判定阶段对结论负责；签字阶段确认结果。测试方通常负责执行与证据留存，开发方在评审环节确认前置数据可用。职责表按场景逐行填写，避免用部门名称笼统代替具体责任人。

验收过程中需求变更了，已经签过字的场景怎么处理？

先修改主表中对应场景，记录变更日期、变更人和影响范围。已签字的场景在变更后需要重新判定，并在签字表中追加新一轮记录，保留原有签字内容不覆盖。如果变更只影响选填字段，例如关联需求编号，可由责任人确认后直接更新。遗留问题随复验轮次继续跟踪，关闭时补记关闭日期。

小项目也要用完整的三张表吗？

可以裁剪，但裁剪的是选填字段和场景数量，判定口径和最小字段集要保留。场景少于10条的内部项目可省略职责表中的评审分工列，在备注中说明；对外交付、涉及资金或合规的项目建议保留完整证据和双人签字。最小字段集包括场景编号、场景名称、触发条件、执行步骤、预期结果、验收准则、判定方式、责任人，以及签字表的结论、签字人和日期。