用 LLM 生 Test Case — Prompt 範本、品質檢核、實務踩雷

LLM 不會取代 QA，但會取代不會用 LLM 的 QA。這篇講怎麼把 Claude / ChatGPT 變成 test case 生產線，又不被它的幻覺害死。

原則：AI 出第一版，人類審第二版。直接 copy-paste 上線是災難。

範本 1：從 spec 生 test case

你是資深 QA 工程師，依下列 spec 產出 test cases。

【Spec】
<貼 spec 全文，或 user story>

【需求】
1. 列出至少 8 個 test cases，涵蓋：
   - Happy path（2 個）
   - 邊界值（至少 2 個）
   - 異常輸入（至少 2 個）
   - 安全性 / 權限（至少 1 個）
   - UI / UX 細節（至少 1 個）
2. 每個 case 用以下格式：
   - ID: TC-<功能簡碼>-<3 位數字>
   - Title: 一句話描述
   - Priority: P0 / P1 / P2
   - Preconditions
   - Test Data（具體值，不要寫「合法 email」）
   - Steps（編號）
   - Expected Result（對齊每個 step）
3. 用繁體中文輸出
4. 如果 spec 有模糊處，先在開頭列「需確認問題」再產 case

【禁忌】
- 不要編造 spec 沒提到的欄位、規則、功能
- 不要假設預設值，模糊處要列「需確認」
- 不要用「正確的」「合理的」這種無法量測的字眼

範本 2：邊界值與等價分割

針對下列輸入欄位，列出完整的等價分割與邊界值測試資料。

【欄位 spec】
欄位：<欄位名稱>
型別：<int / string / date / ...>
限制：<例如 1 <= 值 <= 100、長度 5-20 字元、僅允許英數>

【輸出格式】
| 類別 | 測試值 | 預期 | 為什麼 |
|------|--------|------|--------|
| 等價 - 合法 | ... | ... | ... |
| 等價 - 不合法 | ... | ... | ... |
| 邊界 - 下界 | ... | ... | ... |
| 邊界 - 上界 | ... | ... | ... |
| 邊界 - 下界 -1 | ... | ... | ... |
| 邊界 - 上界 +1 | ... | ... | ... |
| 特殊字元 | ... | ... | ... |
| 空值 / null | ... | ... | ... |
| 超長 | ... | ... | ... |

每一行都要有具體的「測試值」，不要寫「任何小於下界的值」。

範本 3：從 bug 反推回歸測試

我們剛修了一個 bug。請幫我寫對應的回歸 test cases，避免日後再復發。

【Bug 描述】
<貼 bug 報告 / Jira ticket>

【根因】
<貼開發者寫的 root cause analysis>

【修復方式】
<貼 PR 描述 / commit message>

【需求】
1. 寫一個直接覆蓋這個 bug 場景的 case（必填）
2. 寫至少 2 個「類似但不同」的場景（變形攻擊）
3. 寫一個整合 case 確認修復沒打到其他功能
4. 用 test-case-template 格式

收到 AI 的 test case 後，用這份 checklist 過一次：

• [ ] Spec 對得上嗎 — 有沒有編造欄位？是否漏了 spec 寫的規則？
• [ ] Test Data 是具體值嗎 — 還是寫「合法的 email」？
• [ ] Expected 可量測嗎 — 不是「畫面正常」、「行為正確」這種
• [ ] Step 順序正確嗎 — AI 偶爾會把 step 3 放在 step 2 之前
• [ ] 有沒有重複的 case — AI 會把同個 case 用不同 title 列兩次
• [ ] Priority 合理嗎 — AI 預設都 P1，要人工調
• [ ] Domain 規則對嗎 — 涉及稅、法規、健保等，一定要人工查
• [ ] 負面 case 充足嗎 — AI 偏 happy path，要主動追問「還有什麼會壞掉？」

單輪 prompt 輸出常常浮淺，用對話追問結果好很多：

[Round 1] 給 spec、要 case
[Round 2] 「再列 5 個你剛漏掉的異常路徑」
[Round 3] 「以上 case 中，哪些可能 flaky？要怎麼穩定它？」
[Round 4] 「把 P0 case 改寫成 Playwright 程式碼」

每一輪都讓 LLM 挑戰自己上一輪的輸出，最後得到的清單會比一次 prompt 多 30-50% 的覆蓋。

1. 編造 API endpoint — LLM 會說「呼叫 /api/v2/users/verify」但根本不存在。所有 endpoint 以你的程式碼為準。
2. 編造錯誤代碼 — Error: USER_NOT_VERIFIED_42 這類具體錯誤訊息，AI 會編。要對照真實程式碼。
3. 假設預設值 — 「假設 timeout 預設 30 秒」其實是 60 秒。要追問或寫死。
4. 舊版規則 — LLM 訓練資料舊，引用法規或 API spec 可能過期。Domain 規則一律人工驗。
5. 過度樂觀的 expected — 「系統會自動回滾」可能根本沒實作。Expected 要對得上實際行為。

1. PM 寫 spec → 你用範本 1 跑 LLM 出第一版 case
2. 你用 checklist 過一遍、刪重複、補 domain 規則
3. 跟 PM / 開發 review，確認 case 對應到實作
4. 把 P0 case 轉 Playwright（再用 LLM 寫 code 草稿）
5. 跑、修、上 CI

整個流程最花時間的是 step 2-3，AI 只是加速 step 1。但這個加速可能讓你從一天寫 20 個 case 提升到一天 60 個。

LLM 是「能列 100 個 case 但可能有 30 個爛」的工具，QA 是「能在 30 秒分辨爛 case」的人。兩者組合 > 任何一方單獨工作。不要外包判斷力給 AI。