小編精選 - 技術文章翻譯 · 05月01日

我如何運用 AI 修正我們的 E2E 測試架構

我加入了一個專案，該專案已經擁有一個 Playwright 端到端測試套件，包含 38 個規範文件、約 165 個測試案例以及大約 14,000 行測試程式碼。我的第一步很簡單：在本地執行這些測試。

在130次未缺席的測試中，只有8次通過，通過率為6%。

最令人困惑的是，CI 顯示一切正常。結果發現，CI 的所有測試都只使用了workers: 1 ，而多個 worker 加上開發環境，這意味著根本無法在本地執行測試。

第一步：分析－提出我不知道答案的問題

我對這個程式碼庫一無所知。我完全不明白為什麼測驗要這樣寫，自訂包裝器是做什麼的，也不知道真正的問題出在哪裡。所以我開始讓AI分析所有內容，包括Playwright配置、頁面物件、規格文件和CI工作流程。我提出問題來幫助我理解程式碼庫，並找出我們可以做些什麼來讓測試在本地執行。

幾天之內，我們完成了 18 份分析文件，內容涵蓋架構、根本原因、反模式、隱性缺陷和測試隔離。

分析階段的目標是建立一個我不理解的程式碼庫圖。每一份文件都是一個問題的答案。

步驟二：曳光彈計劃

分析完成後，我對需要更改的內容有了清楚的了解。但問題是：更改的順序是什麼？以及如何避免大規模重構導致所有功能崩潰？

答案是曳光彈，這是《程式設計師修練之道》中的一個概念。其想法是建立一個貫穿所有層的精簡端對端切片，以驗證架構的有效性，然後再在此基礎上擴展。

我製作了 8 枚曳光彈，每枚曳光彈都瞄準特定的切片：

UI fixture 鏈— 使用 worker 作用域和 test 作用域的 fixture。驗證：fixture 運作正常，teardown 運作正常，測試在 CI 中通過。
API fixture 鏈－API 測試也採用相同的模式。證明：可組合的 fixture 適用於 API 場景。
擴充 UI 遷移— 將經過驗證的 UI 模式套用到更多檔案。
MFE 範圍的專案— 將一個 Playwright 專案依 MFE 資料夾（應用程式、組織、專案等）分割為 7 個專案，每個專案都有dependencies: ['Setup'] 。
拆卸專案— 使用 Playwright 的專案依賴項新增清理專案。
API fixture 擴充— 可組合的 API fixture（ ownerOrg → ownerProject ）。
大規模 UI 遷移— 剩餘的 UI 規格檔。
API 設定專案— 將空操作的globalSetup取代為適當的設定專案。

關鍵洞察：依賴關係圖告訴我哪些步驟可以並行執行。步驟 1 和 2 是獨立的。步驟 4 也是獨立的。步驟 3 依賴步驟 1。這一點在之後執行多個 AI 會話時變得至關重要。

曳光彈在實際應用上的樣子

第一種方法針對單一文件進行 5 次測試。步驟如下：

新增 fixture 基礎架構（ currentUser → sharedOrg → project ）
將projects-settings-general.spec.ts遷移到使用 fixtures
本地執行，驗證測試通過
推送，驗證 CI 狀態是否為綠色

步驟三：我建立了一個技能來完成這項工作

我制定了一個包含全部 33 項任務並按階段劃分的計劃。我需要一種方法來一致地完成這些任務——每次都採用相同的流程、相同的品質標準和相同的基準。所以我發展了一項技能： pw-test-improvement 。

這項技能的作用

每次變更都需嚴格遵循以下7個步驟：

確定－從實施追蹤表中選擇一項
基準測試－在變更之前執行受影響的測試 3 次，記錄通過率和耗時。
修復——按照劇作家最佳實踐應用更改
測試－更改後執行 3 次，全部必須通過
對比－記錄前後基準資料
更新——將追蹤專案標記為已完成
提交——僅在被要求時提交，並附帶結構化的 PR 描述

該技能內建了知識：Playwright 的定位器優先權（ getByRole > getByLabel > getByText > ...），要避免的反模式列表（ waitForTimeout 、空操作斷言、CSS 類別選擇器、無理由強制點擊），以及將Actions包裝器替換為直接 Playwright 呼叫的遷移模式。

它使用 Playwright CLI 直接執行測試並捕獲結果。

架構變化

固定裝置已更換為樣板

最大的變化是將重複的beforeAll / afterAll程式碼區塊替換為 Playwright fixtures。取代前：5 個測試檔案各自獨立呼叫getUser() 、 createOrg()和createProject() ，總共 15 次 API 呼叫。替換後：使用工作進程作用域的 fixtures，跨檔案共享，總共 7 次呼叫（減少了 53%）。

關鍵區別在於工作者範圍與測試範圍：

工作進程作用域（ { scope: 'worker' } ）－建立一次，即可在該工作進程中的所有測試中共用。適用於組織和專案等高成本部署環境。
測試範圍（預設）－為每個測試建立新的實例。適用於測試會修改的資料。

專案結構

Playwright 配置從執行所有 38 個規範檔案的單一專案變為 7 個專案，每個專案都指向其 MFE 資料夾：

