Acceptance Criteria

---
name: acceptance-criteria
description: 使用 GWT 场景式或规则式清单编写验收标准，含质量核查、复杂度分级与边界覆盖
when_to_use: |
  用于已拆解的 Story/Task 写验收标准、明确上线条件时调用。
  典型触发："写验收标准" / "GWT 场景" / "上线条件是什么" / "AC 怎么写"。
  不用于：需求范围讨论（用 requirement-analysis）/ 测试用例设计（用 test-case-design 在 qa 阶段，AC 是输入它是产物）。
user-invocable: true
allowed-tools: [Read, Write, Edit, Glob, Grep]
---

# 验收标准编写技能

## 格式选择

根据验收内容选择合适的格式：

| 格式 | 适用场景 | 示例 |
|------|---------|------|
| **GWT 场景式** | 用户行为场景、操作流、交互逻辑 | 用户点击提交按钮后的响应 |
| **规则式清单** | 业务约束、配置规则、数据校验、合规要求 | 密码强度规则、字段长度限制 |

同一 Story 允许两种格式混合使用。

## GWT 场景式格式

```gherkin
AC-{序号}: {标准名称}

Given {前置条件/上下文}
  And {补充条件}（可选）
When {用户操作/系统事件}
Then {预期结果/系统响应}
  And {补充结果}（可选）
```

### 编写规范

- 每条 AC 只允许**一个 When/Then 对**（防止 AC 过于宽泛）
- 使用**主动语态**（"系统显示提示信息" 而非 "提示信息被系统显示"）
- 避免 "not" 否定句（用正面描述替代："按钮置灰不可点击" → "按钮处于禁用状态"）
- 使用**简单句**，不用从句嵌套
- 条件和结果必须**可量化**或**可观测**

### GWT 示例

```gherkin
AC-01: 成功提交任务

Given 用户已登录且剩余使用次数 ≥ 1
  And 用户已完成必填配置项
When 用户输入内容并点击"提交"
Then 系统在 60 秒内返回处理结果
  And 用户剩余使用次数减少 1

AC-02: 使用次数不足时的操作限制

Given 用户已登录且剩余使用次数为 0
When 用户访问功能页面
Then "提交"按钮处于禁用状态
  And 页面显示提示"使用次数已用完，请升级套餐"
  And 显示套餐升级入口链接
```

## 规则式清单格式

```markdown
AC-{序号}: {规则名称}

规则：
- [ ] {规则1}
- [ ] {规则2}
- [ ] {规则3}
```

### 规则式示例

```markdown
AC-03: 文章输入校验规则

规则：
- [ ] 原文字数不少于 100 字
- [ ] 原文字数不超过 50,000 字
- [ ] 不接受纯图片/纯链接内容
- [ ] 输入内容自动过滤 HTML 标签
- [ ] 检测到敏感词时阻止提交并提示具体原因
```

## 复杂度分级数量标准

根据 Story 规模确定最少 AC 数量：

| Story 规模 | 最少 AC 数量 | 说明 |
|-----------|-------------|------|
| 1-2 Story Points | 3-4 条 | 正常路径 + 1-2 个异常路径 |
| 3-5 Story Points | 4-6 条 | 正常路径 + 多个异常/边界场景 |
| 8 Story Points | 5-8 条 | 全面覆盖，含并发和状态边界 |
| 13+ Story Points | **先拆分 Story** | Story 过大，不直接写 AC |

## 边界条件覆盖清单

每个功能须评估以下 5 类边界条件，按需编写对应 AC：

### 输入边界
| 条件 | 测试内容 | AC编号 |
|------|---------|--------|
| 空值 | 输入为空时的处理 | |
| 最小值 | 最小有效输入 | |
| 最大值 | 最大有效输入（如文章字数上限） | |
| 非法格式 | 特殊字符、SQL 注入、XSS | |
| 超长输入 | 超过最大长度限制 | |

### 权限边界
| 条件 | 测试内容 | AC编号 |
|------|---------|--------|
| 未登录 | 未认证用户访问 | |
| 无权限 | 角色权限不足 | |
| 过期会话 | Token 过期后操作 | |

### 并发边界
| 条件 | 测试内容 | AC编号 |
|------|---------|--------|
| 重复提交 | 快速连续点击 | |
| 并发修改 | 多人同时编辑同一资源 | |
| 资源竞争 | 任务队列满时的处理 | |

### 状态边界
| 条件 | 测试内容 | AC编号 |
|------|---------|--------|
| 初始状态 | 首次使用时的默认值 | |
| 中间状态 | 任务处理中的操作限制 | |
| 终态 | 已完成/已取消后的操作限制 | |
| 异常状态 | 网络断开/服务不可用 | |

### 无障碍边界
| 条件 | 测试内容 | AC编号 |
|------|---------|--------|
| 键盘导航 | Tab 键可遍历所有交互元素 | |
| 屏幕阅读器 | 关键操作有 ARIA 标签 | |

## 质量核查四步骤

AC 编写完成后，逐条执行以下检查：

| 步骤 | 检查问题 | 通过？ |
|------|---------|-------|
| **清晰** | 无歧义，不同团队成员理解一致？ | ☐ |
| **简洁** | 无冗余信息，每条 AC 聚焦单一验证点？ | ☐ |
| **可测试** | QA 可直接据此编写自动化测试用例？ | ☐ |
| **结果导向** | 关注用户价值和业务结果，而非技术实现细节？ | ☐ |

## 编写规范汇总

1. 每个 Story 至少 3 条 AC（复杂 Story 参照复杂度分级数量标准）
2. 必须覆盖**正常路径** + 至少 **2 类异常路径**
3. 使用可量化指标（时间、字数、比例、百分比）
4. 编写完成后执行质量核查四步骤
5. 如有影响 AC 方向的关键疑问 → **先向用户确认，再继续编写**；次要问题用 `[待确认]` 占位
6. 在响应消息中呈现完整 AC 清单；收到用户确认信号后，写入对应需求文档的 AC 区块