環境不穩、用例亂跳？Playwright自動化避坑大全

一、測試環境不穩定

即使你的腳本寫得再完美，如果測試環境自身不穩定，也會導致測試失敗。

常見原因：

1. 網絡波動：測試機與被測系統之間的網絡不穩定。

2. 依賴服務宕機/異常：被測系統依賴的微服務、數據庫、消息隊列等出現問題。

3. 服務器負載過高：被測系統或測試環境服務器資源緊張，導致響應緩慢。

4. 環境配置差異：CI/CD 環境與本地開發環境的配置不一致。

Playwright 定位與解決技巧：

1. 容器化測試環境

Docker/Kubernetes：使用容器化技術（Docker Compose, Kubernetes）構建一致且可重復部署的測試環境。Playwright 官方提供了 Docker 鏡像，非常方便在 CI/CD 中部署。

好處：確保每次運行都在相同的、干凈的環境下，排除環境配置差異導致的問題。

# 示例：使用 Playwright 官方 Docker 鏡像運行測試docker run -it --rm -v $(pwd):/app -w /app mcr.microsoft.com/playwright/python:latest /bin/bash -c "pip install -r requirements.txt && pytest"

2. 監控與告警

基礎設施監控：實時監控測試環境的 CPU、內存、網絡、磁盤 IO 等指標。

服務健康檢查：監控所有被測系統及其依賴服務的健康狀態。

告警機制：一旦發現異常，及時通過郵件、短信或企業微信通知相關人員。

3. 依賴服務 Mock/Stub

對于外部或不穩定的依賴服務，考慮使用 Mock 或 Stub 技術模擬其響應，減少外部因素的干擾，提高測試穩定性。Playwright 提供了強大的網絡攔截功能。

# 攔截并 Mock 特定 API 響應page.route("**/api/user/**", lambda route: route.fulfill( status=200, content_type="application/json", body='{"username": "mocked_user", "id": 123}'))# 也可以攔截圖片、字體等資源，加速測試或模擬加載失敗page.route("**/*.{png,jpg,jpeg,svg}", lambda route: route.abort())

二、閃爍測試

“閃爍測試”是指在代碼和環境都沒有變化的情況下，時而通過、時而失敗的測試用例。它們是自動化測試工程師的噩夢，極大地降低了測試結果的信任度。

常見原因：

1. 競態條件：腳本與應用之間或應用內部的異步操作競爭資源，導致執行順序不確定。

2. 不充分的等待：顯式等待的時間或條件設置不合理，未能完全覆蓋異步操作完成的時間。

3. 隨機數或時間依賴：測試邏輯依賴于系統時間、隨機數等非確定性因素。

4. 外部系統不穩定：依賴的第三方服務、外部 API 等不穩定。

5. 瀏覽器/驅動問題：瀏覽器或 WebDriver 自身偶爾出現的非預期行為。

6. 測試用例耦合：用例之間存在隱式依賴，導致一個用例的失敗影響其他用例。

Playwright 定位與解決技巧：

Playwright 及其測試框架（Playwright Test）提供了多項強大功能來對抗 Flaky Tests：

1. Playwright Test 的自動重試機制

Playwright Test Runner 內置了重試機制。在 `playwright.config.ts` (或 `pytest-playwright` 配置) 中設置 `retries` 參數。

● 在 `playwright.config.ts` (JS/TS):

