---
source: ../../../../skills/atdd-assistant/acceptance-criteria-guide.md
source_version: 1.0.0
translation_version: 1.0.0
last_synced: 2026-02-05
status: current
---

# 驗收標準撰寫指南

**版本**: 1.0.0
**最後更新**: 2026-01-19

---

## 概述

驗收標準（AC）定義用戶故事被視為完成必須滿足的條件。良好撰寫的 AC 確保共同理解並啟用自動化測試。

---

## 用戶故事的 INVEST 準則

撰寫驗收標準前，確保用戶故事遵循 INVEST：

| 原則 | 描述 | 要問的問題 |
|------|------|----------|
| **I**ndependent 獨立 | 可以不依賴其他故事開發 | 「這需要先完成另一個故事嗎？」 |
| **N**egotiable 可協商 | 細節可以討論，非合約 | 「範圍有彈性嗎？」 |
| **V**aluable 有價值 | 傳遞價值給使用者或企業 | 「為什麼這很重要？」 |
| **E**stimable 可估算 | 團隊可以估算 | 「我們理解需要什麼嗎？」 |
| **S**mall 小 | 小到可以在一個 Sprint 內完成 | 「我們可以在 < 1 週內完成嗎？」 |
| **T**estable 可測試 | 可以通過測試驗證 | 「我們怎麼知道它完成了？」 |

---

## 驗收標準格式

### Given-When-Then（推薦）

```markdown
### AC-1: [標準名稱]
**Given** [前置條件 / 初始情境]
**And** [額外前置條件]
**When** [動作 / 事件]
**And** [額外動作]
**Then** [預期結果]
**And** [額外預期結果]
**But** [預期結果的例外]
```

### 範例

```markdown
### AC-1: 使用有效憑證成功登入
**Given** 我在登入頁面
**And** 我有一個已註冊帳號
**When** 我輸入我的電子郵件 "user@example.com"
**And** 我輸入我的密碼 "correctpassword"
**And** 我點擊登入按鈕
**Then** 我應該被重新導向到儀表板
**And** 我應該看到帶有我名字的歡迎訊息
```

---

## 完整用戶故事範本

```markdown
## 用戶故事: [US-XXX] [標題]

**身為** [角色/人物]
**我想要** [功能/能力]
**以便** [好處/價值]

---

## 驗收標準

### AC-1: [Happy path - 主要成功情境]
**Given** [前置條件]
**When** [動作]
**Then** [預期結果]

### AC-2: [替代路徑]
**Given** [不同前置條件]
**When** [動作]
**Then** [不同預期結果]

### AC-3: [錯誤處理]
**Given** [前置條件]
**When** [無效動作]
**Then** [錯誤處理 / 復原]

### AC-4: [邊界案例]
**Given** [邊界條件]
**When** [動作]
**Then** [適當行為]

---

## 範圍外
- [明確不包含的功能]
- [延後至未來的增強]
- [未涵蓋的變體]

---

## 技術備註
- [實作限制]
- [依賴]
- [效能需求]
- [安全考量]

---

## 開放問題
- [ ] [需要澄清的問題]
- [ ] [需要驗證的假設]

---

## 元資料
- **優先級**: [高/中/低]
- **估算**: [故事點數]
- **Sprint**: [Sprint 編號]
- **相關規格**: [SPEC-XXX 如適用]
```

---

## 撰寫良好的驗收標準

### DO's 和 DON'Ts

| 應該做 | 不應該做 |
|--------|---------|
| 從使用者角度撰寫 | 從系統角度撰寫 |
| 使用商業語言 | 使用技術術語 |
| 具體且明確 | 模糊或抽象 |
| 包含可衡量的結果 | 使用主觀用語 |
| 保持標準獨立 | 建立相互依賴 |
| 涵蓋 happy path 和邊界案例 | 只涵蓋 happy path |

### 好與壞的範例