{ name: 'Applications',  testDir: 'apps/ui/applications/e2e', dependencies: ['Setup'] },
{ name: 'Organizations', testDir: 'apps/ui/organizations/e2e', dependencies: ['Setup'] },
{ name: 'Projects',      testDir: 'apps/ui/projects/e2e',      dependencies: ['Setup'] },
// ... Subscriptions, Host, User Profile

這意味著你可以執行--project=Applications來測試你需要的內容，HTML 報告按區域分組，而大型測試案例則有自己的平行設定。

序列級聯修復

實際的 4 個測試失敗看起來像是 57 個。應用程式測試使用了serial模式，因此當第一個測試失敗時，該 describe 程式碼區塊中的所有後續測試都會被標記為「未執行」。解決方法：將複雜的測試案例拆分到專用專案中，增加逾時時間（ beforeAll逾時時間從 30 秒增加到 60 秒），限制工作執行緒數以防止 API 過載，並使用工作執行緒作用域的 fixture 來共享昂貴的設定。

哪裡出了問題

並非所有事情都能一次成功。

清理專案導致持續整合 (CI) 故障。我們新增了一個包含 Playwright 專案依賴項的清理專案，用於在執行後清理測試資料。該專案在本地執行正常。但在 CI 環境中，它導致了故障——清理操作是在共享環境中執行的，幹擾了其他管線。我們不得不撤銷該操作。

並非所有內容都應該使用 fixture。我們嘗試將所有內容轉換為 fixture。但在查閱 Playwright 文件後，我們決定在轉換之前就放棄其中一個 fixture，因為 worker 作用域的 fixture 會在文件之間共享，這將導致需要按文件隔離的串行測試被不同的選項污染。

我如何運用人工智慧

這並非“讓人工智慧來解決問題”，而是一個協作過程：

不斷提問——「這種方法是做什麼的？」「為什麼這個測試不穩定？」「根據 Playwright 的文件，我們可以做 X，你能根據文件驗證一下你的建議嗎？」在持續幾天的分析階段，我問了數百個問題。
對每一個建議都要提出質疑——「你確定嗎？如果是特殊情況 X 呢？」如果人工智慧提出了一種模式，我會要求它解釋原因，並詢問它是否確定這是一種好的方法。
以文件作為基準——我會連結到劇作家的文件，然後問「這與文件中的內容一致嗎？」人工智慧的訓練資料可能過時，但文件是最新的。
使用多種工具進行驗證——我使用了 Goose、Claude Code 和 GitHub Copilot。不同的工具會發現不同的盲點，並給予不同的意見，就像你與不同的團隊成員合作時一樣。
明確詢問置信度－「你對此的置信度是多少？為什麼只有7？我們怎麼才能達到10的置信度？」這不僅能揭示人工智慧可能不會主動提出的不確定性，還能幫助我們更深入地了解我們尚未考慮到的問題以及如何改進。

實際運作

我同時執行了最多 4 個 AI 會話——基於這些追蹤彈彼此獨立的原則。實施計劃中的依賴關係圖告訴我哪些會話可以安全地同時執行。

我會在不同的會話之間切換，查看進度，閱讀修改內容，並在需要驗證時介入。人工智慧負責執行機械性工作，例如應用模式、執行測試和記錄基準資料。我則負責監督，決定下一步的修復方向，發現不合理的建議，並對照 Playwright 的官方文件進行驗證。

每次最多只看四個。我想讀懂並理解所有發生的事情。

我們測量了

| 指標 | 前 | 之後 | 變化 |

|--------|--------|-------|--------|

| 每個檔案的 API 呼叫次數 | 15 | 7 | 減少 53% |

| UI 測試設定行數 | 8 | 3 | 減少 62% |

| API 設定/清理程式碼行數 | 15 | 3 | 減少 80% |

| 包含手動嘗試/最終操作的檔案 | 15 | 0 | 夾具處理 |

| 移除樣板程式碼 | — | — | 約 1,000 行 |

我們一路走來所創造的一切

18份分析文件
5份實施指南
33 個帶有驗證命令的任務
1. 技能（測驗改進）

學到的教訓

關於測試：

綠色 CI 並不意味著測試可以在本地執行。
在串行模式下，一個真正的故障可能會引發數十個虛假故障。
Web優先斷言（ expect(locator) ）可以擷取手動檢查遺漏的時序問題。
固定裝置並非萬能，有些準備工作必須在beforeAll完成。

關於與人工智慧合作：

人工智慧更擅長應用已知模式而非創造新模式，因此要為其製定清晰的流程。
分析階段是人工智慧發揮最大作用的階段，它發現了一些我幾週都可能忽略的問題。
多種工具比單一工具更有效，交叉驗證可以發現幻覺並增強對該方法的信心。
這項技術使其具有可擴展性；如果沒有這項技術，每次修復都需要重複相同的指令。
讓使用者隨時了解狀況，4 個並行會話，全程有人值守
抽出時間去做這些事。一開始會比較耗時，但之後你會取得更大的成就。
使用人工智慧就像對待一位你不太熟悉的新同事，他從不打開攝像頭，所以很難了解他，因此你不能完全信任他，但你知道他有不錯的看法，工作也很出色，但你需要確保他經過深思熟慮，而不是因為懶惰而做出錯誤的決定。