叫 AI 寫測試之前，先叫它當一次使用者

你叫 AI「幫這個功能補 E2E 測試」。它讀完程式碼，十分鐘交出一排 Playwright 腳本，跑起來全部綠燈。上線之後，使用者卡在一個測試從來沒走過的地方。

我之前遇過一次。專案有 871 支測試全綠，核心流程卻被一張新彈窗擋住兩天。回頭查才發現，其中一百三十多支只是讀原始碼比對字串，另外二十多支會開瀏覽器跑畫面的測試，因為太慢被移出自動檢查。

後來在一則回覆裡，我寫下現在的做法。

目前的做法是先讓 Agent 實際操作，從使用者的角度探索功能、找出可能的 test case。

確認流程與預期行為都沒問題後，再把這些操作轉成 Playwright E2E 自動化測試腳本，放進 CI 流程。

重點在順序。先操作，再寫腳本。

只叫 AI 讀程式碼寫測試，哪裡不對？

它驗的是程式碼說它會做的事，不是使用者實際會碰到的事。

AI 讀程式碼時，看到的是函式、按鈕的 id、API 路徑。它照這些寫測試，很自然會寫成「按下這個 id，應該送出這個請求」。但程式碼看不出來的事，像是新彈窗擋住按鈕、載入太慢按鈕還不能按，測試就不會去驗。

讓 Agent 打開瀏覽器，用使用者的角度從頭走一遍，這些東西會直接撞上來。它點不到按鈕，就會回報點不到。過程中它也會碰到你沒列出的情境，例如存檔後重新整理，資料還在不在。這些就是 test case 的來源。

Playwright 官方的 Test Agents 也照這個順序分工，先探索應用、寫出測試計畫，再照計畫產生測試。

操作一次是為了找出該測甚麼；確認之後就要轉成腳本，不然每次都要重付一次操作的時間和額度。

AI 很愛一格一格點畫面來測試，我改遊戲時就抱怨過這件事。這種操作慢，又吃額度，而且每次點的路徑不一定一樣，昨天過、今天不過，你分不出是功能壞了還是它點歪了。

腳本剛好相反，固定走同一條路，放進 CI 後每次推程式碼都會自動跑。所以 Agent 操作的價值在第一次，用來找出路徑、讓你確認預期行為。確認完，就交給腳本。

照我現在的做法，分三步。

1. 讓 Agent 當使用者走一遍，先不要寫測試。 可以直接這樣交代它。

請在測試環境，用測試帳號，從使用者入口實際操作這個功能，找出值得測試的情境。每個情境回報操作步驟、實際結果、你建議的預期結果，以及需要我確認的地方。先不要寫 E2E，等我確認後再產生腳本。

2. 你確認預期行為，再叫它寫成腳本。 它交回來的回報會像這樣。

操作步驟	它看到的	待你確認
修改資料、按儲存、重新整理	重新整理後，資料變回舊的	這個欄位應該永久儲存，還是只留在這次操作？

「它看到的」和「應該發生的」要分開。這一格如果你不確認，它會把「資料變回舊的」當成正確結果寫進測試。確認完，再叫它把要測的情境寫成 Playwright 腳本，實際跑過再放進 CI。

3. 定期整理一份核心流程清單。

也會請 AI 定期整理產品的核心測試流程，確認哪些功能一定要驗證、哪些情境容易出問題，整理出哪些地方是至少都要讓 AI 親自操作過一次的。

之後只要核心畫面改了或加新功能，就回到第一步，讓 Agent 照清單再親自走一次。測試紅燈時也一樣，先確認產品行為對不對，再決定要修產品還是修測試，不要直接叫它把舊腳本修到綠燈。

我的產品照這套方式開發了好幾個月，至少到現在沒出過甚麼大包。

測的是純邏輯。 計算、格式轉換這類沒有畫面的東西，單元測試就夠。權限和後端資料，要靠 API 或整合測試，不能只靠點畫面。
畫面還天天在變。 原型期每天改版，寫好的 E2E 腳本隔天就壞。先讓 Agent 操作、記下問題，只把一定要穩定的核心流程寫成腳本，其他等流程定了再補。
你自己也還說不出預期行為。 Agent 操作時看到甚麼，就會當成「應該這樣」。你沒先確認，它會把現在的 bug 寫成測試的標準答案。

下次叫 AI 補 E2E 之前，先問一句：這條路，它自己點過了嗎？

如果你手上已經有一大排綠燈、不確定它們有沒有在驗東西，可以接著讀那篇 871 支測試全綠的檢討，裡面講怎麼把已經寫好的假測試找出來。