```markdown
# ❌ 壞：模糊且不可測試
AC-1: 使用者可以輕鬆重設密碼
AC-2: 系統快速發送電子郵件
AC-3: 體驗對使用者友善

# ✅ 好：具體且可測試
AC-1: 密碼重設請求
Given 我在登入頁面
And 我有一個電子郵件為 "user@example.com" 的註冊帳號
When 我點擊「忘記密碼」
And 我輸入我的電子郵件 "user@example.com"
Then 我應該看到「重設連結已寄至您的電子郵件」
And 我應該在 5 分鐘內收到電子郵件
And 電子郵件應該包含 24 小時有效的重設連結

# ❌ 壞：技術術語
AC-1: POST /api/auth/reset 回傳 202
AC-2: Redis 佇列在 SLA 內處理
AC-3: SendGrid webhook 已確認

# ✅ 好：商業語言
AC-1: 重設電子郵件送達
Given 我已請求密碼重設
When 系統處理我的請求
Then 我應該在 5 分鐘內收到電子郵件
And 電子郵件應該來自 "noreply@example.com"
```

---

## 驗收標準類別

### 1. Happy Path

主要成功情境 - 一切正常運作時會發生什麼。

```markdown
### AC-1: 成功結帳
Given 我的購物車有商品
And 我有有效的付款方式
When 我完成結帳流程
Then 我的訂單應該被確認
And 我應該收到確認電子郵件
```

### 2. 錯誤處理

當事情出錯時會發生什麼。

```markdown
### AC-2: 付款被拒絕
Given 我的購物車有商品
When 我嘗試使用無效的卡片結帳
Then 我應該看到「付款被拒絕」
And 我的購物車仍應該包含我的商品
And 不應該建立訂單
```

### 3. 邊界案例

邊界條件和不尋常的情境。

```markdown
### AC-3: 購物車商品達到上限
Given 我的購物車有 100 件商品（允許的最大數量）
When 我嘗試新增另一件商品
Then 我應該看到「購物車已滿」
And 該商品不應該被新增
```

### 4. 授權

誰可以做什麼。

```markdown
### AC-4: 僅限管理員存取
Given 我以一般使用者身份登入
When 我嘗試存取管理面板
Then 我應該看到「存取被拒絕」
And 我應該被重新導向到首頁
```

### 5. 驗證

資料和輸入驗證。

```markdown
### AC-5: 電子郵件格式驗證
Given 我在註冊表單上
When 我輸入無效的電子郵件格式 "not-an-email"
Then 我應該看到「請輸入有效的電子郵件地址」
And 表單不應該被提交
```

### 6. 效能（如適用）

非功能性需求。

```markdown
### AC-6: 搜尋回應時間
Given 我在搜尋頁面
When 我搜尋「筆電」
Then 結果應該在 2 秒內顯示
And 應該顯示至少 10 個結果
```

---

## 驗收標準檢查清單

完成 AC 前，驗證：

```
清晰度
□ 新團隊成員能理解嗎？
□ 沒有技術術語嗎？
□ 足夠具體可以實作嗎？

可測試性
□ 可以自動化嗎？
□ 結果可衡量嗎？
□ 有明確的通過/失敗標準嗎？

完整性
□ Happy path 涵蓋了嗎？
□ 錯誤情境涵蓋了嗎？
□ 邊界案例考慮了嗎？
□ 安全影響處理了嗎？

獨立性
□ 可以獨立測試嗎？
□ 沒有依賴其他 AC 嗎？
□ 沒有假設測試順序嗎？

商業價值
□ 傳遞使用者價值嗎？
□ PO 能解釋為什麼重要嗎？
□ 與商業目標一致嗎？
```

---

## AC 反模式

| 反模式 | 範例 | 問題 | 修復 |
|--------|------|------|------|
| **模糊** | 「系統應該快」 | 不可衡量 | 「回應時間 < 2 秒」 |
| **技術性** | 「API 回傳 200 OK」 | 商業無法驗證 | 「使用者看到成功訊息」 |
| **複合** | 「使用者可以建立、編輯和刪除」 | 太多行為 | 拆分為獨立 AC |
| **缺少 Given** | 「當我點擊提交，訂單建立」 | 沒有情境 | 新增 Given 子句 |
| **缺少 Then** | 「假設我已登入，當我點擊登出」 | 沒有驗證 | 新增 Then 子句 |
| **相依** | 「假設 AC-1 通過...」 | 不獨立 | 自包含設定 |

