轉念學 – 敏捷三叔公的學習之旅

整理 2023–2026 年間 QA 社群、工具廠商、開發者官方文件與學術論文中最常被引用的 test case generation prompt，歸納它們的共同結構，並討論一個常被忽略的問題：這些 prompt 到底用了多少軟體測試的專業？

本文盡量不預設讀者有測試背景。遇到專有名詞會用生活化的例子說明，測試老手可以直接跳過那些段落。

零、先把幾個名詞講清楚

如果你不是做測試的，先花兩分鐘看這一節，後面會輕鬆很多。

測試案例（test case） 一張「怎麼檢查這個功能有沒有做對」的操作單。通常包含：前提條件（例如「使用者已登入」）、操作步驟（「在密碼欄輸入 123」「按登入」）、預期結果（「畫面顯示：密碼至少 8 碼」）。測試人員照著做，結果一樣就是通過，不一樣就是 bug。

User story 與驗收條件（acceptance criteria, AC） 敏捷團隊描述需求的方式。User story 是一句話：「身為會員，我想用信用卡付款，這樣就不用轉帳」。驗收條件是這個需求「做到什麼程度算完成」的具體清單，例如「輸入無效卡號時顯示錯誤訊息」「付款成功後寄出確認信」。測試案例大多是從驗收條件長出來的。

Happy path / negative / boundary / edge case 測試界把情境分成幾類：

• Happy path：一切正常的路。輸入正確帳密，登入成功。
• Negative：故意做錯的路。密碼打錯、欄位留空、卡號亂填。
• Boundary（邊界）：規則的臨界點。「檔案上限 5MB」，那 4.99MB、5.00MB、5.01MB 各會發生什麼事？bug 特別喜歡躲在這裡。
• Edge case：罕見但可能發生的狀況。上傳到一半斷網、兩個人同時用同一張折價券。

Prompt 你打給 AI 的那段指令。本文討論的就是「用什麼樣的指令，能讓 AI 產出好的測試案例」。

一、為什麼要整理這件事

「用 AI 產生測試案例」已經是 QA 社群最常見的 AI 應用場景。工具廠商寫部落格教你怎麼下 prompt，開發者文件附上可以直接複製的模板，學術界也用各種 prompt 跑實驗比較效果。

我把目前最流行的幾份 prompt 攤開來對照，想回答兩個問題：

1. 它們的結構是什麼？有沒有共同骨架？
2. 這些 prompt 裡面，究竟用了多少「軟體測試」這門專業的知識？

第二個問題的答案，比我原本預期的要尷尬一些。

二、共同骨架：七個槽位

把幾份主要來源的 prompt 拆開，格式幾乎都能對應到下面七個「槽位」——你可以想像成一張表單，每家的 prompt 差別只在有沒有填、填得多細。

各家怎麼填這七格

• SoftwareTestPilot（2026） 直接把骨架命名為 RCTF：Role、Context、Task、Format。文章明講「AI 的輸出很空泛，就是四格少了一格」。它還附了一套六點量表（涵蓋度、具體性、資料真實性、可執行性、可追溯性、安全性），每項 1–5 分，低於 4 分就退回重跑，不要手動修補。
• Kualitee（2025/12） 的 expert prompt 把第 2、3、5、6 格填得最滿：角色 + 微服務 B2B 情境 + 貼入 story 與 AC + 表格欄位（包含一欄「這個案例對應哪一條驗收條件」）+ 聚焦 happy path 與高風險 negative。
• Testomat.io（2025/12，2026/07 更新） 用 #ROLE / #TASK 兩個標籤開頭，後面接輸出結構。整篇文章依測試流程切成七步（需求分析 → 情境 → 案例 → edge case → 測試資料 → 自動化腳本 → 測試計畫），每一步一個 prompt。
• tayyabakmal1/qa-prompt-library（GitHub） 是填空模板庫：每組 prompt 就是「任務句 + 幾個方括號填空（功能名稱、user story、驗收條件）+ 要涵蓋的清單 + 輸出欄位」。十組 prompt 依功能類型分（表單驗證、搜尋、權限、報表……）。
• GitHub Copilot 官方 prompt file 是給開發者用的版本，針對「為一段程式碼寫單元測試」。結構：任務 → 四層測試策略（核心功能、輸入驗證、錯誤處理、副作用）→ 撰寫規範（沿用專案既有框架、AAA 模式、描述性命名）→ 讓使用者填目標函式與框架 → 指引（5–8 個案例、彼此獨立、測行為不測實作）。
• 學術論文的 prompt 通常最簡。Yuan et al.（2023）是「角色一句話 + 要測的程式碼 + 用 JUnit4 寫測試」；Tang et al.（2023）調查網路上開發者實際用語後，歸納成「為以下程式碼寫 JUnit 測試，每個方法一個案例」。

