Skip to content
Documentation
Skill

/test-case-writer

測試案例產生器 — 把 PRD 的驗收標準(Acceptance Criteria)與規則,轉成 QA 可直接執行的 測試案例:正常路徑、邊界值、異常路徑、併發/冪等、權限與安全。 當使用者說「幫我寫測試案例」、「這份 PRD 的 test case」、「QA 測試計畫」、「幫我補測試」、 「這功能怎麼測」、「寫測試」、「test cases」、「test plan」、「QA checklist」時, 一定要使用這個 skill。即使使用者只是丟一份 PRD、一段 AC、一個功能描述說 「幫我想想怎麼驗收」、「工程做完了要測什麼」,也應觸發此

From plugin
enterprise-prd-toolkit
454 skills
Install
$ npx -y skills add skinnerlee1225/enterprise-prd-toolkit --skill test-case-writer --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/test-case-writer

Context preview

The summary Claude sees to decide when to auto-load this skill.

測試案例產生器 — 把 PRD 的驗收標準(Acceptance Criteria)與規則,轉成 QA 可直接執行的 測試案例:正常路徑、邊界值、異常路徑、併發/冪等、權限與安全。 當使用者說「幫我寫測試案例」、「這份 PRD 的 test case」、「QA 測試計畫」、「幫我補測試」、 「這功能怎麼測」、「寫測試」、「test cases」、「test plan」、「QA checklist」時, 一定要使用這個 skill。即使使用者只是丟一份 PRD、一段 AC、一個功能描述說 「幫我想想怎麼驗收」、「工程做完了要測什麼」,也應觸發此

SKILL.md

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

Read more
Ships withenterprise-prd-toolkit

把「金融級產品需求文件」的方法論,工程化成一組 Claude Skills。 從一句想法,到工程師能直接開發、QA 能直接寫測試的施工藍圖。

Get the whole plugin
Stats
45
Stars
4
Forks
Maintained
Maintenance
MIT
License
1mo ago
Last commit
1mo ago
Created

Repo: skinnerlee1225/enterprise-prd-toolkit

Other skills on enterprise-prd-toolkit.

prd-writer
Skill

prd-writer

輕量版 PRD 撰寫工具 — 適合個人專案、單一功能、無合規/金流/風控需求、單團隊開發, 快速產出可直接交付工程的「施工藍圖」等級文件。 當使用者說「幫我寫 PRD」、「產品需求文件」、「寫 spec」、「功能規格」、「write a PRD」、 「product requirements」、「feature…

requirement-gap-finder
Skill

requirement-gap-finder

需求補洞助手(探路模式)— 專用於「白紙一張、還沒有 PRD」的場合:站在 PM、UIUX、 Backend、Frontend、QA 五個角色,掃描需求的缺漏、容易誤解的敘述、沒考慮到的 Edge Case, 以及開發前一定要確認的問題,把還沒想到的東西攤開。 ✅ 適用場合(符合任一才觸發): - 全新產品 /…