1. 從一次深夜發(fā)版說起Selenium慢的根子到底在哪先說個(gè)真實(shí)場(chǎng)景。上個(gè)月我維護(hù)的一個(gè)核心商城項(xiàng)目要做大版本回歸UI自動(dòng)化用例兩百多條跑完一輪要將近三個(gè)小時(shí)。那天晚上十點(diǎn)開始跑本打算十二點(diǎn)收工結(jié)果凌晨?jī)牲c(diǎn)半才跑完中途還掛了六條用例——全是超時(shí)不是功能bug。第二天開發(fā)改了個(gè)字段我下午想快速驗(yàn)證一下核心鏈路結(jié)果光等頁面加載就等了快四十秒。如果你也干過UI自動(dòng)化這種感受應(yīng)該不陌生Selenium的執(zhí)行速度很多時(shí)候不是被測(cè)系統(tǒng)慢而是我們的用法不對(duì)。很多新手會(huì)把網(wǎng)頁加載太慢直接歸咎于網(wǎng)絡(luò)或者服務(wù)器響應(yīng)慢但實(shí)際上用Selenium做自動(dòng)化測(cè)試時(shí)頁面加載慢的原因往往是多層的。這個(gè)問題的核心關(guān)鍵詞是Selenium、自動(dòng)化測(cè)試、網(wǎng)頁加載今天這篇文章不打算泛泛講理論而是從根因拆解、診斷方法、到具體的優(yōu)化手段把我實(shí)際在項(xiàng)目里驗(yàn)證過的方案完整梳理一遍。先說結(jié)論Selenium慢通常不是某一個(gè)原因造成的而是瀏覽器加載策略、等待機(jī)制、資源請(qǐng)求、測(cè)試代碼寫法這四個(gè)維度疊加的結(jié)果。你只用對(duì)了一半速度可能就翻倍全都用對(duì)兩百條用例的回歸時(shí)間從三小時(shí)壓到四十分鐘是完全可行的。我的一個(gè)判斷原則是先診斷后優(yōu)化不要一上來就改代碼。很多人在網(wǎng)上看到設(shè)置page_load_strategy為none就抄過來結(jié)果頁面還沒渲染完就開始找元素報(bào)錯(cuò)更多了。所以這篇文章的第一部分先把Selenium為什么慢的機(jī)理講清楚然后再說怎么科學(xué)地把速度提上來。2. 打開網(wǎng)頁到底卡在哪加載過程全鏈路拆解2.1 阻塞時(shí)間線從發(fā)出請(qǐng)求到元素可交互中間發(fā)生了什么我用一個(gè)簡(jiǎn)單例子來還原Selenium打開頁面的完整過程。假設(shè)你用webdriver.get()去訪問一個(gè)電商首頁表面上看只是打開網(wǎng)頁但底層要經(jīng)歷這些步驟驅(qū)動(dòng)進(jìn)程啟動(dòng)瀏覽器實(shí)例ChromeDriver啟動(dòng)Chrome這一步本身就要占用幾百毫秒到一兩秒。瀏覽器發(fā)起HTTP請(qǐng)求經(jīng)歷了DNS解析、TCP握手、TLS協(xié)商、服務(wù)器處理、響應(yīng)返回。瀏覽器開始解析HTML構(gòu)建DOM樹。加載過程中遇到script腳本默認(rèn)會(huì)阻塞解析。CSS、圖片、字體、iframe等子資源繼續(xù)加載。觸發(fā)onload事件——注意Selenium的get()方法默認(rèn)會(huì)等到onload事件觸發(fā)才返回。麻煩就出在第6步。Selenium WebDriver按照W3C規(guī)范默認(rèn)的頁面加載策略是normal意味著driver.get()要一直等到window.onload觸發(fā)完畢才把控制權(quán)交還給你。如果一個(gè)頁面上有第三方統(tǒng)計(jì)腳本、廣告SDK、埋點(diǎn)上報(bào)之類的組件這些資源加載慢或者干脆掛起onload就遲遲不觸發(fā)你的自動(dòng)化腳本就只能干等。我在測(cè)試一個(gè)資訊類網(wǎng)站時(shí)遇到過特別典型的情況正文內(nèi)容兩秒就渲染完了但頁面上嵌了一個(gè)第三方登錄SDK的腳本那個(gè)腳本的服務(wù)器在境外響應(yīng)時(shí)間忽快忽慢離譜的時(shí)候要等十幾秒。用Selenium默認(rèn)配置去跑每次訪問文章詳情頁都要卡十幾秒實(shí)際上頁面主體內(nèi)容早就可用了。這解釋了為什么有時(shí)候你手動(dòng)打開網(wǎng)頁覺得挺快但自動(dòng)化腳本卻慢得離譜——你手動(dòng)感知的加載完和瀏覽器onload事件觸發(fā)的加載完壓根不是一回事。2.2 除了onload之外隱式等待和顯式等待的疊加效應(yīng)另一個(gè)讓Selenium變慢的隱藏因素是等待策略配置不當(dāng)。很多教程會(huì)讓你在初始化driver之后加一句driver.implicitly_wait(10)意思是找不到元素時(shí)最多等10秒。這個(gè)等待不是輪詢到元素就立刻返回嗎是但問題在于隱式等待對(duì)find_element系列方法生效而且不會(huì)和其他等待策略互相抵消。如果你同時(shí)設(shè)置了隱式等待和顯式等待WebDriverWait那情況就會(huì)很微妙。舉個(gè)例子driver webdriver.Chrome() driver.implicitly_wait(10) # 在代碼后面某處 element WebDriverWait(driver, 10).until( EC.element_to_be_clickable((By.ID, submit-btn)) )這種寫法下顯式等待本身會(huì)輪詢條件。每輪詢一次底層都會(huì)執(zhí)行一次find_element而這個(gè)find_element又會(huì)受到隱式等待的影響——也就是說element_to_be_clickable每次輪詢檢查元素是否存在時(shí)都可能額外等待最長10秒。如果元素一直沒出現(xiàn)你的總等待時(shí)間就不是10秒而是遠(yuǎn)遠(yuǎn)超過10秒。網(wǎng)上有很多人反映WebDriverWait等待20秒?yún)s報(bào)了超時(shí)的帖子多半就是隱式等待和顯式等待打架造成的。我處理這個(gè)問題的原則很簡(jiǎn)單代碼里只保留一種等待機(jī)制。項(xiàng)目里統(tǒng)一用顯式等待初始化driver之后不再設(shè)置implicitly_wait。2.3 盲等time.sleep()是拖慢測(cè)試的最大元兇還有一個(gè)常見寫法初學(xué)Selenium的人喜歡到處time.sleep(5)等個(gè)固定時(shí)間再繼續(xù)操作。這在小規(guī)模演示腳本里問題不大但在大型測(cè)試套件里就是災(zāi)難。固定sleep有兩大問題。一是如果網(wǎng)絡(luò)快、頁面加載快sleep的固定時(shí)間就純屬浪費(fèi)二是如果網(wǎng)絡(luò)慢、頁面加載超過了sleep時(shí)間腳本照樣會(huì)失敗。兩全其美靠的應(yīng)該是基于條件的等待而不是基于時(shí)間的猜測(cè)。我見過一個(gè)外包團(tuán)隊(duì)寫的腳本每個(gè)頁面上都有五六個(gè)time.sleep(3)一個(gè)用例跑下來光sleep就要二十多秒整個(gè)套件兩百條用例光浪費(fèi)在blind sleep上的時(shí)間就有七千多秒——兩個(gè)多小時(shí)。把sleep全部改成顯式等待之后執(zhí)行時(shí)間直接砍半。3. 定位瓶頸三板斧先給Selenium提速前先做這四件事3.1 用性能分析工具記錄每一段操作的耗時(shí)動(dòng)手優(yōu)化前你得知道時(shí)間到底花在哪了。我習(xí)慣在測(cè)試腳本里加輕量級(jí)的計(jì)時(shí)邏輯具體做法是給每個(gè)關(guān)鍵步驟打點(diǎn)import time from selenium import webdriver from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from selenium.webdriver.common.by import By def log_time(step_name, start): print(f{step_name}: {time.time() - start:.2f}s) driver webdriver.Chrome() start time.time() driver.get(http://your-test-site.com) log_time(driver.get 返回, start) start time.time() WebDriverWait(driver, 10).until(EC.presence_of_element_located((By.ID, content))) log_time(首屏關(guān)鍵元素出現(xiàn), start) start time.time() WebDriverWait(driver, 3).until( EC.text_to_be_present_in_element((By.TAG_NAME, body), 訂單號(hào)) ) log_time(業(yè)務(wù)數(shù)據(jù)渲染完成, start)跑一次用例輸出的時(shí)間點(diǎn)清清楚楚到底是get()耗時(shí)高還是等待元素出現(xiàn)耗時(shí)高又或者是點(diǎn)擊之后到下一個(gè)頁面可交互耗時(shí)高。有了這條時(shí)間線優(yōu)化才有依據(jù)。3.2 區(qū)分服務(wù)端慢前端渲染慢和自動(dòng)化機(jī)制慢這是最容易被忽略的一道分界線。同一個(gè)頁面在瀏覽器手動(dòng)打開很快但自動(dòng)化腳本慢問題大概率出在自動(dòng)化機(jī)制上反過來你要在Selenium里通過navigation timing接口拿到真實(shí)數(shù)據(jù)來區(qū)分。Chrome DevTools ProtocolCDP允許Selenium直接獲取performance日志。借助這個(gè)能力可以精確拿到頁面各階段的耗時(shí)from selenium.webdriver.common.devtools.v85 import performance # 啟用性能日志 driver.execute_cdp_cmd(Performance.enable, {}) # 獲取導(dǎo)航時(shí)間線數(shù)據(jù) metrics driver.execute_cdp_cmd(Performance.getMetrics, {}) for metric in metrics[metrics]: if metric[name] in [Network.navigationStart, Page.domContentLoaded, Page.loadEventFired]: print(metric[name], metric[value])通過navigation timing的數(shù)據(jù)你可以看到DOMContentLoadedDOM解析完成和loadEventFiredonload觸發(fā)之間的時(shí)間差。如果loadEventFired比domContentLoaded晚了三五秒那多出來的時(shí)間多半就是你等第三方資源白白浪費(fèi)的也就是說服務(wù)端很快前端渲染也很快純粹是頁面設(shè)計(jì)上的資源加載拖了后腿。這種時(shí)候調(diào)整Selenium的頁面加載策略就是最直接的優(yōu)化手段。3.3 抓包看資源請(qǐng)求是不是在等無關(guān)緊要的靜態(tài)資源如果頁面加載偏慢且?guī)в须S機(jī)性我建議你用BrowserMob Proxy這類代理工具做一次抓包分析或者直接打開DevTools的Network面板手動(dòng)看一眼。重點(diǎn)觀察這幾個(gè)指標(biāo)有沒有長時(shí)間pending的請(qǐng)求。有沒有第三方域名的腳本或圖片。靜態(tài)資源有沒有走CDN還是直接打到源站。有沒有大體積圖片、未壓縮的JS/CSS文件。這步診斷的意義在于如果慢的根源是測(cè)試環(huán)境本身的網(wǎng)絡(luò)差那優(yōu)化Selenium配置是治標(biāo)不治本如果慢的根源是頁面掛了外部依賴那可以從測(cè)試環(huán)境層面做處理比如屏蔽或者mock掉這些無關(guān)請(qǐng)求。4. 核心優(yōu)化一攔截?zé)o關(guān)資源加載給瀏覽器減負(fù)4.1 禁用圖片、CSS、字體和媒體資源加載頁面加載慢很多時(shí)候不是HTML本身慢而是因?yàn)闉g覽器要把圖片、CSS、視頻、廣告腳本全都下載一遍。做自動(dòng)化測(cè)試尤其是功能邏輯回歸很多視覺資源根本不需要加載。用ChromeOptions禁用這些資源的加載速度提升非常明顯。下面這段是我在項(xiàng)目里常用的配置from selenium import webdriver from selenium.webdriver.chrome.options import Options options Options() prefs { profile.managed_default_content_settings.images: 2, # 不加載圖片 profile.default_content_setting_values.notifications: 2, profile.managed_default_content_settings.stylesheets: 2, # 不加載CSS謹(jǐn)慎使用 } options.add_experimental_option(prefs, prefs) driver webdriver.Chrome(optionsoptions)需要特別提醒的是禁用CSS需要謹(jǐn)慎。很多前端框架的點(diǎn)擊事件依賴CSS控制的可點(diǎn)擊區(qū)域而且有些元素在CSS未加載時(shí)寬高為0Selenium的點(diǎn)擊會(huì)報(bào)element not interactable。所以更穩(wěn)妥的做法是只禁用圖片和媒體資源CSS保持加載。我實(shí)測(cè)過一個(gè)后臺(tái)管理系統(tǒng)禁用圖片后登錄頁加載時(shí)間從7秒降低到3秒左右列表頁從5秒降到2秒。而且測(cè)試用例本身不依賴頁面上的圖片是否顯示完全沒有影響。4.2 攔截第三方域名請(qǐng)求屏蔽廣告SDK和統(tǒng)計(jì)腳本如果頁面上集成了一堆第三方服務(wù)比如數(shù)據(jù)統(tǒng)計(jì)、廣告、在線客服、異常上報(bào)它們雖然不影響業(yè)務(wù)功能但會(huì)拖慢onload的觸發(fā)時(shí)間。一個(gè)很有效的做法是用Chrome DevTools Protocol的Network.setBlockedURLs方法把這些域名直接攔掉。driver.execute_cdp_cmd(Network.enable, {}) driver.execute_cdp_cmd(Network.setBlockedURLs, { urls: [ *.google-analytics.com/*, *.googletagmanager.com/*, *.#/*, *.#/*, *ads*.com/* ] })需要注意順序這段代碼必須在driver.get()之前執(zhí)行否則頁面已經(jīng)開始加載了再去攔截就起不到省時(shí)的作用了。我之前負(fù)責(zé)過一個(gè)嵌了五六個(gè)第三方SDK的活動(dòng)頁不攔截第三方時(shí)get()要等12秒攔截之后3秒內(nèi)就返回了。差異就是這么夸張。4.3 條件允許時(shí)直接上無頭模式如果你的用例不需要真的看到瀏覽器界面比如純回歸、純接口鏈路驗(yàn)證無頭模式是性價(jià)比最高的提速手段。去掉了渲染和GPU合成的大量開銷同一條用例的執(zhí)行時(shí)間通常能減少30%到50%。options.add_argument(--headlessnew) options.add_argument(--disable-gpu) options.add_argument(--disable-extensions) options.add_argument(--no-sandbox) options.add_argument(--disable-dev-shm-usage)不過要說句公道話無頭模式并不等于永遠(yuǎn)更快。在某些復(fù)雜交互場(chǎng)景下比如文件上傳中有flash組件、拖拽依賴物理像素級(jí)坐標(biāo)、或者某些canvas渲染動(dòng)畫無頭模式反而可能出問題。所以我的建議是分層執(zhí)行——本地調(diào)試和排查問題時(shí)用有頭模式CI流水線和夜間回歸用無頭模式。5. 核心優(yōu)化二頁面加載策略的正確配置5.1 normal、eager、none三種策略到底怎么選Selenium的page_load_strategy有三種取值這是解決網(wǎng)頁加載慢最直接的參數(shù)但很多人沒用對(duì)。三種策略的區(qū)別如下策略特點(diǎn)driver.get()何時(shí)返回適用場(chǎng)景normal默認(rèn)策略等待onload事件所有資源加載完成后返回對(duì)頁面完整性要求高的場(chǎng)景eager等待DOMContentLoaded事件DOM解析完成后即返回大多數(shù)頁面交互測(cè)試none不等待頁面加載事件導(dǎo)航開始后立即返回需要完全自己控制等待邏輯的高級(jí)操作切換到eager是最穩(wěn)妥的提速手段。它不需要等到圖片、iframe、廣告腳本全部加載完才返回控制權(quán)而只需要DOM解析完成。對(duì)大部分業(yè)務(wù)系統(tǒng)來說DOM解析完成時(shí)關(guān)鍵元素基本都已經(jīng)可用了后面配合顯式等待即可。配置方法很簡(jiǎn)單options.page_load_strategy eager driver webdriver.Chrome(optionsoptions)我建議在絕大多數(shù)項(xiàng)目里直接用eager而不是一上來就上none。原因后面會(huì)講。5.2 關(guān)于頁面加載策略設(shè)為none的進(jìn)階用法與雷區(qū)none策略確實(shí)是最激進(jìn)的提速方案設(shè)置為none后driver.get()在發(fā)起導(dǎo)航請(qǐng)求后就立刻返回不等任何加載事件。聽起來很香但坑也很深。我見過很多人把page_load_strategy設(shè)成none之后緊接著就寫driver.find_element(...)去定位元素結(jié)果瀏覽器地址欄都還沒跳轉(zhuǎn)直接報(bào)NoSuchElementException。原因很簡(jiǎn)單——none模式下瀏覽器可能在后臺(tái)還沒開始發(fā)起真正的導(dǎo)航請(qǐng)求頁面還停留在old page狀態(tài)。所以如果要使用none策略必須配合完善的自定義等待邏輯。比如下面這種寫法from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from selenium.webdriver.common.by import By options.page_load_strategy none driver webdriver.Chrome(optionsoptions) driver.get(http://your-test-site.com) # 主動(dòng)等待導(dǎo)航發(fā)生并且頁面出現(xiàn)標(biāo)志性元素 WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.TAG_NAME, html)) ) WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.ID, app)) )這樣寫雖然靈活但每到一個(gè)新頁面你都要寫一堆顯式等待代碼維護(hù)成本會(huì)上升。我的取舍是除非某個(gè)頁面的onload尤其慢且不可控否則優(yōu)先用eager而不是none。eager已經(jīng)能解決90%的等太久問題而且代碼改動(dòng)量最小。6. 核心優(yōu)化三等待策略重構(gòu)把固定sleep全部替換掉6.1 用顯式等待替代time.sleep()的完整思路這次優(yōu)化的邏輯很簡(jiǎn)單等待的目的不是等一段時(shí)間而是等到某個(gè)條件滿足。顯式等待WebDriverWait干的正是這件事。通用做法是寫一個(gè)專門等待元素可用的工具函數(shù)。我項(xiàng)目里有個(gè)wait_utils.py大概長這樣from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from selenium.webdriver.common.by import By def wait_until_clickable(driver, by, locator, timeout10, poll_frequency0.5): 等待元素可見且可點(diǎn)擊返回元素對(duì)象 return WebDriverWait(driver, timeout, poll_frequency).until( EC.element_to_be_clickable((by, locator)), f元素 {locator} 在 {timeout}s 內(nèi)未可點(diǎn)擊 ) def wait_for_text(driver, text, timeout10): 等待頁面上出現(xiàn)指定文本 return WebDriverWait(driver, timeout).until( EC.text_to_be_present_in_element((By.TAG_NAME, body), text), f文本 {text} 在 {timeout}s 內(nèi)未出現(xiàn) )然后在業(yè)務(wù)代碼里把time.sleep(5)替換成wait_until_clickable(driver, By.ID, submit-btn).click() wait_for_text(driver, 訂單提交成功)這套寫法的好處是頁面快的時(shí)候條件立刻滿足一秒都不多等頁面慢的時(shí)候最長等待時(shí)間可控不會(huì)因?yàn)榫W(wǎng)絡(luò)抖動(dòng)直接失敗。6.2 處理Selenium中AJAX數(shù)據(jù)加載的等待技巧現(xiàn)代前端應(yīng)用大量使用AJAX異步加載數(shù)據(jù)比如列表頁先渲染出空殼再通過接口調(diào)取數(shù)據(jù)填充表格。這種場(chǎng)景下等待元素存在還不夠必須等待數(shù)據(jù)渲染完成。我的做法是瞄著一個(gè)數(shù)據(jù)渲染完成的標(biāo)志性表現(xiàn)下條件常用幾種表格中出現(xiàn)了預(yù)期行數(shù)的數(shù)據(jù)記錄。頁面上的loading spinner消失。某個(gè)特定文本如共X條記錄出現(xiàn)。某個(gè)元素的class屬性變化比如從loading變?yōu)閘oaded。以表格數(shù)據(jù)為例from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC # 等待loading遮罩消失 WebDriverWait(driver, 15).until( EC.invisibility_of_element_located((By.CLASS_NAME, loading-mask)) ) # 等待表格數(shù)據(jù)行的數(shù)量達(dá)到預(yù)期 WebDriverWait(driver, 15).until( lambda d: len(d.find_elements(By.CSS_SELECTOR, table tbody tr)) 10 )lambda寫法是我特別推薦的一個(gè)技巧。WebDriverWait的until方法接受一個(gè)可調(diào)用對(duì)象這個(gè)對(duì)象接收driver參數(shù)并返回一個(gè)布爾值或元素列表。你可以用它來寫任意復(fù)雜的等待條件而不只是依賴Selenium預(yù)置的expected_conditions。6.3 輪詢頻率設(shè)置別讓默認(rèn)0.5秒的輪詢拖累你的速度一個(gè)很容易被忽略的細(xì)節(jié)是WebDriverWait的poll_frequency參數(shù)。默認(rèn)值是0.5秒也就是說如果預(yù)期條件在第0.1秒就滿足了你也得等到第0.5秒的輪詢點(diǎn)才能拿到結(jié)果。在頁面數(shù)量多的測(cè)試套件里每次等待白白空轉(zhuǎn)0.4秒幾百次累積起來也很可觀。對(duì)于響應(yīng)極快的本地系統(tǒng)我習(xí)慣把輪詢頻率調(diào)小WebDriverWait(driver, 10, poll_frequency0.1).until(...)反之如果頁面加載本身就很慢輪詢太頻繁反而給瀏覽器增加壓力一般0.5秒已經(jīng)夠用。我的建議是本地調(diào)試和測(cè)試環(huán)境用0.1秒生產(chǎn)環(huán)境壓測(cè)或遠(yuǎn)程環(huán)境用0.2到0.5秒。6.4 設(shè)置合理的全局腳本超時(shí)和頁面加載超時(shí)還有兩個(gè)超時(shí)設(shè)置容易被忽略driver.set_page_load_timeout()和driver.set_script_timeout()。driver.set_page_load_timeout(30) # 頁面加載超時(shí) driver.set_script_timeout(30) # 異步腳本執(zhí)行超時(shí)合理設(shè)置超時(shí)的價(jià)值在于當(dāng)一個(gè)頁面真的卡死或者第三方資源長時(shí)間無響應(yīng)時(shí)測(cè)試不會(huì)無限期等下去而是快速失敗把問題暴露出來。這表面上看是讓測(cè)試更快失敗實(shí)際上是節(jié)省了整個(gè)回歸套件的時(shí)間。7. 核心優(yōu)化四瀏覽器實(shí)例復(fù)用和測(cè)試代碼寫法優(yōu)化7.1 避免每個(gè)用例都重新啟動(dòng)瀏覽器很多測(cè)試框架的初始模板都是一個(gè)用例就啟動(dòng)一次driver用例結(jié)束就driver.quit()。這種做法干凈但代價(jià)極大。啟動(dòng)一個(gè)干凈的Chrome實(shí)例冷啟動(dòng)耗時(shí)要2到5秒如果套件里有兩百個(gè)用例光啟動(dòng)瀏覽器就要十分鐘。我常用的兩種優(yōu)化思路在pytest里用session級(jí)別的fixture讓整個(gè)測(cè)試會(huì)話共享同一個(gè)driver實(shí)例。在用例之間做頁面狀態(tài)清理而不是重復(fù)啟動(dòng)瀏覽器。以pytest為例最簡(jiǎn)單的方式就是用session scope的fixtureimport pytest from selenium import webdriver pytest.fixture(scopesession) def driver(): options webdriver.ChromeOptions() options.page_load_strategy eager driver webdriver.Chrome(optionsoptions) yield driver driver.quit()但要注意共享瀏覽器實(shí)例后會(huì)引入用例間的狀態(tài)耦合問題比如登錄態(tài)、localStorage緩存互相影響。所以在用例設(shè)計(jì)階段就要規(guī)劃好哪些用例可以共享會(huì)話哪些必須用獨(dú)立的瀏覽器上下文。7.2 控制用例粒度減少不必要的頁面導(dǎo)航和重復(fù)操作我遇到過一種極端的用例寫法每條用例都從登錄開始然后走一遍完整業(yè)務(wù)流程最后再退出登錄。兩百條用例全部重復(fù)登錄登出這個(gè)時(shí)間是巨大的浪費(fèi)。優(yōu)化的思路是進(jìn)行用例分層登錄驗(yàn)證本身保留一兩個(gè)完整登錄流程的用例。業(yè)務(wù)功能用例基于已登錄狀態(tài)執(zhí)行避免頻繁跳轉(zhuǎn)回登錄頁。通過設(shè)置cookie、調(diào)接口預(yù)置數(shù)據(jù)等方式跳過無關(guān)的頁面操作。比如在UI自動(dòng)化中可以通過CDP直接添加cookie來維持登錄態(tài)driver.execute_cdp_cmd(Network.enable, {}) # 導(dǎo)出一條已登錄會(huì)話的cookie cookies [ {name: sessionid, value: xxx, domain: your-test-site.com, path: /}, ] for cookie in cookies: driver.execute_cdp_cmd(Network.setCookie, cookie) driver.get(http://your-test-site.com/dashboard)這種做法對(duì)于前后端分離的系統(tǒng)尤其有效省掉了每次打開登錄頁、輸入賬號(hào)、等待跳轉(zhuǎn)的時(shí)間。7.3 JavaScript滾動(dòng)、點(diǎn)擊與屬性獲取的加速替代方案Selenium定位元素之后執(zhí)行click()理論上都是通過驅(qū)動(dòng)轉(zhuǎn)發(fā)命令。有些場(chǎng)景下用execute_script直接操縱頁面反而更快# 替代element.click() driver.execute_script(arguments[0].click();, element) # 替代滾動(dòng)到頁面底部再等待加載 driver.execute_script(window.scrollTo(0, document.body.scrollHeight);) # 獲取元素文本避免額外的WebDriver命令往返 text driver.execute_script(return arguments[0].innerText;, element)尤其在處理canvas繪制的圖表、自定義組件這類Selenium原生click可能被遮擋的場(chǎng)景里用JavaScript直接觸發(fā)點(diǎn)擊不僅快而且更穩(wěn)。Canvas里的元素用DOM定位根本定位不到這種場(chǎng)景下JS執(zhí)行幾乎是唯一選擇。需要說明的是這個(gè)優(yōu)化點(diǎn)帶來的是每條操作節(jié)省幾十毫秒級(jí)別的收益看起來不起眼但一個(gè)用例幾十個(gè)操作累積下來差別還是可以感知的。8. 慢之外更要穩(wěn)提速后容易踩的太快導(dǎo)致失敗的坑8.1 元素還沒掛到DOM上就開始操作提速之后最諷刺的事情是以前是等太久現(xiàn)在是操作得太快反而把用例搞掛了。典型場(chǎng)景是設(shè)置page_load_strategyeager之后driver.get()返回了但頁面JavaScript還沒執(zhí)行完按鈕還沒綁定事件此時(shí)去click只會(huì)得到一個(gè)寬高為0或沒綁事件的元素。解決思路很明確所有關(guān)鍵操作前務(wù)必加一道顯式等待可交互的條件而不是存在條件。WebDriverWait(driver, 10).until( EC.element_to_be_clickable((By.ID, submit-btn)) )8.2 登錄態(tài)和緩存導(dǎo)致的用例間數(shù)據(jù)污染共享瀏覽器實(shí)例之后頁面間的localStorage、sessionStorage可能會(huì)互相污染。比如用例A往localStorage里寫了一個(gè)token用例B啟動(dòng)時(shí)讀到了這個(gè)token用例B的執(zhí)行結(jié)果就不再是從干凈狀態(tài)開始的結(jié)果了。對(duì)此我的建議是在關(guān)鍵用例前后做一次狀態(tài)清理try: driver.execute_script(window.localStorage.clear(); window.sessionStorage.clear();) except Exception: pass同時(shí)在測(cè)試數(shù)據(jù)設(shè)計(jì)上盡量讓用例之間不共享可變數(shù)據(jù)比如每個(gè)人使用自己的測(cè)試賬號(hào)和數(shù)據(jù)記錄。9. 實(shí)測(cè)對(duì)比同一套件優(yōu)化前后的時(shí)間變化光說理論和方案不夠直觀。拿我自己維護(hù)的那套商城回歸用例來舉例兩百一十二條用例測(cè)試環(huán)境是公司內(nèi)網(wǎng)的預(yù)發(fā)布環(huán)境。優(yōu)化前狀態(tài)Chrome默認(rèn)配置未設(shè)置page_load_strategy。代碼里到處都是time.sleep(3)或time.sleep(5)。每個(gè)用例獨(dú)立啟動(dòng)driver。未屏蔽任何靜態(tài)資源或第三方請(qǐng)求。跑完全部的執(zhí)行時(shí)間大約是兩個(gè)小時(shí)五十分鐘失敗率在3%左右。優(yōu)化動(dòng)作page_load_strategy設(shè)為eager。移除全部time.sleep替換為顯式等待和lambda條件等待。禁用圖片、視頻等媒體資源加載。攔截第三方統(tǒng)計(jì)和廣告SDK域名。pytest fixture改為session級(jí)別復(fù)用driver實(shí)例。刪除每個(gè)用例的重復(fù)登錄邏輯僅在會(huì)話開始時(shí)做一次登錄。優(yōu)化后同一套件的執(zhí)行時(shí)間大約是四十二分鐘。時(shí)間縮短了近八成。當(dāng)然這個(gè)結(jié)果和用例的具體場(chǎng)景有關(guān)但整體趨勢(shì)是很有代表性的。有一點(diǎn)必須強(qiáng)調(diào)這些優(yōu)化對(duì)測(cè)試穩(wěn)定性的影響是雙面的。正確配置的等待策略會(huì)讓測(cè)試更穩(wěn)因?yàn)闂l件等待本身就比固定等待更健壯但如果為了提速把所有等待都刪掉那失敗率會(huì)直線上升。提速的目的是讓測(cè)試在可控的時(shí)間內(nèi)跑完而不是為了快而犧牲可靠性。10. 終極建議什么情況下該優(yōu)化Selenium什么情況下該換工具聊了這么多提速手段最后必須說一個(gè)更根本的問題。Selenium天然是一個(gè)偏重模擬用戶操作的工具它的架構(gòu)決定了它不可能比接口測(cè)試快。如果你的自動(dòng)化測(cè)試場(chǎng)景里90%的時(shí)間都花在等頁面加載而不是驗(yàn)證業(yè)務(wù)邏輯上那可能你根本用錯(cuò)工具了。我的個(gè)人判斷是如果只是驗(yàn)證后端接口返回的數(shù)據(jù)和狀態(tài)碼直接用Requests/HTTP客戶端、或者接口自動(dòng)化測(cè)試框架速度是Selenium的幾十倍。如果要做的是核心業(yè)務(wù)鏈路冒煙測(cè)試比如下單、支付、審批流這些必須驗(yàn)證真實(shí)瀏覽器交互的才適合繼續(xù)用Selenium。如果要做大規(guī)模數(shù)據(jù)抓取Selenium也是下策換成直接構(gòu)造HTTP請(qǐng)求的方式配合簡(jiǎn)單的登錄態(tài)維持效率會(huì)高得多。所謂AI自動(dòng)化測(cè)試平臺(tái)搭建也不是直接拿Selenium裸跑。我曾經(jīng)參與過一個(gè)小型測(cè)試平臺(tái)的設(shè)計(jì)底層用Selenium Grid做分布式執(zhí)行可以同時(shí)把用例分到多臺(tái)機(jī)器上跑從架構(gòu)層面橫向擴(kuò)展執(zhí)行能力。這也是Selenium提速的一個(gè)深層方向——單機(jī)優(yōu)化終究有天花板分布式并行才是大規(guī)?；貧w的最終解法。所以最后我的建議是先把本篇文章里的單機(jī)優(yōu)化方案落地如果還不夠快再往分布式和分層自動(dòng)化方向走。工具永遠(yuǎn)是為目標(biāo)服務(wù)的別被UI自動(dòng)化這四個(gè)字框住思路。