zhaoxuya520 验收测试（Acceptance Testing / UAT）
参考来源：Gojko Adzic《Specification by Example》、Dan North BDD、Cucumber/Gherkin、ISTQB Foundation。
适用场景
- 功能开发完毕需要业务方验收
- UAT（User Acceptance Testing）
- 上线前发布会签
- 客户演示前的预演
- 合同 / SLA 验收
核心原则
1. 验收 = 业务方签字
不是"QA 测过"，是"PM/业务/客户认为达标"
2. Given-When-Then 通用语言
业务方读得懂，开发能实现，QA 能验证
3. 一个场景一个故事
不要"一个验收覆盖 5 个流程"
4. 验收标准来自 PRD
不是 QA 临时加的，是需求阶段就定的
5. 验收前所有 P0 / P1 Bug 关闭
不要带 Bug 上验收会
Given-When-Then 标准格式
功能：订单退款
场景：用户对已支付订单发起全额退款
Given 用户 user_a 有一个订单 ORD-123
And 订单状态为 paid
And 订单金额为 100 USD
When 用户在订单详情页点击 "申请全额退款"
And 选择退款原因 "商品有质量问题"
And 点击 "确认退款"
Then 订单状态变为 refunded
And 用户余额增加 100 USD
And 用户收到退款成功的邮件通知
And 系统记录退款审计日志
验收标准 vs 测试用例
| 维度 | 验收标准 | 测试用例 |
|---|---|---|
| 受众 | 业务方 / PM / 客户 | 开发 / QA |
| 语言 | 业务语言 | 技术语言 |
| 数量 | 少（覆盖业务规则） | 多（覆盖技术细节） |
| 阶段 | 需求阶段定义 | 测试阶段编写 |
| 通过标准 | "业务认为达标" | "符合预期" |
→ 验收标准是测试用例的"宪法"，每条验收标准至少 1 个 P0 测试用例
ATDD（Acceptance Test-Driven Development）
1. PRD 定义验收标准（PM + QA + Dev 共同评审）
↓
2. 验收标准转 Given-When-Then
↓
3. 开发按验收标准写代码 + 自动化验收测试
↓
4. 自动化验收测试通过 = 功能完成
↓
5. UAT 阶段业务方再验收一次（端到端）
验收类型
Alpha 验收
- 内部团队验收
- 通常在开发完成后立即
- 范围：核心功能正确性
Beta 验收
- 真实用户参与（小范围）
- 范围：可用性、用户体验、边缘场景
UAT（User Acceptance Test）
- 业务方 / 客户参与
- 范围：业务流程完整性、合规性
合同验收
- 客户签字确认
- 范围：合同 / SLA 列出的全部条目
验收执行流程
1. 准备阶段（验收前 2~5 天）
□ 所有功能已开发完
□ 所有 P0 / P1 Bug 已关闭
□ Sanity 套件 100% 通过
□ 验收环境数据准备
□ 验收账号准备
□ 验收会议安排
↓
2. 验收会议（30 分钟 ~ 2 小时）
□ PM 介绍变更范围
□ QA 演示主路径
□ 业务方按 Given-When-Then 走查
□ 业务方提问 / 提改进建议
↓
3. 验收结论
□ 通过：可上线
□ 有条件通过：列出限制 / 后续改进
□ 不通过：返工
↓
4. 记录
□ 验收会议纪要
□ 改进项跟踪
□ 业务方签字确认
↓
5. 上线
验收会议纪要模板
# UAT 会议纪要
## 基本信息
- 日期：
- 主持：
- 参与：[PM, QA, 业务方代表]
- 验收范围：[功能清单]
## 验收清单（按 PRD 验收标准）
| # | 验收标准 | 状态 | 备注 |
|---|---------|------|------|
| AC1 | 用户能成功创建订单 | ✅ | |
| AC2 | 库存不足时给出明确提示 | ✅ | |
| AC3 | 支持微信 / 支付宝两种支付方式 | ⚠️ | 支付宝需要补充 |
## 业务方反馈
- [改进建议 1]
- [改进建议 2]
## 已知问题（业务方知悉，不阻塞上线）
- [问题 + 影响 + 计划修复时间]
## 验收结论
- [ ] 通过
- [ ] 有条件通过（条件：...）
- [ ] 不通过（原因：...）
## 签字
- 业务方：
- PM：
- 日期：
验收数据准备
真实数据：
- 真实用户场景模拟
- 涵盖典型业务规模
- 包含各种状态（新 / 老 / 异常）
边界数据：
- 最大订单
- 最小订单
- 跨年订单
- 多币种订单
环境：
- 与生产相似（数据规模 / 配置 / 第三方）
- 但隔离（不污染生产）
验收时的"业务陷阱"
1. PRD 没写但"理所当然"
- 业务方会临时提出"这个不是应该 XXX 吗"
- 应对：UAT 前再核对一遍 PRD
2. 边缘业务场景
- 业务方知道但没写进 PRD
- 应对：让业务方写"业务异常清单"
3. 性能 / 体验感受
- "感觉慢" / "操作不顺"
- 应对：定量化（X 秒内 / Y 步内）
4. 合规 / 审计要求
- 业务方知道但开发不知道
- 应对：PRD 中加 "合规要求" 章节
质量自检
□ 每条 PRD 验收标准都有 Given-When-Then
□ 验收标准 PM/QA/Dev 共同评审过
□ 验收前所有 P0 / P1 Bug 关闭
□ Sanity 套件通过
□ 验收数据准备充分
□ 验收账号准备好
□ 验收会议有纪要
□ 业务方签字确认
□ 已知问题列表清晰
□ 改进项跟踪到位
常见坑
- 验收 = 再测一遍——不是，验收是业务方"签字"
- 验收标准模糊——"易用 / 友好 / 高效"无法验证
- PM 不参与定义验收标准——QA 自己写，业务不认
- 带 P0 Bug 上验收——浪费业务方时间
- 验收当场提新需求——应该走变更流程
- 没有 Given-When-Then——业务方不理解
- 会议纪要不签字——后期扯皮无依据
- 验收数据不真实——业务方说 "在我们真实场景下不行"
- 不准备边界数据——只演示主路径
- 改进项不跟踪——验收后被遗忘
配套模板
templates/acceptance-criteria-template.md— 验收标准 + Given-When-Then 场景 + UAT 会议纪要 + 签字模板
与其他 skill 的协作
上游：
产品经理工作流（PRD） → 验收标准
test-case-design → 用例覆盖每条验收标准
regression-testing → Sanity 通过
平行：
exploratory-testing → 业务方探索式
下游：
bug-reporting → 验收发现的问题
test-report → 验收结论纳入报告
quality-gate → 验收通过 = 放行条件之一
上线流程