近年來，Playwright 作為一款跨瀏覽器、跨平台的端到端自動化測試框架，越來越多的測試團隊選擇它替代 Selenium 或 Puppeteer。 它提供了強大的 API 和智能等待機制，但在實際項目中，很多團隊仍會遇到各種坑。今天，我們結合行業實踐經驗，總結 Playwright 最容易踩的坑及解決方案，讓你的測試更快、更穩定。
1. 按風險級別組織測試
坑點：按功能模塊組織測試會導致發版流水線臃腫，低風險 UI 也佔用時間。 解決方案：
- 高風險場景（登錄、下單、支付）快速精準覆蓋並嚴格斷言。
- 低風險 UI 細節放到夜間全量回歸。
實踐：維護 @smoke 和 @full 標籤，冒煙測試每次提交跑，全量回歸在夜間或發版前跑。
2. 使用穩定的定位策略
坑點：複雜 CSS 或文本選擇器容易導致測試不穩定。 解決方案：
- 優先使用 data-testid，作為代碼與測試的契約。
- 在 PR 檢查中要求核心 UI 元素必須加測試 ID。
3. 充分利用 Playwright 自動等待
坑點：手寫 waitForTimeout 或固定等待時間會導致測試不穩定。 解決方案：
- 使用 Playwright 內置自動等待和 web-first 斷言。
- 必要時綁定到明確信號：網絡請求、元素出現或 URL 變化，而非毫秒數。
4. 用 fixtures 管理認證和環境狀態
坑點：每個測試重新登錄導致測試慢且脆弱。 解決方案：
- 使用 storageState 保存登錄態，每個測試啓動時即登錄狀態。
- 測試更快、更穩定、可讀性更高。
5. 通過 API 準備測試數據
坑點：UI 操作慢且容易失敗。 解決方案：
- 優先用後端接口準備測試數據，然後在 UI 驗證結果。
- 若無測試專用接口，可創建受控 /api/test/* 命名空間，僅在 CI 環境開啓。
6. 控制網絡請求，Mock 不可控依賴
坑點：第三方接口不穩定導致測試掛。 解決方案：
- 使用 HAR 文件或 stub 關鍵接口保證穩定性。
- 保留一套真實環境 Canary 測試監控外部接口變化。
7. 視覺迴歸測試要有的放矢
坑點：動態區域可能導致大量無用 diff。 解決方案：
- 對動態區域設置 mask 或閾值。
- 從小範圍開始（收據、PDF 或核心儀表盤），逐步擴大覆蓋面。
8. Trace 和視頻只在必要時開啓
坑點：全程錄製 Trace / 視頻浪費時間和存儲。 解決方案：
- 僅在測試失敗或重試時開啓 Trace。
- 保證快速通過，同時失敗時有完整信息。
9. 合理設置併發數
坑點：盲目增加併發可能引發資源競爭，反而不快。 解決方案：
- 先 Profile 測試套件，找出瓶頸。
- 只在總耗時確實降低時才增加 worker 數量。
10. 按用户場景組織，別死磕 Page Object
坑點：Page Object 容易臃腫，難維護。 解決方案：
- 採用“劇本式” helper 函數，用穩定定位器組合業務操作。
- 測試代碼讀起來像講故事，更直觀易懂。
11. 讓不穩定性可見
坑點：掩蓋不穩定測試會影響主流程的可信度。 解決方案：
- 用註解標記不穩定測試。
- 跟蹤每個 spec 文件的不穩定率，超過 1% 就該修復。
12. 優化測試報告
坑點：報告難讀、難定位問題。 解決方案：
- 標準化產物命名，突出關鍵信息：失敗步驟、截圖、Trace、網絡請求。
- 配置 CI，把 HTML 報告和 Trace 暴露為構建產物。
- 定位問題只需兩次點擊，不搞尋寶遊戲。
實戰案例
在實際項目中，有團隊在使用 Playwright 做 UI 測試時遇到以下問題： 問題：
- 600 多個 UI 測試，跑完 42 分鐘，每 5 次 run 就掛 1 次。
- 通過採納以下優化措施，取得了顯著效果：
- 核心 UI 元素加 data-testid
- API 接口準備測試數據，減少 UI 操作依賴
- 重試時開啓 Trace，方便排查失敗
- 區分 smoke 和 full 測試，合理調度流水線
- Worker 數量從 12 降到 6（降低數據庫壓力）
結果：
- PR 上 12 分鐘跑完
- 不穩定率 <0.3%
- 發版再也不用提心吊膽 這一案例展示了合理設計測試策略、優化定位器、使用 API 數據和 Trace 的組合實踐，可以顯著提升 Playwright 測試的穩定性和效率。
實踐流程示意圖
寫在最後
Playwright 不只是一個測試工具，它是一套 方法論：
- 風險級別組織測試
- 穩定選擇器 + 自動等待
- API 預置數據，Mock 不穩定接口
- 精準控制 Trace、併發和報告
一次採納幾個習慣，你會發現 CI 流水線的焦慮逐漸消失，發版變成例行公事。
