測試案例產生器(Test Case Writer)

SkillSecurity

Test case generator — converts a PRD's acceptance criteria and rules into test cases that QA can execute directly: happy paths, boundary values, error paths, concurrency/idempotency, permissions and security. Use this skill whenever the user says things like "幫我寫測試案例", "這份 PRD 的 test case", "QA 測試計畫

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the 測試案例產生器(Test Case Writer) skill

What this skill tells your AI

The instructions your AI receives, as published by skinnerlee1225/enterprise-prd-toolkit in skills/test-case-writer/SKILL.md and read by ahel’s review.

在流程的位置

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 輸出成可篩選(依類型/優先級/狀態)、可勾選追蹤的互動報告

Signals

GitHub stars
45
Forks
4
Last commit
Jul 2026
Advanced
Catalog kind
skill
Gateway key
test-case-writer
Source
github.com/skinnerlee1225/enterprise-prd-toolkit