AI 時代，測試的 Domain Knowledge 比過去更重要

AI 時代，測試的 Domain Knowledge 比過去更重要 目錄 1. AI 把測試變容易了，但問題也來了 2. AI 生成，人來判斷值不值得跑 3. Prompt 品質就是 Domain Knowledge 的輸出 4. AI 沒有你的 Bug History 5. AI 製造假安全感 6. 剩下給人做的，全都是高判斷力的工作 7. 結尾 AI 把測試變容易了，但問題也來了 現在要生成一批測試案例很簡單：把需求貼給 AI，它幾秒鐘就能輸出格式整齊的測試清單——正常流程、空值、邊界值、異常處理，樣樣都有。 看起來很完整。 但測了之後發現，這批測試案例沒有抓到任何你不知道的問題。它測的東西，你本來就知道要測。真正容易漏的——產品特定的邊界邏輯、歷史 bug 的重現路徑、兩個功能交互產生的奇怪狀態——AI 完全沒有提到。 AI 把「生成測試案例」這件事的門檻降低了。但同時，它也讓「你懂不懂這個產品」的差距變得更明顯。 AI 生成，人來判斷值不值得跑 AI 可以大量產出測試案例，但「這個案例有沒有測到真正重要的東西」，還是需要人判斷。 這個判斷力的底層是 domain knowledge。 沒有它，你只能看測試案例的數量，不知道方向對不對。一千個通用測試案例，可能不如十個針對這個功能歷史問題設計的案例。但如果你不知道這個功能的歷史，你沒有辦法做這個判斷。 AI 改變的是生產速度，不是判斷標準。判斷標準還是要靠人，靠的就是 domain knowledge。 Prompt 品質就是 Domain Knowledge 的輸出 你怎麼描述問題，決定 AI 給你什麼答案。 同樣是「幫我設計計時功能的測試案例」，有 domain knowledge 的人會這樣描述： 我們的 App 的計時功能有一個 08:00 切換邏輯：08:00 前完成的種植累積到昨日進度，08:00 後開始的累積到今日。跨越 08:00 的種植歸屬需要確認 AC（開始時間或結束時間為準）。另外，離線狀態下完成的種植，恢復網路同步後，歸屬時間不應被同步時間影響。 這樣的 prompt 得到的測試案例，和只貼一段 AC 文字得到的，是完全不同層次的東西。 domain knowledge 決定你能不能問出好問題。AI 放大的是你問問題的能力，不是幫你產生問問題的能力。 AI 沒有你的 Bug History AI 不知道你們去年踩過什麼坑。 它不知道 App 的帳號連結功能在 Google 登入和 Apple 登入同時存在的時候有過什麼問題。它不知道哪個模組在裝置切換背景和前景的時候最容易出現狀態不同步。它不知道訂閱過期邊界那天的行為有過什麼 bug。 這些只存在人的記憶和知識庫裡。 AI 從需求文字推測測試案例，但測試案例的價值往往在需求沒有寫的地方——之前踩過的坑、裝置特定的行為、活動機制和計時邏輯的交互。這些東西 AI 沒有，只能略過。 有 domain knowledge 的 QA 知道要在哪裡多測一層，因為他們記得上次是怎麼壞的。 AI 製造假安全感 AI 生出來的測試套件，看起來很完整。 格式整齊、分類清楚、邊界值都有考慮——但可能系統性地跳過了最重要的場景，因為那些場景藏在產品特定的邏輯裡，不在通用測試框架能推導出來的範圍內。 沒有 domain knowledge，你沒有辦法分辨「覆蓋得廣」和「看起來覆蓋得廣」的差別。 這是 AI 輔助測試的一個真實風險：AI 讓人覺得測試做得很完整，但完整的是格式，不是覆蓋。如果 QA 沒有足夠的 domain knowledge 去驗證這份完整性，假安全感比沒有安全感更危險。 剩下給人做的，全都是高判斷力的工作 AI 把機械性的工作拿走之後，人負責的是什麼？ 這個 bug 算不算 blocker？ 這次 release 的風險在哪裡？ 這個 AC 有什麼沒寫清楚，會變成測試死角？ AI 生成的這批案例，哪些值得跑、哪些可以刪？ 每一個問題都需要判斷力。判斷力的底層是對產品的理解——計時規則怎麼運作、訂閱狀態怎麼影響功能、哪個模組最脆弱。 Pre AI 時代，QA 的工作是「理解需求 + 設計測試 + 執行測試」。AI 時代，執行的部分被拿走了，設計的部分被加速了，但理解需求的部分沒有被取代——而且因為後兩個步驟變快了，理解需求這個環節的品質反而變得更關鍵。 結尾 計算機出現之後，不讓數學家失業，但讓「只會算術」的人失業了。 AI 測試工具的邏輯類似：它讓「只會按步驟執行測試」的人的價值降低，但讓真正懂產品的 QA 的價值提高——因為 AI 放大了你，你懂得越多，AI 幫你做的就越有價值。 我自己做了一個叫 QA Brain 的系統來驗證這件事。它是一個給 AI 用的 QA 知識庫，把 App 的計時規則、訂閱邏輯、歷史 bug pattern、裝置行為差異整理成有 schema 的結構，讓 AI 在設計測試案例或診斷 bug 的時候有東西可以依賴。 結果很明顯：同樣是「幫我設計這個功能的測試案例」，餵給 AI 通用需求文字，得到的是通用清單；餵給 AI 有產品知識的 QA Brain，得到的是考慮過 08:00 切換邏輯、離線同步、跨裝置訂閱狀態的具體案例。 但 QA Brain 有多好用，取決於裡面的知識有多深。知識是我累積的，AI 只是讀它、放大它。如果裡面沒有 domain knowledge，QA Brain 就是一個空架構。 domain knowledge 不是靠文件累積的，是靠跟產品一起出過問題、踩過坑、找過根本原因累積的。這個過程 AI 幫不上忙，只能靠時間和經歷。 AI 時代，這才是 QA 真正的護城河。 常見問題 Q：AI 工具可以取代 QA 嗎？ A：AI 取代的是機械性的工作，例如生成通用測試案例、執行重複腳本。但「這個 bug 算不算 blocker」、「這次 release 的風險在哪裡」、「AI 生成的案例哪些值得跑」——這些判斷性工作需要 domain knowledge。AI 沒有你的產品歷史，沒有辦法替代這個判斷力。 Q：什麼是測試的 Domain Knowledge？怎麼累積？ A：Domain knowledge 是對特定產品的深層理解：計時規則怎麼運作、哪個模組最容易出問題、歷史 bug 的重現路徑、兩個功能交互的奇怪狀態。它不靠文件累積，而靠和產品一起出過問題、踩過坑、找過根本原因才能形成。這個過程 AI 幫不上忙，只能靠時間和經歷。 Q：為什麼我用 AI 生成的測試案例感覺很通用、沒有針對性？ A：因為 AI 只能從你提供的資訊推測。你給它通用需求文字，它給你通用清單。Prompt 品質就是 domain knowledge 的輸出——懂產品的 QA 描述問題時會帶入產品特定的邊界邏輯、離線同步邊界、跨裝置狀態這類細節，得到的測試案例才會有針對性。 Q：AI 生成的測試套件看起來很完整，怎麼判斷它真的夠用？ A：「覆蓋得廣」和「看起來覆蓋得廣」有本質差別。AI 可能系統性地跳過最重要的場景，因為那些場景藏在產品特定邏輯裡，不在通用測試框架能推導的範圍內。沒有 domain knowledge 很難分辨這兩者——這是 AI 輔助測試最真實的風險：假安全感比沒有安全感更危險。 參考資料 ISTQB — AI Testing Foundation — ISTQB AI 測試師認證，定義 AI 時代 QA 的核心能力 Gartner — AI in Software Testing — Gartner 對 AI 與測試自動化趨勢的分析 Capgemini — World Quality Report 2024 25 — AI 測試工具採用率與效果的全球調查 Google Testing Blog — ML Testing — Google 如何測試機器學習系統 Microsoft — Responsible AI Testing — AI 系統的測試倫理與品質標準