小補充：什麼是單元測試？什麼是 AAA？ 單元測試是開發者寫程式來測自己的程式，針對最小的單位（一個函式）。AAA 是寫單元測試的慣用三段式：Arrange（準備資料）、Act（呼叫要測的函式）、Assert（檢查結果）。就像做菜的「備料、下鍋、試味道」。

進階：從單一 prompt 拆成流程

真正拉開差距的不是七格填法，而是把一個大 prompt 拆成好幾步，也就是 prompt chain（串接）。

• QATribe（2026/07） 提出五階段：
  1. 模糊點分析——先請 AI 列出需求哪裡不清楚、缺什麼資訊、必須做哪些假設，並明確要求「這一步不要產生測試案例」。
  2. 情境識別——列出所有該測的情境，只要標題不要細節。
  3. 逐類別產生案例——一次只做一類（例如只做 negative），避免 AI 越寫越草率。
  4. 覆蓋率審查——回頭檢查有沒有漏。
  5. 匯出格式——轉成測試管理工具能匯入的格式。
• arXiv 2412.03693（2024） 用五份需求規格書做實驗：把整份規格加指令塞進一個 prompt，平均每個功能只產出 3.6 個測試設計；改成先給規格、再一個功能一個功能分開問，平均升到 10.58 個。一樣的資料，拆開問就多了三倍。
• arXiv 2312.10622（2023） 先請 AI 寫單元測試，再把「哪幾行程式碼還沒被測到」餵回去要它補，重複幾輪。這是唯一把執行結果接回 prompt 的做法。

三、關鍵觀察：骨架是通用的，測試專業在哪裡？

把七個槽位再看一次，你會發現這套結構跟軟體測試沒有必然關係。把它改成「你是資深法務，根據這份合約，列出風險條款，用表格輸出，聚焦付款與違約責任」，完全成立。這是通用 prompt 寫法的固定套路（角色 / 情境 / 任務 / 格式），不是測試領域的產物。

那測試專業到底出現在哪裡？逐份對照後，只在兩個槽位看得到，而且多數只做到第一層。

第 5 槽（Coverage）：多數只放了「名詞」，沒放「方法」

「涵蓋 happy path、negative、boundary、edge case」這句話，本質上是把測試教科書的目錄貼進 prompt，然後期待 AI 自己知道怎麼做。

這跟對新人說「記得要測邊界值」一樣——他點頭了，但你沒告訴他邊界怎麼找。結果就是他只測「有效」和「無效」兩種，中間最容易出 bug 的 4.99MB、5.01MB 根本沒碰到。

少數把技法寫成操作程序的例子，輸出品質明顯不同：

• Klariti 對「只接受 5MB 以下 PDF」的需求，明講要測 4.9 / 5.0 / 5.1 MB 三個值。這才是「邊界值分析」的操作定義，不是名詞。
• Kualitee expert prompt #2 給出「金額 1 到 10,000、最多兩位小數、僅限 USD」的具體規格，要求 AI 先做等價分割與邊界分析，並在表格中標示每個案例屬於哪一區、風險多高。
• QATribe 第四階段的覆蓋率審查，明確要求對每個數值／日期／長度欄位確認「最小值、最小值+1、最大值-1、最大值、最大值+1」都有案例；對會互相影響的條件檢查有沒有漏掉組合。另外還有針對「狀態轉換」和「風險排序」的 prompt。
• GitHub Copilot prompt file 的 AAA 模式、測試彼此獨立、測行為不測實作——這是單元測試的實踐層，不只是名詞。