import { defineConfig } from '@playwright/test';exportdefaultdefineConfig({ // ... retries: process.env.CI ? 2 : 0, // 在 CI/CD 環境下重試2次，本地不重試 // ...})

● 在 `pytest` (Python) 中：

可以利用`pytest-rerunfailures` 插件，或在 CI/CD 中配置重試邏輯。

# 命令行運行pytest --reruns 2 --reruns-delay 1 # 失敗后重試2次，每次間隔1秒

重要：重試只是權宜之計，治標不治本。它給你時間去定位和修復根本問題，而不是掩蓋它們。

2. 強大的調試與分析工具

Playwright Trace Viewer（追蹤查看器）：記錄完整的測試執行軌跡，包括每一步的操作、網絡請求、DOM 快照、日志和失敗堆棧。這是診斷閃爍測試的終極武器。

啟用 Trace：在 `playwright.config.ts` (或 `pytest` 運行參數) 中配置 `trace: 'on-first-retry'` 或 `trace: 'on'`。

運行并分析：失敗后，使用 `playwright show-trace trace.zip` 命令打開分析。你可以一步步回放測試，查看每一步的 DOM 狀態和元素是否可見、可交互。

視頻錄制與截屏：失敗時自動錄制視頻和截屏。

配置：在 `new_context()` 或 `launch()` 中配置 `record_video` 和 `screenshot` 選項。

# video_path 是視頻保存的目錄context = browser.new_context(record_video_dir="videos/", record_video_size={'width': 640, 'height': 480})# ...# 在測試失敗時自動截圖 (pytest-playwright 默認會做)# page.screenshot(path="failed_screenshot.png")

這些視覺證據對于理解非預期行為至關重要。

3. 優化等待策略和斷言

回顧“同步等待問題”部分，確保所有的等待都是顯式且精確的。

使用Playwright的`expect`庫進行健壯性斷言，例如`expect(locator).to_be_visible()`而不是`assert locator.is_visible()`。前者會進行自動等待直到條件滿足或超時。

from playwright.sync_api import expect# 斷言元素可見，Playwright 會自動等待直到可見或超時expect(page.locator(".success-message")).to_be_visible()# 斷言元素不可見expect(page.locator(".loading-spinner")).to_be_hidden()# 斷言元素文本內容expect(page.locator("#username-display")).to_have_text("John Doe")

4. 消除非確定性因素

獨立用例：確保每個測試用例都是獨立的，不依賴于其他用例的執行順序或狀態。利用 Pytest 的 fixture 機制做好 `setup` 和 `teardown`。

清理會話：每次測試前，確保瀏覽器會話干凈。`context.new_page()` 默認會提供干凈的頁面，但對于 `browser.new_context()` 要注意。

時間/隨機數：避免測試依賴于當前時間或隨機數。如果必須，則在測試中固定或模擬它們。

三、性能與效率低下

當測試套件變得龐大時，執行時間過長會嚴重影響反饋速度，降低自動化測試的價值。

常見原因：

1. 測試用例冗余：大量重復或低價值的測試用例。

2. 低效的定位器：使用了過于寬泛或復雜的 XPath/CSS Selector，導致查找元素耗時。

3. 不必要的 UI 操作：頻繁的頁面跳轉、不必要的點擊和輸入。

4. 串行執行：未充分利用多核 CPU 或分布式資源。

5. 環境性能瓶頸：測試機或被測系統性能不足。

Playwright 定位與解決技巧：

1. 遵循測試金字塔原則

優先編寫單元測試和接口測試，它們速度快、成本低。

UI 自動化測試只覆蓋關鍵業務路徑和用戶場景。避免對每個微小功能都進行 UI 自動化。

2. 優化 Playwright 配置

無頭模式 (Headless Mode)：在 CI/CD 環境下，默認開啟無頭模式，可以顯著提高執行速度。

browser = playwright.chromium.launch(headless=True) # 默認就是 True

并行執行：Playwright Test Runner 支持多進程并行執行測試用例，充分利用 CPU 核心。

# 運行所有測試，使用 4 個 worker 并行pytest --workers 4

3. 利用 `context` 和 `page` 的生命周期

在 `pytest` 中，`page` fixture 默認是 `function` scope，`browser` fixture 默認是 `module` scope。

對于需要在相同瀏覽器上下文（例如已登錄狀態）下運行的多個測試用例，可以考慮在 `module` 或 `class` 級別創建 `context`，在 `function` 級別創建 `page`。這樣可以避免每次測試都重新登錄或初始化上下文。

4. 最小化 UI 交互

對于只涉及數據校驗的場景，優先通過 Playwright 的 `request` context 進行接口調用來完成數據準備或驗證，避免不必要的 UI 交互。這比 UI 操作快幾個數量級。

5. 精簡定位器

避免使用過于寬泛或復雜的 XPath，尤其是以 `//` 開頭、遍歷整個 DOM 樹的 XPath。優先使用 ID、`data-test-id` 等直接且唯一的屬性。

四、系統性排查自動化測試問題的通用方法論

除了針對特定問題的解決方案，掌握一套通用的問題排查方法論至關重要。

1. 觀察與收集證據

自動化錄屏/截屏：配置 Playwright 失敗時自動錄制視頻和截屏。

Playwright Trace Viewer：運行失敗后，第一時間打開 Trace Viewer 回放測試，觀察每一步的 DOM 狀態、網絡請求和日志。

詳細日志：在腳本中加入詳細的日志輸出（如操作步驟、變量值、錯誤信息），失敗時能快速定位。

瀏覽器 Console & Network：在Trace Viewer中查看瀏覽器控制臺是否有 JavaScript 錯誤，網絡請求是否正常（HTTP狀態碼、響應時間）。

2. 隔離與復現

運行單個用例：嘗試單獨運行失敗的測試用例，排除其他用例的干擾。

簡化用例：注釋掉與失敗無關的代碼，逐步簡化用例，找出最小復現路徑。

本地復現：優先在本地環境（`--headed --debug` 模式）復現問題，方便交互式調試。

3. 驗證與調試

手動復現：根據失敗時的信息，手動在瀏覽器中操作，看是否能穩定復現。

逐步調試：在IDE中設置斷點，逐步執行代碼，觀察變量值和元素狀態。利用 Playwright Inspector 的 Step-by-step 模式。

斷言增加：在關鍵步驟增加斷言，驗證中間狀態是否符合預期。

4. 定位根因

● 是應用自身的 Bug？測試數據問題？環境問題？還是自動化腳本（定位器、等待、邏輯）的問題？

● 與開發團隊溝通，了解最近的代碼變更，是否有影響到被測功能。

5. 修復與驗證

修復代碼：針對定位到的問題，修改自動化腳本或聯系開發修復應用 Bug。

驗證修復：運行失敗的用例，確保問題已解決，并考慮增加新的斷言或用例來防止類似問題再次發生。

6. 文檔化與分享

● 將排查過程、根因分析和解決方案記錄下來，形成知識庫。

●在團隊內部進行分享，提升團隊整體的排查能力和避免踩坑。

總結

每一次失敗都是一次學習的機會，每一次排查都是一次自我提升。希望這篇指南能幫助大家在 Web 自動化測試的道路上披荊斬棘，所向披靡！

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

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

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

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