---

## 各功能類型範例

### 使用者認證

```markdown
## 用戶故事: 使用者登入

**身為** 註冊使用者
**我想要** 登入我的帳號
**以便** 我可以存取我的個人化內容

### AC-1: 成功登入
Given 我在登入頁面
And 我有一個電子郵件為 "user@example.com" 的註冊帳號
When 我輸入我的電子郵件 "user@example.com"
And 我輸入我正確的密碼
And 我點擊登入按鈕
Then 我應該被重新導向到我的儀表板
And 我應該看到「歡迎回來，[使用者名稱]」

### AC-2: 密碼錯誤登入失敗
Given 我在登入頁面
When 我輸入我的電子郵件 "user@example.com"
And 我輸入錯誤的密碼
And 我點擊登入按鈕
Then 我應該看到「電子郵件或密碼無效」
And 我應該停留在登入頁面
And 密碼欄位應該被清空

### AC-3: 帳號鎖定
Given 我已失敗登入 3 次
When 我嘗試再次登入
Then 我應該看到「帳號暫時鎖定」
And 我應該可以選擇密碼重設
And 我應該在 15 分鐘內無法登入
```

### 電子商務結帳

```markdown
## 用戶故事: 套用折扣碼

**身為** 客戶
**我想要** 在我的訂單套用折扣碼
**以便** 我可以在購買時省錢

### AC-1: 有效的百分比折扣
Given 我的購物車商品總計 $100
When 我套用折扣碼 "SAVE10"
Then 我的總計應該減少到 $90
And 我應該看到「已套用 10% 折扣」

### AC-2: 有效的固定金額折扣
Given 我的購物車商品總計 $100
When 我套用折扣碼 "FLAT5"
Then 我的總計應該減少到 $95
And 我應該看到「已套用 $5 折扣」

### AC-3: 過期的折扣碼
Given 我的購物車有商品
When 我套用折扣碼 "EXPIRED2023"
Then 我應該看到「此折扣碼已過期」
And 我的總計應該保持不變

### AC-4: 最低購買要求
Given 我的購物車總計 $30
When 我套用折扣碼 "MIN50"（需要最低 $50）
Then 我應該看到「需要最低購買 $50」
And 我的總計應該保持不變

### AC-5: 每筆訂單一個折扣碼
Given 我已套用折扣碼 "SAVE10"
When 我嘗試套用另一個折扣碼 "SAVE20"
Then 我應該看到「每筆訂單只能使用一個折扣碼」
And 我原本的折扣應該保留
```

---

## 將 AC 對應到測試

### 從 AC 到 Gherkin

```markdown
### AC-1: 成功的密碼重設
**Given** 我有一個註冊帳號
**When** 我請求密碼重設
**And** 我點擊電子郵件中的連結
**And** 我輸入新的有效密碼
**Then** 我的密碼應該被更改
**And** 我應該能用新密碼登入
```

變成：

```gherkin
@AC-1
Scenario: 成功的密碼重設
  Given 我有一個電子郵件為 "user@example.com" 的註冊帳號
  When 我為 "user@example.com" 請求密碼重設
  And 我點擊電子郵件中的重設連結
  And 我輸入新密碼 "NewSecureP@ss123"
  And 我確認新密碼
  Then 我應該看到「密碼已成功更改」
  And 我應該能用 "NewSecureP@ss123" 登入
```

### 從 AC 到 FitNesse

```
!|Password Reset|
|email|action|result|
|user@example.com|request reset|link sent|
|user@example.com|click expired link|error: expired|
|user@example.com|click valid link|reset form shown|
|user@example.com|submit new password|password changed|
```

---

## 相關資源

- [ATDD 工作流程指南](./atdd-workflow.md)
- [ATDD 核心標準](../../../../core/acceptance-test-driven-development.md)
- [Gherkin 指南](../bdd-assistant/gherkin-guide.md)
- [需求助手](../requirement-assistant/SKILL.md)