小補充：三個常見的測試設計技法

等價分割（equivalence partitioning）：把輸入分成「行為應該一樣」的幾群，每群測一個代表就好。年齡欄位接受 18–65，那 20 和 40 測起來應該一樣，不用兩個都測；但 17、18、65、66 就是不同群。

邊界值分析（boundary value analysis）：專攻每一群的邊。程式寫 > 還是 >= 常常寫錯，所以 18 和 17 一定要分開測。

決策表（decision table）：當好幾個條件會互相影響時，先列一張表把所有組合排出來，每一列變一個案例。例如「折價券有效？」「訂單金額達門檻？」「已經用過一張？」三個條件就有 8 種組合，靠腦袋想很容易漏。

第 7 槽（Constraints）：偶爾出現實踐級規則

「不要用固定等待秒數」「每個測試檔最多 10 個測試」「遇到規格沒定義的行為，列成待澄清問題，不要猜」——這類約束才是專業經驗的沉澱。但它們多半出現在 Claude Code、Cursor 社群的「規範檔」裡（CLAUDE.md、skill、.cursor/rules，也就是讓 AI 每次都先讀的團隊規則），而不是那些被廣泛轉貼的單一 prompt 範本裡。

完全缺席的，才是測試設計的核心

1. 預期結果從哪裡來？（測試界稱為 oracle 問題）

每一份 prompt 都要求 AI 填「預期結果」這一欄。但你想想：AI 怎麼知道「輸入 5.01MB 的檔案」應該發生什麼事？規格如果沒寫，它就會編一個聽起來合理的答案——「顯示錯誤訊息：檔案超過大小限制」。看起來很專業，但那是它猜的，不是規格說的。

這正是 AI 產生測試案例最危險的地方：格式整齊的猜測，比明顯的錯誤更難被發現。 沒有任何一份流行 prompt 要求「每個預期結果要能追溯到規格的哪一句；找不到對應的，標為假設而非事實」。

2. 需求澄清的結構化流程。

QATribe 的模糊點分析已經很接近，但它是 AI 單方面列問題。Specification by Example 有一套叫 example mapping 的做法——開發、測試、產品三方坐下來，把每條規則配上具體例子，講不出例子的規則就是還不清楚。這個流程沒有被任何人轉成 prompt 步驟。

3. 其他測試設計技法。

Pairwise（多個選項組合太多時的抽樣法）、狀態轉換表（QATribe 有一個）、探索性測試的 charter（Kualitee 有一個）、mutation testing（故意在程式裡埋錯，看測試抓不抓得到）——幾乎缺席。

4. 執行回饋迴路。

除了那篇「把沒測到的行號餵回去」的論文，沒有任何實務 prompt 把測試跑完的結果、失敗訊息接回來當下一輪輸入。AI 寫完就結束了，它永遠不知道自己寫的測試有沒有用。

為什麼流行的都是通用版？

一個合理的解釋是：這些 prompt 之所以流行，恰恰因為它們不需要測試知識就能寫出來，也不需要測試知識就能覺得輸出很棒。

沒學過測試設計的人，看到 AI 吐出 30 個排版整齊的案例會很滿意；懂邊界值分析的人會發現，邊界值只有「有效／無效」兩類，臨界點全部漏掉。前者會分享這個 prompt，後者不會——所以流傳出去的永遠是前者。

四、補上缺的那一格：Test Design Method

前面說骨架有七格，測試專業只出現在第 5、第 7 格，而且大多只放名詞。順著這個觀察往下推，解法其實很直接：加第 8 格，叫「測試設計方法」，並且把它拆成「先選、再用」兩個動作。

為什麼要「先選」？因為技法不是萬用的，要看規格長什麼樣：

一份規格通常會同時命中兩三列。這個「對照 → 挑選」的動作，就是測試設計的核心，也是流行 prompt 完全沒有的那一步。

