用一個真實案例告訴你：Playwright三大AI助手，有多香！

近期測試圈有一個爆火的AI小團體，它就是Playwright 的團隊研發的3個AI小助手，名字挺唬人：Planner、Generator、Healer。

但說白了，就是三個干臟活累活的“小弟”：

• Planner：打開你的應用，到處點點看看，輸出一份測試計劃（Markdown）；
• Generator：把測試計劃翻譯成 .spec.ts 測試代碼；
• Healer：跑失敗的測試，嘗試自己修。

它們統稱為：Playwright Test Agents ，就是 Playwright 框架在原生版本集成的三款 AI 助手，主要用來解決自動化測試的核心難題：幫你“想”（Planner）、幫你“寫”（Generator）、再幫你“修”（Healer）。

今天咱們從一個實際經歷出發，看看他實操下來到底順不順利，碰到哪些麻煩，怎么搞定的，最后學到了啥。

項目背景

公司有個內部數據中臺，因為開發換了好幾撥，文檔幾乎等于沒有，公司最近規范文檔，需要把核心流程（登錄 → 數據源配置 → 創建數據集 → 發布 API）的 E2E 測試補上。

拿行內的話說，這簡直就是一個“屎山”項目。

實踐過程分享

第一步：Seed 測試

操作步驟：

官方文檔說，先寫一個 seed.spec.ts，用來做環境初始化和前置驗證。

因為項目里需要先登錄，登錄之后還要等幾個異步權限加載完成才能進到主頁。

所以一開始寫得很簡單：

test('seed', async ({ page }) => { await page.goto('https://xxx.com/login'); await page.fill('#username', 'myuser'); await page.fill('#password', 'mypass'); await page.click('button:has-text("登錄")'); await page.waitForURL('**/dashboard');});

跑一下，通過。然后開始執行 npx playwright init-agents --loop=vscode，初始化 Agent。

結果展示：

結果 Planner 開始探索時，直接在登錄頁卡住。

因為 Seed 里沒有把登錄態保存下來，Planner 每次啟動都會重新走一遍 seed 流程，但不知道哪里沒處理好，總是登錄失敗。

原因分析：

Planner 在探索的時候，會重新運行 seed 測試中的每一步，但它是通過 MCP 工具來操作瀏覽器的，和本地手動跑 test 的環境不一樣。比如項目的登錄接口有 CSRF token，seed 測試里用了 page.context() 的 cookie 復用，但 MCP 工具沒有自動帶上。

重試過程：Seed 測試不能只保證“能跑通”，還要保證能夠被 Agent 正確重放。最好的實踐是：Seed 里只做最簡單的頁面打開和基本元素檢查，把登錄和認證放到 自定義 fixture 里，然后在 playwright.config.ts 里配置 storageState。

改成如下：

// fixtures.tsimport { test as base } from '@playwright/test';export const test = base.extend({ authenticatedPage: async ({ page }, use) => { await page.goto('/login'); // 登錄邏輯 await page.context().storageState({ path: 'auth.json' }); await use(page); },});

然后在 seed 里直接 test.use({ storageState: 'auth.json' })。這樣 Planner 就不會每次都被登錄流程拖累了。

經驗總結：Seed 測試是為 Agent 服務的，不是簡單為了測通一個場景。 需要理解 Agent 的執行模型，才能把基礎打牢。

第二步：Planner輸出測試計劃

操作步驟：

把 Planner 指向了數據源配置頁面，讓它生成測試計劃。提示詞如下：

@planner 為數據源配置頁面生成測試計劃。主要功能：添加 MySQL 數據源，填寫 host、port、用戶名、密碼，測試連接，保存。覆蓋異常場景：連接超時、認證失敗、必填項為空。

Planner 確實打開了頁面，到處點點點，最后生成了一份 Markdown 計劃，看著挺全：什么“TC001 正常添加數據源”“TC002 密碼錯誤時提示”“TC003 測試連接按鈕在未填 host 時應禁用”……

出現問題：

老項目里，“測試連接”按鈕的啟用/禁用邏輯根本不是由前端驗證的，而是后端實時返回的權限字段控制的。所以 Planner 生成的 TC003 在現實中根本不成立——因為即便 host 為空，按鈕也可能是啟用的（后端說這個用戶有權限，前端就亮著）。

如果把這個計劃直接交給 Generator 生成代碼，跑起來必然失敗，而且不是 UI 變化導致的失敗，是業務邏輯和 Plan 不符。

原因分析：

Planner 再聰明，它也只是一個基于可訪問性樹和頁面交互的表層探索。它看不到業務規則，看不到代碼里的 if-else 邏輯。所以它生成的測試計劃，必須要人工過濾和修正，不能全盤接收。

最后只采用了 Planner 給出的 60% 的場景，刪掉了那些涉及復雜業務規則的，自己又補了幾個真實容易出錯的邊界（比如“保存數據源時網絡斷開”這種 Planner 根本不會主動去測的）。

第三步：Generator 生成測試代碼

操作步驟：

Generator 根據修改后的計劃，生成了 datasource-add.spec.ts。

