別怪Selenium慢！優化環境讓自動化測試快4倍的5個方法

測試編寫者和測試架構師之間的區別是什么？有一個很經典的回答是這樣的：初級工程師調試代碼，高級工程師調試系統。

有位作者正是沿著這個思路，不再追問“我怎樣才能讓這個測試跑得更快？”，而是轉向一個更深層的問題：“到底是什么拖慢了運行它的系統？”。基于這一視角，他對常用的 Selenium 進行了提速實踐，結果出乎意料——在沒有改動任何測試邏輯的情況下，整體速度提升了4倍！

今天我們就來拆解他的實踐過程。

第一步：分析 Selenium 的底層環境

Selenium 的速度受其底層環境制約，主要包括

• 運行測試的機器性能；
• Grid 與瀏覽器之間的網絡延遲；
• 選擇器、等待及數據讀取涉及的 I/O 開銷；
• 線程同步機制。

這些正是我們可以著手優化的關鍵因素。

第二步：逐步調整變量

接下來，就是針對上述因素，一步一步地進行調優實驗了。

1. 遷移到無頭容器(從本地瀏覽器)

以前在本地啟動瀏覽器，各大瀏覽器如Chrome、Firefox、Edge，它們爭搶CPU就像幼兒搶糖果。后來作者使用Selenium Grid+ Docker將它們容器化,配合headless Chrome。突然間,資源爭用消失了。每個測試套件在自己的容器中運行 → 并行擴展變得輕而易舉。

速度提升: 1.7倍

額外收益:不再有"WebDriver無法連接"的隨機失敗。

如下圖：

一行命令啟動。完整的大規模測試執行。

無需手動設置，無需等待，無任何負擔。

2. 通過本地Grid切換到Remote WebDriver

在本地運行瀏覽器實例時,會遇到文件系統I/O限制,特別是如果測試寫日志或截圖。

通過啟動遠程Selenium Grid(即使在同一網絡),繁重的瀏覽器工作在別處進行。

測試代碼仍然在開發機器上運行——瀏覽器不在。

網絡開銷最小。性能提升巨大。

速度提升: 1.3倍

3. 一次性緩存所有靜態資源

Selenium測試反復訪問登錄頁面、Dashboard和相同的靜態資源。

每次運行都會一次又一次地獲取相同的JS和CSS包。

解決方案:使用Service Workers或簡單的代理緩存(如Nginx)來提供緩存內容。

無需瀏覽器hack，無需編輯測試。

速度提升: 0.5倍 (特別是UI密集型應用)

Nginx配置片段:

4. 在Suite級別并行化,而非Test級別

將每個test并行化聽起來不錯——直到Chrome標簽頁開始互相吞噬。

作者將測試分組為執行時長相似的suite(如Login、Search、Reports),并讓這些suite在并行線程中運行。

4個線程 = 4個獨立的瀏覽器會話 = 沒有CPU崩潰。

TestNG示例:

速度提升: 1.5倍

額外收益:多次運行間性能一致。

5. 優化Wait策略(不改動測試)

這個很巧妙。

作者沒有改變一行WebDriverWait代碼,但改變了基礎driver中wait的實現方式。

他用事件驅動wait替換了輪詢wait,使用Selenium內部的ExpectedConditions包裝自定義日志。

不再是"每500ms檢查一次",現在它等待真實的DOM信號(如DOMContentLoaded、AJAX完成)。

速度提升: 0.6倍

額外收益: 漏報減少40%。

總結：

Selenium不是慢，環境才是慢的主要原因。

大多數開發者過度優化他們的測試代碼,卻忽略了生態系統，如：

• 磁盤I/O
• 日志開銷
• 瀏覽器啟動時間
• 網絡延遲
• CPU限流

整體過程如下圖：

??轉崗軟件I測試/野路子技能提升

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

??可以到我的個人號：atstudy-js

即可加入領取 ??????

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

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