升級版骨架（含第 8 格）

以下是我自己寫的範例，分成兩個 prompt，對應「先選、再用」：

Prompt A：選技法

【Role】你是熟悉測試設計技法的測試設計者。
【Input】規格：[貼入 user story + 驗收條件 + 已知限制]
【Task】先不要產生測試案例。請分析這份規格，回答：
1. 規格中有哪些「有範圍的欄位」？逐一列出欄位名稱與範圍。
2. 有哪些「會互相影響的條件」？列出條件組合。
3. 有沒有「狀態或生命週期」？畫出狀態與轉換。
4. 有沒有「可任意組合的獨立選項」？列出選項與各自的值。
5. 根據以上分析，建議這份規格該用哪幾種測試設計技法，
   每種技法說明「用在規格的哪一段」。
【Output】表格：規格片段 | 特徵類型 | 建議技法 | 理由
【Constraints】規格沒寫清楚的地方，列成「待澄清問題」，不要補完它。

Prompt B：用技法產生案例（人審過 A 的輸出後才跑）

【Role】同上。
【Input】規格：[同上]
       已確認的技法對照：[貼入 Prompt A 審核後的表格]
【Task】依照對照表，逐一套用技法產生測試案例。
【Test Design Method —— 每種技法寫成程序】
- 等價分割 + 邊界值：對每個有範圍的欄位，先列有效／無效分群，
  再對每個邊界產生 min-1 / min / min+1 / max-1 / max / max+1。
- 決策表：對每組互相影響的條件，先列完整組合表，
  每一列一個案例，並標出規格「沒有定義」的組合。
- 狀態轉換：列出所有合法轉換各一個案例，
  再對每個「不該發生」的轉換各一個案例，驗證系統會拒絕。
- Pairwise：列出選項與值，產生任兩個選項的組合都至少出現一次的最小集合。
- Error guessing：列出你認為最容易出錯的五個地方，各一個案例，並說明理由。
【Oracle —— 預期結果要有出處】
每個預期結果標註它對應到規格的哪一句。
找不到對應的，標為 [ASSUMPTION]，不要寫成事實。
【Output】表格：ID | 技法 | 規格片段 | 輸入值 | 預期結果 | 規格出處 | 假設
【Constraints】
- 只用對照表裡確認過的技法，不要自己加。
- 規格沒定義的行為，列成「待澄清問題」，不要猜。
- 最後列出你認為最可能漏掉的三個區域。

每一段在做什麼：

• Prompt A 的 1–4 題是在教 AI「怎麼看規格」——不是問它「該用什麼技法」，而是先讓它把規格的特徵拆出來，技法選擇自然會跟著出現。
• A 和 B 中間留給人審核。 這是刻意的：選錯技法的代價很高，而選技法正是需要經驗的地方。AI 提案、人拍板，然後才讓 AI 大量產出。
• Prompt B 的技法段落是把每種方法寫成「步驟」，不是名詞。AI 拿到「min-1 / min / min+1」這種指令，就沒有空間只測「有效／無效」兩種。
• Oracle 段落處理預期結果從哪來的問題：有出處的才是事實，沒出處的是假設，審核的人一眼就能分辨。
• Output 多了「技法」和「規格片段」兩欄，這樣審核時可以按技法檢查覆蓋：「決策表那一段產了幾個？有沒有漏列組合？」——這叫做「按方法審覆蓋率」，比「看起來案例很多」可靠得多。

這樣做的副作用是 prompt 變成兩份、變長、變「醜」，不像流行文章裡乾淨的四行式範本。但這正好說明了問題：好看和有效是兩回事。 通用骨架好看，是因為它把最難的部分（看規格、選技法）留給 AI 自由發揮；而 AI 自由發揮的結果，恰好是專業人員一眼就能看出破綻的地方。

五、結語

整理下來，2023 到 2026 年的演變有一條清楚的線：

