Skip to main content
AI 時代的自動化測試與驗收（一）：從測試金字塔到信任系統

Architecture Journal

Last updated on
aitestingverification

AI 時代的自動化測試與驗收（一）：從測試金字塔到信任系統

最近跟人聊 AI 開發，最常被問到的問題已經不是「AI 能不能寫」，而是「它寫得那麼快，我們怎麼相信它寫對了」。

GitHub 那篇〈AI made code easy. Trust is now the bottleneck.〉講的其實就是這件事：程式產出已經不再是瓶頸，信任才是。 [1]

很多人談 AI 開發風險時，還是會把問題收斂成一句「AI 產出品質不穩」，但現在的風險結構已經不太一樣了。社群裡大型 AI 任務翻車的案例，問題多半不是它直接亂寫一通，而是它會持續產生一個看起來很合理的進度敘事——每一步都像在推進，每一輪回報都像在收斂，但真正被驗證過的東西，可能比你以為的少很多。 [2]

如果只是做 demo，很多事情都可以先過。畫面能跑、流程能動、測試有幾個綠燈，通常就足以讓人往下一步走。但一碰真實專案，問題就會完全變樣：

  • 這個結果是不是只是看起來合理？
  • 它是不是漏掉了最重要的邊界情境？
  • 它說已完成，到底是指文字上完成，還是有證據支持的完成？

我後來越來越覺得，AI 時代真正需要被工程化的，不是生成，而是驗證。這篇是這個系列的第一篇，我想先把地圖畫出來。後面每一篇，都會沿著這張地圖往下一層走。

信任不是一個問題，是五個問題

大家熟悉的測試金字塔，通常是用執行速度與維護成本來解釋：底層測試多、快速且便宜；越往上越少、越慢也越脆弱。這個原則在 AI 時代依然有效。

但它還多了一個角色：把信任拆成不同粒度的回饋迴路。

層次它主要在問什麼最適合抓的問題
Unit test單一規則是否成立？邊界條件、計算、狀態轉換、domain rule
Integration test元件接在一起時是否正確？資料庫、queue、框架設定、實際序列化
Contract test系統邊界的承諾是否一致？API schema、事件格式、consumer/provider 假設
E2E test關鍵使用者流程是否走得完？跨服務流程、前後端整合、部署後煙霧測試
Acceptance交付是否值得被接受？需求意圖、使用情境、風險與商業判斷

每一層答一個不同的問題。unit test 問「這段邏輯還符合我們的規則嗎」，契約測試問「邊界上的雙方還說同一種語言嗎」，E2E 問「真正的使用者流程還走得完嗎」，驗收問「這次交付的產品，還是我們要的那個東西嗎」。

這不是要把每個行為都在每一層測一次。每一層都有自己的責任。把所有信心壓在 E2E，CI 會又慢又脆；只寫 unit test，很容易到服務邊界才發現大家理解不同。

真正的工程問題，是每一層都要說得出自己保護哪種風險，也接受什麼不該由自己負責。

測試與驗收是兩件事

自動化測試要驗證的是「系統依照已知規則運作」。驗收要回答的則是「這個交付是否真的解決了要解的問題」。兩者會重疊，但不能互相取代。

登入流程的 unit test、API 測試和 E2E 測試都通過，只能說已被編碼成測試的行為仍然成立。它不會自動告訴你：新使用者是否看得懂登入方式、權限要求是否合理、流程是否符合這次產品調整的目的。

AI 特別容易放大這個差別。它很擅長依照明確規格產生程式碼與測試；但如果規格本身模糊，或團隊還沒辨認出真正的風險，AI 也會很有效率地把錯誤的假設固定下來。

測試保護已知的規則；驗收檢查我們是否選對規則。

AI 到底改變了什麼

第一，測試案例不再稀缺

AI 可以很快補上 parameterized test、邊界值、fixture 和重複性高的測試骨架。真正稀缺的是能否辨認「哪個不變量值得保護」。金額不可為負、庫存不可超賣、退款後狀態不可回復為已出貨——這些不是 AI 自己能從空白專案可靠猜出的事。

第二，改動成本下降，回歸風險上升

當 agent 可以一口氣跨檔案重構時，好的測試該當成一張讓人敢於小步改動的安全網，而不是事後的檢查清單。測試要快到能放進 agent 的迴路裡，不能等到合併前才知道結果。

第三，測試本身也要被審查

AI 生成的測試可能只是在驗證實作細節，甚至直接重述被測程式的錯誤邏輯。審查時應先問：如果把實作換成另一種正確寫法，這個測試還有意義嗎？如果需求被誤解，這個測試抓得到嗎？這類把 AI review 與測試優先綁在一起的討論，Uncle Bob 最近也有談。 [3]

金字塔之外，還需要一層橫切的驗證能力

金字塔定義了每一層驗什麼，但它沒有回答一件事：完成條件誰定義、證據誰來收、門檻誰來設。

當 agent 開始參與需求分析、規格轉換、程式生成、測試生成、維運排查這整條流程時，驗證就不該只是最後一道 QA 關卡，而應該是一層獨立的工程能力，也就是我說的 Verification Engineering。

完成，不能被「它說沒問題」定義

如果今天一個 agent 跟你說「這個功能已完成」，那到底代表什麼？如果完成只是它自己說完成了、PR 看起來很完整、測試全部綠燈，那這個完成其實還很脆弱。

