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