AI 測試案例生成實戰（2026）：AI 給我 50 個案例，有 20 個在測不存在的功能

AI 測試案例生成實戰（2026）：AI 給我 50 個案例，有 20 個在測不存在的功能 Stack Overflow 2025 年的開發者調查裡，66% 的人說 AI 最讓人困擾的地方是「答案幾乎對，但就是差一點」。測試案例是這種差一點最難被發現的地方：格式整齊、分類清楚、邊界值也有列，看起來沒什麼好挑的，一跑才知道。 我第一次讓 AI 產測試案例就是這樣。這篇從那次失敗講起，再拆解我現在的做法：把 AI 測試案例生成拆成幾塊積木，自己組流程。 那份「完整」的測試案例 那次要測的是 App 的訂閱功能改版。功能說明兩頁，條件不少：免費版限制、付費版解鎖項目、IAP 流程、訂閱狀態同步、跨裝置還原。 我把說明貼給 AI，請它生成測試案例。不到三分鐘，它給了我 50 幾個案例，有正常流程、有邊界值、有錯誤情境，還分好類別。我當下覺得這東西真好用。 實際跑下去，大概 20 個測的是我們系統根本不存在的情境。 更糟的是它沒測到的那個。我們的訂閱有一條特殊規則：使用者在 A 裝置訂閱後，換到 B 裝置登入，付費功能的解鎖要靠我們自己的 server 在登入時主動查一次訂閱狀態。這件事在說明文件第二頁最下面，一句話帶過。這個流程前一版才因為 race condition 出過 bug，使用者付了錢卻看不到付費功能。 AI 不可能知道這一句有多重要。它看到「訂閱功能」，就把它見過的訂閱系統測試案例重新組合一遍。那些案例對「一般的訂閱系統」都對，但我們的系統不是一般的系統。 後來我在 AI 漏掉的那個情境找到了 bug：在 iPhone 訂閱，換到 iPad 登入，訂閱狀態沒有即時同步，要等下一次 App 啟動才會查詢。如果那天我直接拿 AI 的 50 個案例跑完就結案，這個 bug 會留到使用者手上。 2026 年，AI 測試案例生成變成什麼樣子 那次之後，業界的工具和做法變了很多。我看到的變化有四個。 一、九成公司在試，能擴大到全公司的只有 15% Capgemini 的《World Quality Report 2025–26》裡，89% 的受訪組織正在試行或導入生成式 AI 的品質工程流程，但真正做到全公司規模的只有 15%。同年 Stack Overflow 的調查，84% 的開發者在用或打算用 AI 工具，信任 AI 輸出準確度的卻只有 33%。 用的人越來越多，信的人越來越少。我自己的解讀是：卡住的不是模型能力，是 AI 拿不到產品脈絡。每次對話都從零開始，產出就只能停在「一般的系統」。 二、從「一段 prompt」變成「一套知識庫」 一年前我的做法還是把 prompt 寫好。到了 2026 年，Claude Code、Codex 這類 agent 工具都會在專案啟動時讀取設定檔（CLAUDE.md、AGENTS.md），也能直接讀專案裡的文件。重點從「這次 prompt 怎麼寫」，變成「我給 AI 準備了什麼文件」。 產品規則、術語、歷史 bug、模組之間的關係寫成文件放進專案，每次產測試案例時 AI 都讀得到。這份知識庫是會累積的，prompt 不會。 三、AI 開始能自己操作產品 透過 MCP（Model Context Protocol），AI 可以直接操作手機或瀏覽器，例如用 Appium MCP 點 App、用 Chrome DevTools MCP 看網頁和 API request。測試案例不再只能從文件推，AI 可以先自己走一遍功能，把看到的畫面和流程寫回知識庫，再來產案例。 四、QA 的時間從「寫案例」移到「問清楚」 AI 寫案例很快，所以 QA 的時間開始往前移：AC 有沒有漏、RD 怎麼實作、後台設定會影響什麼。以前這些問題在寫案例時順便想；現在要先問清楚，才餵得給 AI。 心法：先講清楚 AI 和人各做什麼 拆積木之前，先講幾條我現在的原則。後面每一塊積木都是照這幾條設計的。 AI 的產出是候選，不是答案 我會在每份 AI 草稿上明確標「待 QA 審核」，審過才算正式案例。標這個是提醒自己：還沒被人看過的東西，不能進回歸清單。 已確認、推論、缺口要分開寫 AI 最大的毛病是把猜測寫得跟事實一樣肯定。所以我要求它每條規則都標來源：文件寫的、實機看到的，還是它自己推的。推出來的就列在「待確認」，由我去問 PM 或 RD。 資料不夠就停下來 我寧可 AI 回我「這個功能的後台設定文件裡沒有，請先補」，也不要它硬寫一份看起來合理的案例。 AI 負責發散，人負責判斷 列出所有可能的操作和邊界值，AI 比人快、也不會累。哪個值得測、哪個是真的 bug、哪個只是測試資料的假象，還是人的工作。 知識要寫進文件，不能只留在對話裡 每次發現新規則、新 bug，就寫回知識庫。對話關掉就沒了，文件會留下來給下一次用。 積木架構：把 AI 測試案例生成拆成七塊 我不用一個超長 prompt 一次產出，而是拆成幾塊小積木，每塊只做一件事、有固定的輸入和輸出。小需求只拿兩三塊來組，大改版全部串起來跑。 | 積木 | 輸入 | 輸出 | | | | | | 1. 產品知識庫 | 規格、實機觀察、歷史 bug | 可以被引用的產品文件 | | 2. 需求審查 | AC／需求文件 | AC 缺口清單、要問 PM 的問題 | | 3. 風險預測 | 需求＋歷史 bug 模式 | 這次最可能出事的地方 | | 4. 測試模型 | 需求＋風險 | 狀態圖、決策表、邊界值清單 | | 5. 產生案例 | 測試模型＋團隊格式 | 測試案例草稿（待審） | | 6. AI 審查 | 案例草稿＋需求 | 覆蓋缺口、看不懂的步驟 | | 7. 探索章程 | 風險清單 | 探索性測試的方向與判斷依據 | 1. 產品知識庫：其他積木都靠它 這塊是地基。我把產品拆成模組、核心資料（例如訂閱狀態、使用者帳號）、歷史 bug、團隊術語，各自寫成文件，再用一份索引告訴 AI 什麼問題去哪裡找。 歷史 bug 我會整理成「模式」，不逐筆貼：計時邏輯、跨裝置同步、狀態還原、平台差異、並發請求……每個模式底下掛著實際發生過的案例。開頭那個跨裝置同步的 bug，現在就是其中一個模式。 知識庫怎麼分層、怎麼防止 AI 腦補，我在 QA Brain：讓 AI 真的懂你的產品 寫得比較完整。這個知識庫我從三月開始累積，前幾個月幾乎看不到回報，那段過程寫在 從寫自動化到經營知識庫。 2. 需求審查：先找洞，再產案例 拿到需求，我第一件事是讓 AI 檢查 AC，還不急著產案例。我固定問它這幾類問題： 只寫了正常流程？失敗、取消、逾時呢？ 「正確顯示」是顯示什麼？有沒有具體的數字或狀態？ iOS、Android 有沒有分開說？需要什麼帳號前置條件？ 操作前的初始狀態是什麼？操作完資料會變成什麼？ 產出是一份「要問 PM 的問題清單」。這份清單問完，後面的案例才有根據。直接跳過這步產案例，等於讓 AI 替 PM 決定規格。 3. 風險預測：讓歷史告訴你這次會壞哪裡 把新需求的技術特徵和知識庫裡的 bug 模式比對。需求有提到跨裝置？對到同步類模式。牽涉計時？對到計時類模式。比對結果分高、中、低，高風險的地方，後面的案例和探索就要多花力氣。 這塊是 AI 單靠通用知識做不到的。它不知道你的產品哪裡出過事，除非你寫給它。 4. 測試模型：先畫結構，再展開案例 直接從需求產案例，AI 會照它看過的格式湊數量。先讓它建一個測試模型，案例就有骨架： 有狀態轉換的功能（訂閱、訂單），先畫狀態圖，再看哪些轉換沒被測到 多個條件組合出不同結果的功能，先做決策表 有數值輸入的地方，列邊界值：上限、上限 +1、0、負數 參數組合太多時，用 PICT 這類 pairwise 工具壓縮組合數 模型也是審查的依據。案例漏了什麼，對照模型一眼就看得出來。 5. 產生案例：團隊慣例寫進規則 到這一步，AI 手上有需求、問題的答案、風險和模型，產出的案例才會像樣。 團隊自己的寫法也在這時候給它：優先級怎麼分、步驟寫到多細、一個案例要驗幾個點。這些「只有你們團隊知道」的慣例，寫成固定規則，比每次在 prompt 裡交代可靠得多。 6. AI 審查：讓另一輪 AI 挑毛病 產出的草稿，我會再開一輪讓 AI 用審查者的角度看：對照需求，有沒有沒覆蓋的 AC？高風險的地方有沒有案例？步驟寫得新人看不看得懂？ 這個方向的效果反而比從零生成好。手上已經有一份案例當脈絡，AI 的補充就有根據，不會從通用知識裡隨機湊。審查完先出報告，我確認後才改檔案。 7. 探索章程：補腳本測不到的地方 測試案例守的是已知的路徑。新功能帶來的未知問題，要靠探索性測試。 我讓 AI 依照風險清單產幾個探索章程，每個寫清楚：去哪裡探索、從什麼角度（操作順序、中途打斷、狀態殘留、平台差異、時間邊界），以及怎麼判斷壞了（iOS 和 Android 結果不同、和以前的 bug 行為一樣、和文件規則對不上，或者就是感覺怪怪的）。 怎麼組合 小改動 ：需求審查 → 產生案例 → AI 審查 新功能 ：七塊全部串起來 出了線上 bug ：寫回知識庫 → 風險預測 → 探索章程，確認同類問題還有沒有 積木的好處是可以換。哪一塊效果不好就只改那一塊，不用整個流程重來。 一個可以直接用的 prompt 範本 還沒有知識庫的話，可以從這個範本開始。重點在最後三條規則： 「正常路徑只要最基本的幾條」這句很重要。不說的話，AI 會花大半篇幅測正常流程，邊界和例外塞在最後幾個。 審 AI 產出時，我會做的三件事 1. 刪掉不適用的 ：測不存在功能的、和我們產品規則衝突的。 2. 補上 AI 想不到的 ：只有懂這個產品的人才知道要測的情境。 3. 標出要探索的 ：AI 給的案例是「已知的未知」，探索性測試找的是「未知的未知」。 開頭那次的 50 個案例，我最後刪到 30 個，自己再補 10 到 15 個。跑的清單變短，但每一條都有理由。 常見問題 ChatGPT 或 Claude 可以直接寫測試案例嗎？ 可以寫，但直接拿去用的品質不夠。它能列出顯而易見的正常流程和通用邊界值，不知道你產品的特殊規則和歷史問題。至少要補上業務規則和歷史 bug，產出才會接近能用。 AI 產的測試案例可以直接跑嗎？ 不建議。AI 會產出你系統不存在的情境，也會漏掉文件沒寫清楚的規則。把它當第一份草稿，人審過再進正式案例。 寫測試案例的 prompt 要怎麼寫？ 給它三樣東西：需求、spec 沒寫但重要的業務規則、過去相關的 bug。再加上規則：先問問題再產案例、推斷的規則要標「待確認」、資料不夠就說不知道。上面有完整範本。 要用什麼工具？ 工具不是重點，選你習慣的就好。Claude Code、Codex 這類能讀專案文件的 agent 工具，比在聊天視窗貼 prompt 適合長期累積，因為知識庫可以放在專案裡一直用。 AI 會取代寫測試案例的 QA 嗎？ 寫案例的時間會被取代，判斷不會。AI 不知道哪個情境對你的業務最重要，也不知道哪裡出過事。QA 的時間會從寫案例，移到問清楚需求、整理產品知識、判斷 AI 的產出。 公司資料可以餵給 AI 嗎？ 先確認公司的 AI 使用政策：允許用哪些工具、哪些資料可以送出去。知識庫裡也不要放帳號、密碼、token 和使用者個資。這一步比任何技巧都優先。 回到那 50 個案例 那次如果我有現在這套積木，需求審查會先問出「跨裝置同步走自建 server」這件事，風險預測會對到前一版的 race condition，測試模型會把「A 裝置訂閱、B 裝置登入」畫成一條狀態轉換。那個 bug 不用靠我剛好記得，流程本身就會把它翻出來。 這也是我現在檢查一份 AI 測試案例的方式：先找出哪一條是只有懂這個產品的人才會寫的。一條都找不到，這份清單就還沒好。 AI 的輸出要怎麼判斷能不能信，我在 我憑什麼相信綠燈 寫過；為什麼產品知識在 AI 時代更重要，可以看 這篇。 參考資料 Stack Overflow Developer Survey 2025：AI — 84% 使用 AI 工具、33% 信任其準確度、66% 困擾於「幾乎對但差一點」 World Quality Report 2025–26 — Capgemini — 89% 試行或導入生成式 AI，僅 15% 達全公司規模 Model Context Protocol — AI 工具連接外部系統（裝置、瀏覽器、資料源）的開放協定 PICT — Microsoft — pairwise 組合測試工具 AI Tester Certification — ISTQB — ISTQB 的 AI 測試認證大綱