我現在比較傾向把完成定義成三件事：

  • 有客觀證據支持，不是只有模型回報
  • 能被另一個人或另一套流程獨立驗證
  • 能重跑、能重現，而不是一次性的對話結果

我會把這件事想成蓋房子。土木工程、泥作、灌漿，甚至部分結構施工，都可以交給不同的承包商。每家承包商的工法、工具和速度可能不同，能力也不會完全一樣。放到 AI 開發裡，這些承包商就像不同的 LLM provider 或 agent。

但承包商可以換，驗收標準不能跟著換。地基要承受多少重量、結構要符合什麼規範、管線要怎麼測試，不能因為這次換了一家施工團隊，就改成「這家說可以，所以算完成」。AI 產物也是一樣：模型可以負責生成，provider 可以替換，施工方法可以不同，但完成條件、測試證據與上線門檻，仍要由產品和工程團隊自己定義並驗收。

驗證的對象，常常是實作背後的假設

以前講驗證，我第一個想到的是 correctness。功能有沒有照需求跑、測試有沒有過、輸入輸出有沒有對。但 AI 產物最麻煩的地方，往往在表面看不出來：它跑得動、也過得了測試，卻偷偷把一堆沒講清楚的假設補進去：

  • 它假設某個商業規則永遠成立
  • 它假設某個例外流程不重要
  • 它假設使用者行為會很單純
  • 它假設未來維護的人看得懂這段設計

這些東西如果沒被挑出來，系統一開始可能真的能跑。但之後只要需求一變、資料一髒、流量一上來，問題就會冒出來。所以好的驗證不只是檢查「有沒有寫對」，而是主動去問：哪些測試其實還沒寫？這個實作偷偷依賴了哪些前提？哪些情境是現在流程根本沒覆蓋到的？

這個方向，不是我們獨自發明的

台灣長期推敏捷與測試的 David Ko 柯仁傑，最近幾場公開分享都在講很類似的事。 [4] [5] 他的切入點不反對 GenAI 介入測試，反對的是把 GenAI 想成一台自動出題機。AI 產出的測試個案，真正的問題從來不是「生不生得出來」，而是真的能照表操課執行嗎、涵蓋率真的夠嗎、不懂測試的人只靠 prompt 做得好嗎。背後還是要靠 Specification by Example、Exploratory Testing 和 test case design techniques 這些基本功，AI 只是把能力放大，不會憑空替代。 [5]

Martin Fowler 最近幾篇談 AI coding agent 的文章，也在往同一個方向收斂。 [6] [7] [8] [9] [10] 他沒有把焦點放在「模型會不會越來越強」，而是放在 harness、review loops 和 sensors。真正能提升信任的，是把規格、檢查點、持續監測與回饋訊號包成一套外部結構，讓 agent 的輸出不必只靠人類事後猜；多喊幾次「請仔細檢查」，其實沒什麼用。

Kent Beck 對 code review 的描述也很直接。 [11] 傳統 review 在 AI 加速之前其實就已經有點撐不住了，PR 放著等、reviewer 沒時間、最後變成 LGTM 式橡皮圖章。一旦生成速度被拉高，這套做法更不可能是主力——不是 reviewer 不努力，而是回饋迴路本身已經跟不上。他也提到一個我很喜歡的觀點：把多個 AI assistant 之間的不一致當成一種 verification 訊號，用分歧暴露假設、比較設計，逼自己做更有意識的判斷。 [12] [13]

做重有代價，所以要看風險分級

當然，verification 不是一句話喊完就沒有代價。你把驗證做重，前期要花更多時間定義完成條件，測試與驗證腳本本身也需要維護，團隊流程短期內會變慢；有些小型任務如果也套同樣強度，反而會過度設計。

所以這不是叫大家把所有 AI 任務都升級成高監管流程。比較務實的做法是分級：低風險、可逆的小任務，給比較輕的驗證；高風險、跨系統、不可逆、會直接影響使用者或資料的任務，就必須有更重的 gate。

這裡真正困難的地方，不是工具怎麼選，而是團隊願不願意先把風險邊界講清楚。當 AI 產出越來越多之後，團隊也不可能永遠靠人逐行把每一段都看完。重點不是人有沒有看過每一行，而是錯的東西能不能被結構性地擋下來。

這個系列接下來怎麼走

這篇是地圖，不是終點。測試與驗收真正的功力，在逐層的實務裡。接下來我會沿著金字塔從下往上寫：

  1. Unit test：先把 domain rule 釘住，什麼該測、什麼不該 mock、如何讓測試替重構提供信心
  2. 整合測試：不要只測你以為的框架行為，資料庫、訊息系統、序列化與外部依賴該怎麼驗
  3. 契約測試：在服務邊界保護共同承諾，consumer-driven contract 適合什麼情境，又有哪些成本
  4. E2E 測試：只保護最重要的旅程，如何避免把 E2E 寫成又慢又不可靠的大雜燴
  5. 驗收與 agent workflow：綠燈之後誰來判斷？，把驗收條件、人工探索與 AI agent 的交付流程接起來

每一篇我都想回答同樣三個問題：這層到底驗證什麼、擋住哪種風險、AI 時代哪裡變了。

如果金字塔每一層都能各自守住邊界，團隊才會同時得到兩件事：更快的改動速度，以及對改動仍然可信的理由。沒有這層信任結構，AI 帶來的效率，多半只是把風險更快擴散。

參考資料