我讓 AI 產測試案例，它給了我一份看起來很完整但根本沒用的東西

我讓 AI 產測試案例，它給了我一份看起來很完整但根本沒用的東西 Stack Overflow 2024 年調查顯示，76% 的開發者已使用或計畫使用 AI 工具——QA 圈也掀起同樣的熱潮。但 AI 產出「看起來完整」的測試案例，和產出「真正有用」的測試案例，是完全不同的兩件事。我花了一次慘烈的失敗才搞清楚這個差距。 目錄 1. 那份「完整」的測試案例 2. 我當時的期待 3. AI 不懂你的產品，除非你告訴它 4. 現在我怎麼用 AI 產測試案例 5. 結尾 那份「完整」的測試案例 那次我要測 我們的 App 的訂閱功能改版。功能說明文件兩頁，邏輯不算複雜，但條件挺多：免費版限制、Pro 版解鎖項目、IAP 流程、訂閱狀態同步、跨裝置還原。 我把功能說明貼給 AI，請它生成測試案例。 它給我的東西讓我眼睛一亮：50 幾個測試案例，有正常流程、有邊界值、有錯誤情境，格式整齊，還分好類別。花了不到三分鐘。 我當時想：這個真的好用。 後來跑測試，結果是——這 50 幾個測試案例，大概有 20 個測的是我們系統根本不存在的情境。 我當時的期待 我以為 AI 產出的測試案例，代表這個功能的測試範圍被覆蓋了。 這個想法是錯的。 AI 看到「訂閱功能」這幾個字，它做的事是：把它見過的所有訂閱系統的測試案例拿出來，重新組合給你。這些案例對「一般的訂閱系統」是對的。但你的系統不是一般的系統。 我們的 App 的訂閱有一個特殊規則：用戶透過 App Store 訂閱後，Pro 版的稀有樹種解鎖狀態要在跨裝置登入時同步——但這個同步走的是我們自己的 server，不是 Apple 的 receipt 驗證。也就是說，如果用戶在 A 裝置訂閱，切換到 B 裝置，我們的 server 需要在 B 裝置登入時主動查詢一次訂閱狀態，才會解鎖。這個行為在功能文件的第二頁最下面，一句話帶過。 AI 沒有測這個。它不可能測這個，因為它不知道「跨裝置訂閱同步走自建 server」這件事有多重要，也不知道這個流程在前一個版本曾經因為 race condition 出過 bug，導致用戶付費後看不到 Pro 功能。 那份 50 幾個案例的清單，對這個最關鍵的邊界條件完全沒有覆蓋。 AI 不懂你的產品 業界有個數字讓我印象深刻：手動寫出來的測試案例，在複雜系統裡平均會漏掉 20–30% 的關鍵情境。AI 產出的情況更糟——因為它漏掉的通常是你沒有明確說出來的業務邏輯。 AI 能做的事是： 從你給的描述推導出「顯而易見」的測試案例 列出通用的邊界值（空值、負數、超長字串） 補齊你可能忽略的格式驗證 AI 做不到的事是： 知道哪個情境對你的業務最重要 理解系統的歷史：哪些地方曾經出過問題 推斷文件沒有明說的隱性規則 這不是 AI 的缺陷，是它的本質。它沒有你的產品脈絡，除非你給它。 現在怎麼用 我現在還是用 AI 產測試案例，但用法完全不同。 第一步：先給它夠多的脈絡 不只是功能說明文件。我還會加： 「這個功能過去出過什麼 bug」 「哪種用戶行為最容易觸發邊界」 「這個功能跟哪些其他模組有連動」 脈絡給得越具體，AI 產出的案例越接近有用。以下是我現在給 AI 的 prompt 結構： 最後那句「不需要覆蓋所有正常路徑」很重要。如果不說，AI 會花大量案例測正常流程，然後把邊界和例外塞在最後幾個。 第二步：把 AI 的輸出當第一草稿，不是最終答案 拿到 AI 的案例清單之後，我做三件事： 1. 刪掉明顯不適用的 ：那些測的是我們系統不存在的功能的案例 2. 補上 AI 沒有想到的 ：基於我對產品的了解，加入 AI 漏掉的業務情境 3. 標記哪些需要探索性測試 ：AI 產的案例是「已知的未知」，探索性測試是為了找「未知的未知」 通常一份 AI 產出的 50 個案例，我會刪到 30 個，然後自己再加 10–15 個。最後跑的是一份 40–45 個的清單，但這份清單的品質比直接用 AI 的 50 個好很多。 第三步：讓 AI 幫你審你自己寫的案例 這是我覺得最有價值的用法，但很少人在做。 把你自己寫的測試案例貼給 AI，問它： AI 在這個方向的表現比「從零生成」好很多。因為它有了你的案例作為脈絡，可以做比較有根據的補充，而不是從通用知識裡隨機組合。 2025 年的現實 Medium 上有篇文章的標題是：「AI generated test cases are wrong more often than you think.」 我覺得這句話是對的，但結論不應該是「不要用 AI」。 Capgemini《World Quality Report 2024–25》調查指出：超過 63% 的 QA 團隊將 AI 測試列為年度重點，但真正落地並產出穩定品質的比例遠遠更低。落差的根源就是我一開始犯的那個錯：直接拿 AI 的輸出當答案，結果發現品質不行，就放棄了。 AI 在測試案例設計上的定位，是「讓你少花時間在顯而易見的案例上，把精力放在需要判斷的地方」。它不是要取代你的判斷，是要讓你的判斷用在更值得的地方。 結尾 那次訂閱功能的測試，最後我在 AI 漏掉的跨裝置同步那個情境，確實找到了一個 bug：用戶在 iPhone 訂閱，換到 iPad 登入，訂閱狀態沒有即時同步，要等下一次 App 啟動才觸發查詢。 如果我直接用 AI 的 50 個案例跑完就結案，那個 bug 不會在測試階段被發現。 AI 省了我很多時間，但前提是我知道它省的是哪部分的時間，以及哪部分它省不了。 現在每次拿到 AI 的測試案例，我會先問自己：「這份清單裡，哪個案例是只有我才知道要測的？」 那個答案，就是你作為 QA 存在的意義。 參考資料 World Quality Report 2024–25 — Capgemini Stack Overflow Developer Survey 2024 AI Tester Certification Overview — ISTQB Just Say No to More End to End Tests — Google Testing Blog TestPyramid — Martin Fowler