在軟體開發日益追求速度與自動化的時代，越來越多團隊開始使用 GenAI 工具，如 ChatGPT、Cursor、CodeWhisperer 等，協助產出測試案例（Test Case）。表面上看，這彷彿是一個美好的未來：只要一句話，AI 就能產出十數筆結構完整的案例，格式乾淨、分類分明、還自動加上預期結果。
但真正懂測試的人會發現：這些看起來「不錯」的東西，未必真的「有效」。
你要的是 Test Case，還是測試設計？
AI 可以產生 test case，沒錯。但我們真正需要的，是測試設計的思考能力。有別於傳統的腳本堆疊，測試設計是關於「測什麼比較有意義」、「哪些情況最容易出錯」、「我們是否已經覆蓋了所有有風險的類別」。
很多人用 AI 的方式是：「幫我針對登入功能寫 test case」，結果拿到的往往是：
- 一筆正常流程（帳號密碼正確）
- 一筆密碼錯誤
- 一筆帳號不存在
就這樣。
很整齊。很乾淨。很無聊。也很危險，因為這些案例根本無法捕捉邏輯錯誤、狀態異常、組合缺陷，更別說是跨模組的邏輯漏洞。
測試設計的深度，決定品質的上限
我們必須承認，AI 的「語言理解」能力強，但對於「測試邏輯結構」與「風險分層分析」仍處於非常依賴 prompt 的階段。也就是說：
如果你的提問不夠精準，AI 產出的測試也只會停留在表面。
例如：你沒有要求 AI 根據等價類別劃分、邊界值分析、狀態轉移圖、決策表模型，它就不會幫你涵蓋那些邏輯分支。你不提醒它哪些輸入參數需要組合測試，它就永遠只給你每一欄位單獨的 Happy Path。
與其叫 AI 寫案例，不如叫 AI 幫你「設計分類」
這裡有個轉念的重點：AI 不是測試機器，而是測試輔助思考的助理。最具價值的應用方式，不是讓它幫你產出一堆資料，而是：
- 幫我劃分等價類別
- 幫我畫出輸入資料組合表
- 幫我分析哪些組合可能造成失敗
- 幫我列出可能被忽略的業務邊界
AI 在這裡的角色，不是自動化，而是擴張你思考的邊界。
傳統測試技術 + GenAI 的結合，才是王道
真正資深的測試設計者會知道，等價類別、邊界值、決策表、狀態轉移這些方法並不只是教科書內容，而是：
- 讓你在有限時間內測到最多 bug 的策略
- 讓你在模糊需求中建立結構的工具
- 讓你判斷「這樣夠了沒」的準則
而如果能把這些技術，轉化成 prompt 語言與 AI 結合，例如：
- 「請根據以下輸入欄位，使用等價類別與邏輯組合的方式產生測試組合。」
- 「請依照狀態轉移圖，列出所有非法跳轉的測試情境。」
- 「請產出能覆蓋下列條件決策表的測試案例（每筆標記涵蓋條件）。」
你就會發現，AI 開始變得像一個測試助理，而不再只是個會回你幾個 JSON 的聊天機器人。
不需要系統串接，也能做到深度測試設計輔助
很多人會質疑：「那 AI 又看不到我的程式碼，也看不到缺陷紀錄，能幫什麼？」
答案是——設計過程本身。
你不需要它幫你讀 bug，你需要它：
- 幫你刺激更多角度的分類思考
- 幫你補齊你沒想到的異常情境
- 幫你快速建出資料變化組合
- 幫你驗證你寫的測試想法有沒有遺漏條件
測試的價值，不是拿來證明系統沒問題，而是有策略地懷疑系統可能會出問題，而這部分正是 AI 可以發揮思考輔助的區域。
我們要的是更好的問題，而不是更多的案例
與其說 AI 要幫我們寫測試，不如說它幫我們問出對的問題。
一個優秀的測試設計師，不會問「能不能寫出 100 筆測試案例」，而是會問：「這樣的分類設計，是否足以涵蓋這個功能的風險輪廓？」
在 GenAI 的時代，我們要讓 AI 做的，不是幫我們做完工作，而是讓我們的設計思路更全面、風險掌握更到位、邏輯分類更具策略性。
你不再是測試用例的產出者，而是測試設計的導演。
發表迴響