用 LLM 生 Test Case — Prompt 範本、品質檢核、實務踩雷
LLM 不會取代 QA，但會取代不會用 LLM 的 QA。這篇講怎麼把 Claude / ChatGPT 變成 test case 生產線，又不被它的幻覺害死。
什麼能交給 AI、什麼不能
| 任務 | AI 表現 | 為什麼 |
|---|---|---|
| 等價分割、邊界值 | 🟢 好 | 規則型，LLM 能列得比人全 |
| 反例 / 異常路徑 | 🟢 好 | LLM 想到的角度比新手多 |
| 標準化 case 格式 | 🟢 好 | 純 formatting |
| 從 user story 拆 case | 🟡 中 | 會列，但要人篩 |
| 跨系統整合 case | 🔴 差 | 缺上下文，會編造 |
| Domain-specific 規則 | 🔴 差 | 例如台灣稅法、健保規則，會講錯 |
| 探索性測試靈感 | 🟡 中 | 給你方向，但無法執行 |
原則：AI 出第一版，人類審第二版。直接 copy-paste 上線是災難。
Prompt 範本（直接複製可用）
範本 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 出案後必做）
收到 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 提升品質
單輪 prompt 輸出常常浮淺，用對話追問結果好很多：
[Round 1] 給 spec、要 case
[Round 2] 「再列 5 個你剛漏掉的異常路徑」
[Round 3] 「以上 case 中，哪些可能 flaky？要怎麼穩定它？」
[Round 4] 「把 P0 case 改寫成 Playwright 程式碼」
每一輪都讓 LLM 挑戰自己上一輪的輸出，最後得到的清單會比一次 prompt 多 30-50% 的覆蓋。
常見幻覺與踩雷
- 編造 API endpoint — LLM 會說「呼叫
/api/v2/users/verify」但根本不存在。所有 endpoint 以你的程式碼為準。 - 編造錯誤代碼 —
Error: USER_NOT_VERIFIED_42這類具體錯誤訊息，AI 會編。要對照真實程式碼。 - 假設預設值 — 「假設 timeout 預設 30 秒」其實是 60 秒。要追問或寫死。
- 舊版規則 — LLM 訓練資料舊，引用法規或 API spec 可能過期。Domain 規則一律人工驗。
- 過度樂觀的 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。