• 2023–2024 的文章重點在措辭——怎麼寫一句話讓 ChatGPT 產出更多案例。
• 2025 起，重點轉向結構——RCTF、#ROLE/#TASK、表格欄位、可匯入工具的格式。
• 2026 的主流則是流程與規範檔——prompt chain、Claude Code skill、Copilot prompt file、CLAUDE.md，加上輸出評分機制。

但不論哪個階段，「測試設計技法」都只是以名詞的形式出現在涵蓋清單裡，從來沒有成為骨架中獨立的一格。

AI 放大了一件老事：需求澄清先於測試設計，測試設計先於測試案例。 沒有前面兩步，prompt 骨架再漂亮，產出的也只是格式整齊的猜測。這件事在 AI 出現之前就是對的，只是以前猜錯要花好幾天才會發現，現在 AI 讓你在三十秒內猜錯三十次，而且每一次都排版得很好看。

資料來源

主要來源

1. Zunnoor Zafar, “30 Expert AI Prompts for QA Teams,” Kualitee Blog, 2025-12-11. https://www.kualitee.com/blog/ai/expert-ai-prompts-for-qa-teams/
2. Avinash Kamble, “50 ChatGPT Prompts for Software Testers (2026): Manual, Automation, API,” SoftwareTestPilot, 2026-06-30（2026-07-10 更新）. https://softwaretestpilot.com/blog/ai-in-testing/chatgpt-prompts-software-testers-50-examples
3. Vitaliy Mikhailyuk, “AI Test Management Solutions vs. ChatGPT: What’s Better for QA Documentation Analysis?,” Testomat.io Blog, 2025-12-22（2026-07-28 更新）. https://testomat.io/blog/chatgpt-for-test-case-generation/
4. tayyabakmal1, qa-prompt-library — manual-qa/test-case-creation/functional-prompts.md, GitHub. https://github.com/tayyabakmal1/qa-prompt-library/blob/main/manual-qa/test-case-creation/functional-prompts.md
5. Ajit Marathe, “How to Generate Test Cases from User Stories Using Claude: A Complete Step-by-Step SDET Guide (2026),” QATribe, 2026-07-07. https://qatribe.in/generate-test-cases-from-user-stories/
6. GitHub Docs, “Generate unit tests” (Copilot prompt file, customization library). https://docs.github.com/en/copilot/tutorials/customization-library/prompt-files/generate-unit-tests
7. Zhiqiang Yuan et al., “No More Manual Tests? Evaluating and Improving ChatGPT for Unit Test Generation,” arXiv:2305.04207, 2023（正式發表於 Proc. ACM Softw. Eng., FSE 2024）. https://arxiv.org/abs/2305.04207
8. Yutian Tang et al., “ChatGPT vs SBST: A Comparative Assessment of Unit Test Suite Generation,” arXiv:2307.00588, 2023. https://arxiv.org/abs/2307.00588
9. “System Test Case Design from Requirements Specifications: Insights and Challenges of Using ChatGPT,” arXiv:2412.03693, 2024. https://arxiv.org/pdf/2412.03693
10. “Unit Test Generation using Generative AI: A Comparative Performance Analysis of Autogeneration Tools,” arXiv:2312.10622, 2023. https://arxiv.org/pdf/2312.10622

補充來源

11. Klariti, “Simple to Advanced ChatGPT Prompts for Software Testing,” 2025-05-26. https://klariti.com/2025/05/26/simple-to-advanced-chatgpt-prompts-for-software-testing/
12. GitHub Docs, “Writing tests with GitHub Copilot.” https://docs.github.com/en/copilot/tutorials/write-tests
13. aqua cloud, “Prompt Engineering for Software Testers: Best Practices for 2026.” https://aqua-cloud.io/prompt-engineering-for-testers/
14. Alfredo Perez, “Create Reliable Unit Tests with Claude Code,” Medium (ngconf), 2025-09. https://medium.com/ngconf/create-reliable-unit-tests-with-claude-code-9147d050d557
15. localskills.sh, “Claude Code Unit Tests: Build a Test-Writing Skill,” 2026-07. https://localskills.sh/blog/claude-code-skill-writing-tests