隨著 GenAI 工具（如 Copilot、Cursor、Windsurf）開始自動產生測試程式碼、修補 bug，許多工程師心中浮現熟悉的念頭：
「這不就是更高級的測試自動化工具嗎？ 以後還需要懂測試的人嗎？」
這個問題不新，Selenium、JUnit、CI/CD 剛出現時，我們也曾問過： 「測試人員是不是會消失？」
結果如何？ 沒消失，反而變得更重要——但角色徹底改變了。
現在，GenAI 不會讓測試消失，反而暴露一個長期存在的核心問題：
我們從來沒有好好訓練工程師去思考「測什麼才有意義」。
🚫 誤解一：GenAI 是萬能副駕駛，可以幫你設計出完美測試
GenAI 工具確實可以從自然語言需求中，自動產出測試程式碼，這很強沒錯。 但它並不是真的懂你的系統、商業規則、邊界條件或使用者行為。
✅ GenAI 擅長：
- 根據你寫的函式自動產出單元測試
- 根據範例產出類似測資或 mock code
- 幫你補寫 assertion、測試 scaffold
❌ GenAI 不擅長：
- 辨識需求中的邏輯矛盾或模糊假設
- 預測使用者非預期行為（如錯誤操作序列）
- 分析跨角色、多狀態的業務流程（如訂票、退貨）
換句話說：
GenAI 是 pattern matcher，不是 decision maker。 它可以幫你「寫測資」，但不能替你「設計測試邏輯與策略」。
🎯 你以為測得很全，實際上可能什麼都沒驗到
✳️ 案例 1：改票功能
需求：「使用者可以修改已訂票的車次」
AI 測試產出：
def test_change_ticket_success():
response = client.change_ticket(old_id, new_time)
assert response.status_code == 200
看起來有測試，事實上只覆蓋了 Happy Path。
漏掉什麼？
- 超過改票期限怎麼辦？
- 新車次價格不同要補差價嗎？
- 多人訂票中一人改票時其他人會怎樣？
這些才是導致真實錯誤的來源，而這類問題 不是靠「語意配對」就能測出來的。
✳️ 案例 2：電商退貨流程
需求：「14 天內可無條件退貨」
GenAI 測試產出：
def test_refund_within_14_days():
assert refund(order_id, days=13) == SUCCESS
但沒人問：
- 剛好遇到連假怎麼算？（邊界模糊）
- 促銷商品能退嗎？（例外規則）
- 已開立發票？已刷卡分期？物流已回收？（流程依賴）
這不是「測得不夠」，而是「根本沒想過這些要測」。
🧠 真正的挑戰不是 GenAI，而是我們本來就不太懂怎麼設計好測試
這是整個業界長年存在的問題：
- 測試被誤認為只是「有無 assert」
- Coverage 被當作品質指標，卻無法代表邏輯完整性
- 測試人被當作工具操作者，而非需求對話者
- 測試教育幾乎不存在於主流工程訓練中
所以，當 GenAI 進來幫我們寫測試，我們其實連「它寫的到底好不好」都不知道。
這才是真正令人擔心的事。
🧭 如何讓 GenAI + 人類形成真正的測試升級組合？
✅ 1. 重建「測試設計」的專業意識
- 把測試視為「風險建模」與「例外辨識」的活動
- 導入 Specification by Example、Example Mapping 等對話方法
- 在 Product Backlog Refinement、三方討論會中加入測試設計視角
✅ 2. 定義新時代的測試角色與流程
- 將「驗收範例設計」明確獨立為可追蹤的任務
- 建立「AI 產測、人工 Review、雙重覆核」的流程
- 設置「測試設計導師」或「驗證策略師」角色，專職審視 AI 測試的風險覆蓋度
✅ 3. 善用 GenAI 的優勢，但明確邊界
(1) 單元測試
GenAI 表現：很強
建議方式：可直接使用
(2) 標準業務流程
GenAI 表現：普通
建議方式：人類設計 → AI 寫 code
(3) 高風險例外流程
GenAI 表現：較弱
建議方式：需人工主導設計與審核
(4) 需求含糊處
GenAI 表現：無能
建議方式：必須用人腦先釐清
✨ 結語：測試不是「多寫一些」，而是「釐清要驗什麼」
GenAI 是把測試設計外包出去的機會，但你不能不知道自己外包了什麼。 它是你的寫手，不是你的思考器。
未來真正有價值的測試人，不是會寫測資的人，而是會問這些問題的人：
- 這需求裡有沒有模糊處？
- 這個流程中有哪些例外沒被提到？
- 這樣測，有沒有盲區？
只要這些問題還沒被 AI 解決， 測試這門專業就還活得好好的——只是名字會變。
發表迴響