ACCEPTANCE SCRIPT / 业务验收
把“开发完成”改写成可执行的业务任务
验收脚本从一项真实任务开始：谁在什么前提下完成哪些操作，系统和业务现场应出现什么结果。正常流程与关键异常都通过，才比“页面已经做完”更接近可上线。
SCOPE / 项目范围
理解方法的适用要点。
- 01角色与前提
写明操作身份、权限、设备、初始状态和需要准备的数据。
- 02任务步骤
按业务动作描述过程，不把点击某个按钮当作最终目标。
- 03异常分支
覆盖撤回、重复提交、数据缺失、接口失败和权限不足等关键情况。
- 04结果证据
约定页面状态、消息、记录、导出或现场反馈中应看到什么。
DECISIONS / 关键判断
结合当前任务，核对关键判断。
先验收高风险任务
优先验证跨角色、跨系统和不可逆的数据操作。
脚本使用真实样例
脱敏后的业务数据比随手填写的测试文字更容易暴露问题。
失败结果也要明确
异常出现时系统应阻止什么、提示什么、保留什么记录。
WORKED EXAMPLE / 填写示例
一条合格的验收脚本至少包含五个要素
示例任务：客服创建安装工单，师傅完成现场作业，客户确认结果。
客户、地址、服务项目和可派师傅数据已经准备完成。
客服派单，师傅接单并上传现场材料，客户确认完工。
缺少照片不能完工；客户拒绝确认时工单进入待处理状态。
角色操作时间、材料、状态变化和处理人均能追溯。
- 01从真实任务提取角色与前提
- 02补齐正常步骤和高风险异常
- 03用约定证据逐条记录通过结果
BOUNDARY / 项目说明
业务验收脚本定义可观察结果，不代替专项测试。
FAQ / 常见问题
怎样让验收不再依赖临场判断
验收脚本应该什么时候写？
在核心流程和原型确认时就开始写。越晚定义结果，越容易在上线前才发现双方理解不同。
每个功能都要单独写脚本吗？
不需要按按钮穷举。先覆盖能代表业务闭环、关键权限、异常处理和数据结果的任务。
NEXT / 继续了解
从相关服务、案例或资料继续判断。
可复制的任务验收脚本
可直接阅读下表，再复制空白模板填写。填写示例仅用于解释方法，不是真实客户案例、报价、合同条款或交付承诺；实际范围与责任由双方确认。
窄屏下可左右滑动表格，查看完整填写示例。
| 记录项 | 怎样填写 | 填写示例 |
|---|---|---|
| 任务条件 | 记录版本、环境、账号角色和前置数据 | R1测试环境，调度账号，一张待处理工单 |
| 正常路径 | 操作步骤与预期业务结果 | 派单后状态更新，师傅可查看且有操作记录 |
| 异常路径 | 至少一条权限或失败场景与预期 | 重复提交不得重复创建业务动作 |
| 执行记录 | 实际结果、证据位置、问题编号和执行人 | 未通过时关联问题记录，修复后按同脚本复测 |
| 签认边界 | 确认人、日期、未结项与阶段结论 | 未结项影响核心任务时不预填通过 |
在上方文本框中全选复制，粘贴到你的文档后填写；无需登录或提交联系方式。
PROJECT CONTEXT / 项目沟通
先说明实际情况，再讨论适合的范围。
不用先整理完整需求文档，说明当前做法、使用角色和首期目标即可；预算暂不确定时，也可以先沟通范围。