Test Case Writer

---
name: test-case-writer
description: |
  測試案例產生器 — 把 PRD 的驗收標準（Acceptance Criteria）與規則，轉成 QA 可直接執行的
  測試案例：正常路徑、邊界值、異常路徑、併發/冪等、權限與安全。
  當使用者說「幫我寫測試案例」、「這份 PRD 的 test case」、「QA 測試計畫」、「幫我補測試」、
  「這功能怎麼測」、「寫測試」、「test cases」、「test plan」、「QA checklist」時，
  一定要使用這個 skill。即使使用者只是丟一份 PRD、一段 AC、一個功能描述說
  「幫我想想怎麼驗收」、「工程做完了要測什麼」，也應觸發此 skill。
  這個 skill 輸入 PRD / AC，輸出結構化測試案例；不寫 PRD、不寫程式碼，只負責「怎麼驗證」。

  接力關係：enterprise-prd-writer / prd-writer 產出 AC → 本 skill 把 AC 展開成測試案例 →
  QA 據以執行。PRD 的每條 Given/When/Then 是輸入，測試案例是輸出。
---

# 測試案例產生器（Test Case Writer）

## 在流程的位置

```
prd-writer / enterprise-prd-writer  ──→  AC（Given/When/Then + Edge Case）
                                              ↓
                                    【test-case-writer】← 展開成可執行測試案例
                                              ↓
                                          QA 執行 / 自動化
```

**分工界線：**

| Skill | 負責 | 不負責 |
|---|---|---|
| enterprise-prd-writer | 定義需求與 AC | 不展開逐條測試步驟 |
| **test-case-writer** | 把 AC 展開成可執行測試案例 | 不改需求、不寫測試程式碼 |

如果輸入的 PRD 沒有 AC，先提醒使用者「這份缺 AC，測試案例會不完整」，
再就現有資訊盡量產出，並標出哪些是因缺 AC 而假設的。

---

## 核心原則

### 1. 每條 AC 至少展開成一組正常 + 邊界 + 異常

一條 Given/When/Then 不等於一個測試案例。它至少要拆成：

- **正常路徑（Happy Path）**：條件成立，預期結果發生
- **邊界值（Boundary）**：剛好在門檻上、門檻 ±1、最小/最大值
- **異常路徑（Negative）**：條件不成立、輸入非法、前置失敗

PRD 的 AC 若已附 Edge Case，每個 Edge Case 至少對應一個測試案例。

### 2. 每個測試案例都可獨立執行、可判定通過與否

一個合格的測試案例，QA 拿到不必再問任何人就能跑。所以每條必須有：

- **前置條件（Precondition）**：具體到可以建立的資料狀態
- **測試步驟（Steps）**：一步一動作
- **預期結果（Expected）**：明確、可觀察、可判定 pass/fail

禁止「驗證功能正常」這種無法判定的預期結果。

### 3. 用 PRD 的具體數值，不要自己發明

AC 的 Given 有數值（如「起點權益 10,000、上限 5%」），測試案例就用那些數值，
並補上邊界值（=門檻、門檻 ±1）。PRD 沒給的數值標 `TBD`，不要憑空填。

### 4. 覆蓋這幾類，缺一要說明

正常、邊界、異常之外，金融/後台類需求還要覆蓋：

- **併發 / 冪等**：同請求送兩次、兩人搶同資源
- **權限**：不同角色、未授權存取
- **安全**：越權、繞過前置檢查
- **狀態機**：非法狀態轉換、同時觸發多規則的優先級

某類不適用要寫「本功能無此類（因為…）」，不要默默略過。

---

## 執行流程

### Step 0：讀 PRD，盤點 AC 與規則

讀完輸入的 PRD / AC，列出所有 `R-xx` 規則與 `AC-xx`。若沒有編號，自己編。
確認每條 AC 的 Given 有沒有具體數值——沒有的先標記，測試案例會受影響。

### Step 1：為每條 AC 展開測試案例

依「正常 → 邊界 → 異常」逐條展開。每個測試案例給一個 ID（`TC-<AC>-<序號>`）。

### Step 2：補跨 AC 的整合與非功能測試

- **整合流程**：跨多條規則的完整 user flow 走一遍
- **併發/冪等/權限/安全**：依核心原則 4 補上

### Step 3：標優先級與類型

- **優先級**：P0（阻斷發布）/ P1（重要）/ P2（次要）
- **類型**：正常 / 邊界 / 異常 / 併發 / 權限 / 安全 / 整合

### Step 4：輸出（見下方格式）+ 覆蓋率自檢

---

## 輸出格式

### 測試案例表（每個功能區塊一張）

```
### 提現 — 新地址鎖定（對應 AC-01 / R-03）

| TC ID | 類型 | 前置條件 | 步驟 | 預期結果 | Pri |
|---|---|---|---|---|---|
| TC-01-1 | 正常 | 用戶 10:00 新增地址 X | 20:00 對 X 發起提現 | 拒絕，提示隔日 10:00 解鎖；記錄稽核 | P0 |
| TC-01-2 | 邊界 | 地址 X 新增剛滿 24h | 對 X 發起提現 | 放行 | P0 |
| TC-01-3 | 邊界 | 地址 X 新增差 1 分鐘滿 24h | 對 X 發起提現 | 拒絕 | P0 |
| TC-01-4 | 異常 | 刪除 X 後再重新加入 | 對 X 發起提現 | 依 Open Q 定義（標 TBD） | P1 |
```

欄位規範：

- **前置條件**：具體到 QA 能照著建資料
- **步驟**：一步一動作，用祈使句
- **預期結果**：可觀察、可判定 pass/fail
- **類型 / Pri**：見上方定義

### 覆蓋率摘要（表格之後）

```
## 測試覆蓋率摘要

| 規則 / AC | 正常 | 邊界 | 異常 | 併發 | 權限 | 備註 |
|---|---|---|---|---|---|---|
| R-03 新地址鎖定 | ✅ | ✅ | ✅ | N/A | N/A | 冪等不適用 |

未覆蓋 / 待補：
- [因缺 AC 而無法展開的項目]
- [標 TBD 的數值，待 PRD 定案後補測試]
```

### 缺口提示（必要）

明確列出：① PRD 缺 AC 的功能 ② Given 沒有具體數值的 AC
③ 標 Open Question 尚未定案、因而測試案例只能標 TBD 的項目。

---

## 語言與格式偏好

- 一律繁體中文，專有名詞保留英文
- 表格優先；老花友善：段落短、重點粗體
- P0 用粗體標示

## 輸出載體

- 預設輸出在對話中（QA 拿去即用的工作稿）
- 測試案例超過 30 條，或使用者要求「整理成文件 / 看板」時，
  改用 `interactive-html-report` 輸出成可篩選（依類型/優先級/狀態）、可勾選追蹤的互動報告