# Acceptance Testing

> 上线前业务方/产品方验收时使用。适用于功能交付确认、UAT、发布会签。融合 BDD Given-When-Then、Specification by Example、ATDD。

- Skill: `zhaoxuya520/acceptance-testing` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add zhaoxuya520/acceptance-testing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zhaoxuya520/acceptance-testing/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: zhaoxuya520 (https://skillmd.com/u/zhaoxuya520)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zhaoxuya520/acceptance-testing

---


# 验收测试（Acceptance Testing / UAT）

参考来源：Gojko Adzic《Specification by Example》、Dan North BDD、Cucumber/Gherkin、ISTQB Foundation。

## 适用场景

- 功能开发完毕需要业务方验收
- UAT（User Acceptance Testing）
- 上线前发布会签
- 客户演示前的预演
- 合同 / SLA 验收

## 核心原则

```text
1. 验收 = 业务方签字
   不是"QA 测过"，是"PM/业务/客户认为达标"

2. Given-When-Then 通用语言
   业务方读得懂，开发能实现，QA 能验证

3. 一个场景一个故事
   不要"一个验收覆盖 5 个流程"

4. 验收标准来自 PRD
   不是 QA 临时加的，是需求阶段就定的

5. 验收前所有 P0 / P1 Bug 关闭
   不要带 Bug 上验收会
```

## Given-When-Then 标准格式

```gherkin
功能：订单退款

场景：用户对已支付订单发起全额退款
  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）

```text
1. PRD 定义验收标准（PM + QA + Dev 共同评审）
   ↓
2. 验收标准转 Given-When-Then
   ↓
3. 开发按验收标准写代码 + 自动化验收测试
   ↓
4. 自动化验收测试通过 = 功能完成
   ↓
5. UAT 阶段业务方再验收一次（端到端）
```

## 验收类型

### Alpha 验收
- 内部团队验收
- 通常在开发完成后立即
- 范围：核心功能正确性

### Beta 验收
- 真实用户参与（小范围）
- 范围：可用性、用户体验、边缘场景

### UAT（User Acceptance Test）
- 业务方 / 客户参与
- 范围：业务流程完整性、合规性

### 合同验收
- 客户签字确认
- 范围：合同 / SLA 列出的全部条目

## 验收执行流程

```text
1. 准备阶段（验收前 2~5 天）
   □ 所有功能已开发完
   □ 所有 P0 / P1 Bug 已关闭
   □ Sanity 套件 100% 通过
   □ 验收环境数据准备
   □ 验收账号准备
   □ 验收会议安排
   ↓
2. 验收会议（30 分钟 ~ 2 小时）
   □ PM 介绍变更范围
   □ QA 演示主路径
   □ 业务方按 Given-When-Then 走查
   □ 业务方提问 / 提改进建议
   ↓
3. 验收结论
   □ 通过：可上线
   □ 有条件通过：列出限制 / 后续改进
   □ 不通过：返工
   ↓
4. 记录
   □ 验收会议纪要
   □ 改进项跟踪
   □ 业务方签字确认
   ↓
5. 上线
```

## 验收会议纪要模板

```markdown
# UAT 会议纪要

## 基本信息
- 日期：
- 主持：
- 参与：[PM, QA, 业务方代表]
- 验收范围：[功能清单]

## 验收清单（按 PRD 验收标准）

| # | 验收标准 | 状态 | 备注 |
|---|---------|------|------|
| AC1 | 用户能成功创建订单 | ✅ |  |
| AC2 | 库存不足时给出明确提示 | ✅ |  |
| AC3 | 支持微信 / 支付宝两种支付方式 | ⚠️ | 支付宝需要补充 |

## 业务方反馈
- [改进建议 1]
- [改进建议 2]

## 已知问题（业务方知悉，不阻塞上线）
- [问题 + 影响 + 计划修复时间]

## 验收结论
- [ ] 通过
- [ ] 有条件通过（条件：...）
- [ ] 不通过（原因：...）

## 签字
- 业务方：
- PM：
- 日期：
```

## 验收数据准备

```text
真实数据：
  - 真实用户场景模拟
  - 涵盖典型业务规模
  - 包含各种状态（新 / 老 / 异常）

边界数据：
  - 最大订单
  - 最小订单
  - 跨年订单
  - 多币种订单

环境：
  - 与生产相似（数据规模 / 配置 / 第三方）
  - 但隔离（不污染生产）
```

## 验收时的"业务陷阱"

```text
1. PRD 没写但"理所当然"
   - 业务方会临时提出"这个不是应该 XXX 吗"
   - 应对：UAT 前再核对一遍 PRD

2. 边缘业务场景
   - 业务方知道但没写进 PRD
   - 应对：让业务方写"业务异常清单"

3. 性能 / 体验感受
   - "感觉慢" / "操作不顺"
   - 应对：定量化（X 秒内 / Y 步内）

4. 合规 / 审计要求
   - 业务方知道但开发不知道
   - 应对：PRD 中加 "合规要求" 章节
```

## 质量自检

```text
□ 每条 PRD 验收标准都有 Given-When-Then
□ 验收标准 PM/QA/Dev 共同评审过
□ 验收前所有 P0 / P1 Bug 关闭
□ Sanity 套件通过
□ 验收数据准备充分
□ 验收账号准备好
□ 验收会议有纪要
□ 业务方签字确认
□ 已知问题列表清晰
□ 改进项跟踪到位
```

## 常见坑

1. **验收 = 再测一遍**——不是，验收是业务方"签字"
2. **验收标准模糊**——"易用 / 友好 / 高效"无法验证
3. **PM 不参与定义验收标准**——QA 自己写，业务不认
4. **带 P0 Bug 上验收**——浪费业务方时间
5. **验收当场提新需求**——应该走变更流程
6. **没有 Given-When-Then**——业务方不理解
7. **会议纪要不签字**——后期扯皮无依据
8. **验收数据不真实**——业务方说 "在我们真实场景下不行"
9. **不准备边界数据**——只演示主路径
10. **改进项不跟踪**——验收后被遗忘

## 配套模板

- `templates/acceptance-criteria-template.md` — 验收标准 + Given-When-Then 场景 + UAT 会议纪要 + 签字模板

## 与其他 skill 的协作

```text
上游：
  产品经理工作流（PRD） → 验收标准
  test-case-design → 用例覆盖每条验收标准
  regression-testing → Sanity 通过

平行：
  exploratory-testing → 业务方探索式

下游：
  bug-reporting → 验收发现的问题
  test-report → 验收结论纳入报告
  quality-gate → 验收通过 = 放行条件之一
  上线流程
```