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