幾秒后，tests/datasource-add.spec.ts 生成了。我打開一看，定位符竟然用的是 getByRole 和 getByText，而不是我擔心的 hash 類名。

test('搜索無結果時顯示空狀態', async ({ page }) => { await page.goto('/users'); await page.getByRole('searchbox').fill('一個不存在的用戶名'); await page.getByRole('button', { name: '搜索' }).click(); await expect(page.getByText('暫無數據')).toBeVisible();});test('分頁切換后搜索條件應保留', async ({ page }) => { await page.goto('/users'); await page.getByRole('searchbox').fill('張三'); await page.getByRole('button', { name: '搜索' }).click(); await page.getByLabel('第 2 頁').click(); // 驗證搜索框內容依然是“張三” await expect(page.getByRole('searchbox')).toHaveValue('張三');});

它避開了Ant Design 3 那種 ant-select-dropdown-xxxxx 的class名，而是用了組件自帶的 ARIA 屬性（比如 getByLabel 對應 label 標簽）。這是因為它讀取的是可訪問性樹，不是 DOM 結構。

太爽了——這意味著即使前端升級Ant Design版本，這些定位符大概率依然有效。

出現問題：

當然也有小問題。比如它生成的斷言里用了page.waitForTimeout(1000)，改成了 waitForSelector。還有一個斷言期望文案是“成功”，實際接口返回的是“操作成功”，改了一下。但這些修改量很小，比自己從零寫快太多了。

總結：

Generator 生成的代碼質量已經超過很多初級測試工程師。把它當草稿，人工優化斷言和等待，效率至少提升 80%。

第四步：Healer修復

生成代碼后，跑了一遍全量測試。17個測試通過了14 個，掛了3個。把失敗信息發給Healer：

@healer 修復 tests/user-list.spec.ts 中失敗的用例

Healer 修復過程如下：

• 失敗 1：“測試連接”按鈕定位超時。原因是該項目的 Ant Design 3 在加載中會替換按鈕 DOM 結構，原來的 getByRole('button', { name: '測試連接' }) 找不到。Healer 重新分析了頁面，發現加載期間按鈕的 aria-label 變成了“加載中”，加載完成后恢復。它把定位改成了 page.getByRole('button').filter({ hasText: /測試連接|加載中/ })，并加了一個 waitForState 等待按鈕可用。重跑，通過。
• 失敗 2：保存數據源后，斷言“列表中出現新數據源”超時。Healer 發現是因為保存后列表刷新較慢，原來的 waitForSelector 超時時間太短。它自動把超時從 5 秒增加到 15 秒，并加了一個 waitForResponse 等待保存接口返回。重跑，通過。
• 失敗 3：添加重復名稱時，斷言“提示重復”失敗。Healer 嘗試了幾次，發現提示文案實際是“數據源名稱已存在”，而預期是“重復”。它沒有擅自改斷言，而是報告“預期文案與實際不符，請確認業務邏輯”，然后把測試標記為 skip。檢查了一下，發現是產品后來改了提示文字，但測試計劃沒更新。當更新了計劃中的期望文案，重新生成，就過了。

思考：Healer 不會盲目讓測試變綠。它能區分“定位問題”“超時問題”和“業務邏輯變化”，前兩種它會自動修，第三種它不會強繞。這讓人很放心。

總結

什么人適合用？怎么用效果最好？

適合的場景：

• 你要給一個Web應用從零開始寫E2E測試，尤其是你不熟悉業務細節的時候（Planner 幫你探索）。
• 你的項目UI頻繁變化，手動維護選擇器成本高（Healer 是真救星）。
• 你想快速驗證一個新功能的核心路徑是否穩定（Generator 幾分鐘出一版腳本）。

不太適合的場景：

• 你的應用有復雜的非標準交互（比如 Canvas、WebGL），Agent 可能探索不到。
• 你需要深度定制斷言邏輯（比如數據庫校驗），AI 生成的代碼只能做基礎驗證。

最佳實踐建議：

1. Seed 測試里不要放復雜登錄，用 storageState 保存認證狀態。
2. Planner 生成的計劃要人工過濾，它不懂你的業務優先級。
3. Generator 生成的代碼當草稿用，斷言和等待你自己優化一遍。
4. 給 Healer 設好保護上限（比如最多自動修3次），避免它亂改預期。
5. 最終代碼提交前，一定要跑一遍全量測試，確保修復沒有引入新問題。

看到這，大家還覺得AI能取代自己嗎？它只是從“寫定位符、調超時、改class 名”這種重復勞動中解放了出來。省下來的時間，去思考更深層次的測試策略，比如怎么造數據、怎么覆蓋更多邊界。

如果你也在被E2E測試折磨，花一下午試試 Playwright Test Agents。不保證完全無痛，但保證比你硬寫爽得多。

??想了解更多漲薪技能提升方法

??可以到公主號【Atstudy技術社區】,即可加入領取 ??????

??轉行、入門、提升、需要的各種干貨資料

??內含AI測試、 車載測試、AI大模型開發、BI數據分析、銀行測試、游戲測試、AIGC