---
title: 用 LLM 生 Test Case — Prompt 範本、品質檢核、實務踩雷
description: 把 Claude / ChatGPT 變成測試案例產生器。從 spec 到 test case 的 prompt 範本、輸出品質檢核、什麼能交給 AI、什麼不能。
category: ai-qa
tags: [llm, claude, prompt, test-case, ai-qa]
date: 2026-06-09
---

# 用 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% 的覆蓋。

## 常見幻覺與踩雷

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**。