1. 从一次深夜发版说起Selenium慢的根子到底在哪先说个真实场景。上个月我维护的一个核心商城项目要做大版本回归UI自动化用例两百多条跑完一轮要将近三个小时。那天晚上十点开始跑本打算十二点收工结果凌晨两点半才跑完中途还挂了六条用例——全是超时不是功能bug。第二天开发改了个字段我下午想快速验证一下核心链路结果光等页面加载就等了快四十秒。如果你也干过UI自动化这种感受应该不陌生Selenium的执行速度很多时候不是被测系统慢而是我们的用法不对。很多新手会把网页加载太慢直接归咎于网络或者服务器响应慢但实际上用Selenium做自动化测试时页面加载慢的原因往往是多层的。这个问题的核心关键词是Selenium、自动化测试、网页加载今天这篇文章不打算泛泛讲理论而是从根因拆解、诊断方法、到具体的优化手段把我实际在项目里验证过的方案完整梳理一遍。先说结论Selenium慢通常不是某一个原因造成的而是浏览器加载策略、等待机制、资源请求、测试代码写法这四个维度叠加的结果。你只用对了一半速度可能就翻倍全都用对两百条用例的回归时间从三小时压到四十分钟是完全可行的。我的一个判断原则是先诊断后优化不要一上来就改代码。很多人在网上看到设置page_load_strategy为none就抄过来结果页面还没渲染完就开始找元素报错更多了。所以这篇文章的第一部分先把Selenium为什么慢的机理讲清楚然后再说怎么科学地把速度提上来。2. 打开网页到底卡在哪加载过程全链路拆解2.1 阻塞时间线从发出请求到元素可交互中间发生了什么我用一个简单例子来还原Selenium打开页面的完整过程。假设你用webdriver.get()去访问一个电商首页表面上看只是打开网页但底层要经历这些步骤驱动进程启动浏览器实例ChromeDriver启动Chrome这一步本身就要占用几百毫秒到一两秒。浏览器发起HTTP请求经历了DNS解析、TCP握手、TLS协商、服务器处理、响应返回。浏览器开始解析HTML构建DOM树。加载过程中遇到script脚本默认会阻塞解析。CSS、图片、字体、iframe等子资源继续加载。触发onload事件——注意Selenium的get()方法默认会等到onload事件触发才返回。麻烦就出在第6步。Selenium WebDriver按照W3C规范默认的页面加载策略是normal意味着driver.get()要一直等到window.onload触发完毕才把控制权交还给你。如果一个页面上有第三方统计脚本、广告SDK、埋点上报之类的组件这些资源加载慢或者干脆挂起onload就迟迟不触发你的自动化脚本就只能干等。我在测试一个资讯类网站时遇到过特别典型的情况正文内容两秒就渲染完了但页面上嵌了一个第三方登录SDK的脚本那个脚本的服务器在境外响应时间忽快忽慢离谱的时候要等十几秒。用Selenium默认配置去跑每次访问文章详情页都要卡十几秒实际上页面主体内容早就可用了。这解释了为什么有时候你手动打开网页觉得挺快但自动化脚本却慢得离谱——你手动感知的加载完和浏览器onload事件触发的加载完压根不是一回事。2.2 除了onload之外隐式等待和显式等待的叠加效应另一个让Selenium变慢的隐藏因素是等待策略配置不当。很多教程会让你在初始化driver之后加一句driver.implicitly_wait(10)意思是找不到元素时最多等10秒。这个等待不是轮询到元素就立刻返回吗是但问题在于隐式等待对find_element系列方法生效而且不会和其他等待策略互相抵消。如果你同时设置了隐式等待和显式等待WebDriverWait那情况就会很微妙。举个例子driver webdriver.Chrome() driver.implicitly_wait(10) # 在代码后面某处 element WebDriverWait(driver, 10).until( EC.element_to_be_clickable((By.ID, submit-btn)) )这种写法下显式等待本身会轮询条件。每轮询一次底层都会执行一次find_element而这个find_element又会受到隐式等待的影响——也就是说element_to_be_clickable每次轮询检查元素是否存在时都可能额外等待最长10秒。如果元素一直没出现你的总等待时间就不是10秒而是远远超过10秒。网上有很多人反映WebDriverWait等待20秒却报了超时的帖子多半就是隐式等待和显式等待打架造成的。我处理这个问题的原则很简单代码里只保留一种等待机制。项目里统一用显式等待初始化driver之后不再设置implicitly_wait。2.3 盲等time.sleep()是拖慢测试的最大元凶还有一个常见写法初学Selenium的人喜欢到处time.sleep(5)等个固定时间再继续操作。这在小规模演示脚本里问题不大但在大型测试套件里就是灾难。固定sleep有两大问题。一是如果网络快、页面加载快sleep的固定时间就纯属浪费二是如果网络慢、页面加载超过了sleep时间脚本照样会失败。两全其美靠的应该是基于条件的等待而不是基于时间的猜测。我见过一个外包团队写的脚本每个页面上都有五六个time.sleep(3)一个用例跑下来光sleep就要二十多秒整个套件两百条用例光浪费在blind sleep上的时间就有七千多秒——两个多小时。把sleep全部改成显式等待之后执行时间直接砍半。3. 定位瓶颈三板斧先给Selenium提速前先做这四件事3.1 用性能分析工具记录每一段操作的耗时动手优化前你得知道时间到底花在哪了。我习惯在测试脚本里加轻量级的计时逻辑具体做法是给每个关键步骤打点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(首屏关键元素出现, start) start time.time() WebDriverWait(driver, 3).until( EC.text_to_be_present_in_element((By.TAG_NAME, body), 订单号) ) log_time(业务数据渲染完成, start)跑一次用例输出的时间点清清楚楚到底是get()耗时高还是等待元素出现耗时高又或者是点击之后到下一个页面可交互耗时高。有了这条时间线优化才有依据。3.2 区分服务端慢前端渲染慢和自动化机制慢这是最容易被忽略的一道分界线。同一个页面在浏览器手动打开很快但自动化脚本慢问题大概率出在自动化机制上反过来你要在Selenium里通过navigation timing接口拿到真实数据来区分。Chrome DevTools ProtocolCDP允许Selenium直接获取performance日志。借助这个能力可以精确拿到页面各阶段的耗时from selenium.webdriver.common.devtools.v85 import performance # 启用性能日志 driver.execute_cdp_cmd(Performance.enable, {}) # 获取导航时间线数据 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的数据你可以看到DOMContentLoadedDOM解析完成和loadEventFiredonload触发之间的时间差。如果loadEventFired比domContentLoaded晚了三五秒那多出来的时间多半就是你等第三方资源白白浪费的也就是说服务端很快前端渲染也很快纯粹是页面设计上的资源加载拖了后腿。这种时候调整Selenium的页面加载策略就是最直接的优化手段。3.3 抓包看资源请求是不是在等无关紧要的静态资源如果页面加载偏慢且带有随机性我建议你用BrowserMob Proxy这类代理工具做一次抓包分析或者直接打开DevTools的Network面板手动看一眼。重点观察这几个指标有没有长时间pending的请求。有没有第三方域名的脚本或图片。静态资源有没有走CDN还是直接打到源站。有没有大体积图片、未压缩的JS/CSS文件。这步诊断的意义在于如果慢的根源是测试环境本身的网络差那优化Selenium配置是治标不治本如果慢的根源是页面挂了外部依赖那可以从测试环境层面做处理比如屏蔽或者mock掉这些无关请求。4. 核心优化一拦截无关资源加载给浏览器减负4.1 禁用图片、CSS、字体和媒体资源加载页面加载慢很多时候不是HTML本身慢而是因为浏览器要把图片、CSS、视频、广告脚本全都下载一遍。做自动化测试尤其是功能逻辑回归很多视觉资源根本不需要加载。用ChromeOptions禁用这些资源的加载速度提升非常明显。下面这段是我在项目里常用的配置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谨慎使用 } options.add_experimental_option(prefs, prefs) driver webdriver.Chrome(optionsoptions)需要特别提醒的是禁用CSS需要谨慎。很多前端框架的点击事件依赖CSS控制的可点击区域而且有些元素在CSS未加载时宽高为0Selenium的点击会报element not interactable。所以更稳妥的做法是只禁用图片和媒体资源CSS保持加载。我实测过一个后台管理系统禁用图片后登录页加载时间从7秒降低到3秒左右列表页从5秒降到2秒。而且测试用例本身不依赖页面上的图片是否显示完全没有影响。4.2 拦截第三方域名请求屏蔽广告SDK和统计脚本如果页面上集成了一堆第三方服务比如数据统计、广告、在线客服、异常上报它们虽然不影响业务功能但会拖慢onload的触发时间。一个很有效的做法是用Chrome DevTools Protocol的Network.setBlockedURLs方法把这些域名直接拦掉。driver.execute_cdp_cmd(Network.enable, {}) driver.execute_cdp_cmd(Network.setBlockedURLs, { urls: [ *.google-analytics.com/*, *.googletagmanager.com/*, *.hm.baidu.com/*, *.cnzz.com/*, *ads*.com/* ] })需要注意顺序这段代码必须在driver.get()之前执行否则页面已经开始加载了再去拦截就起不到省时的作用了。我之前负责过一个嵌了五六个第三方SDK的活动页不拦截第三方时get()要等12秒拦截之后3秒内就返回了。差异就是这么夸张。4.3 条件允许时直接上无头模式如果你的用例不需要真的看到浏览器界面比如纯回归、纯接口链路验证无头模式是性价比最高的提速手段。去掉了渲染和GPU合成的大量开销同一条用例的执行时间通常能减少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)不过要说句公道话无头模式并不等于永远更快。在某些复杂交互场景下比如文件上传中有flash组件、拖拽依赖物理像素级坐标、或者某些canvas渲染动画无头模式反而可能出问题。所以我的建议是分层执行——本地调试和排查问题时用有头模式CI流水线和夜间回归用无头模式。5. 核心优化二页面加载策略的正确配置5.1 normal、eager、none三种策略到底怎么选Selenium的page_load_strategy有三种取值这是解决网页加载慢最直接的参数但很多人没用对。三种策略的区别如下策略特点driver.get()何时返回适用场景normal默认策略等待onload事件所有资源加载完成后返回对页面完整性要求高的场景eager等待DOMContentLoaded事件DOM解析完成后即返回大多数页面交互测试none不等待页面加载事件导航开始后立即返回需要完全自己控制等待逻辑的高级操作切换到eager是最稳妥的提速手段。它不需要等到图片、iframe、广告脚本全部加载完才返回控制权而只需要DOM解析完成。对大部分业务系统来说DOM解析完成时关键元素基本都已经可用了后面配合显式等待即可。配置方法很简单options.page_load_strategy eager driver webdriver.Chrome(optionsoptions)我建议在绝大多数项目里直接用eager而不是一上来就上none。原因后面会讲。5.2 关于页面加载策略设为none的进阶用法与雷区none策略确实是最激进的提速方案设置为none后driver.get()在发起导航请求后就立刻返回不等任何加载事件。听起来很香但坑也很深。我见过很多人把page_load_strategy设成none之后紧接着就写driver.find_element(...)去定位元素结果浏览器地址栏都还没跳转直接报NoSuchElementException。原因很简单——none模式下浏览器可能在后台还没开始发起真正的导航请求页面还停留在old page状态。所以如果要使用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) # 主动等待导航发生并且页面出现标志性元素 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)) )这样写虽然灵活但每到一个新页面你都要写一堆显式等待代码维护成本会上升。我的取舍是除非某个页面的onload尤其慢且不可控否则优先用eager而不是none。eager已经能解决90%的等太久问题而且代码改动量最小。6. 核心优化三等待策略重构把固定sleep全部替换掉6.1 用显式等待替代time.sleep()的完整思路这次优化的逻辑很简单等待的目的不是等一段时间而是等到某个条件满足。显式等待WebDriverWait干的正是这件事。通用做法是写一个专门等待元素可用的工具函数。我项目里有个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): 等待元素可见且可点击返回元素对象 return WebDriverWait(driver, timeout, poll_frequency).until( EC.element_to_be_clickable((by, locator)), f元素 {locator} 在 {timeout}s 内未可点击 ) def wait_for_text(driver, text, timeout10): 等待页面上出现指定文本 return WebDriverWait(driver, timeout).until( EC.text_to_be_present_in_element((By.TAG_NAME, body), text), f文本 {text} 在 {timeout}s 内未出现 )然后在业务代码里把time.sleep(5)替换成wait_until_clickable(driver, By.ID, submit-btn).click() wait_for_text(driver, 订单提交成功)这套写法的好处是页面快的时候条件立刻满足一秒都不多等页面慢的时候最长等待时间可控不会因为网络抖动直接失败。6.2 处理Selenium中AJAX数据加载的等待技巧现代前端应用大量使用AJAX异步加载数据比如列表页先渲染出空壳再通过接口调取数据填充表格。这种场景下等待元素存在还不够必须等待数据渲染完成。我的做法是瞄着一个数据渲染完成的标志性表现下条件常用几种表格中出现了预期行数的数据记录。页面上的loading spinner消失。某个特定文本如共X条记录出现。某个元素的class属性变化比如从loading变为loaded。以表格数据为例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)) ) # 等待表格数据行的数量达到预期 WebDriverWait(driver, 15).until( lambda d: len(d.find_elements(By.CSS_SELECTOR, table tbody tr)) 10 )lambda写法是我特别推荐的一个技巧。WebDriverWait的until方法接受一个可调用对象这个对象接收driver参数并返回一个布尔值或元素列表。你可以用它来写任意复杂的等待条件而不只是依赖Selenium预置的expected_conditions。6.3 轮询频率设置别让默认0.5秒的轮询拖累你的速度一个很容易被忽略的细节是WebDriverWait的poll_frequency参数。默认值是0.5秒也就是说如果预期条件在第0.1秒就满足了你也得等到第0.5秒的轮询点才能拿到结果。在页面数量多的测试套件里每次等待白白空转0.4秒几百次累积起来也很可观。对于响应极快的本地系统我习惯把轮询频率调小WebDriverWait(driver, 10, poll_frequency0.1).until(...)反之如果页面加载本身就很慢轮询太频繁反而给浏览器增加压力一般0.5秒已经够用。我的建议是本地调试和测试环境用0.1秒生产环境压测或远程环境用0.2到0.5秒。6.4 设置合理的全局脚本超时和页面加载超时还有两个超时设置容易被忽略driver.set_page_load_timeout()和driver.set_script_timeout()。driver.set_page_load_timeout(30) # 页面加载超时 driver.set_script_timeout(30) # 异步脚本执行超时合理设置超时的价值在于当一个页面真的卡死或者第三方资源长时间无响应时测试不会无限期等下去而是快速失败把问题暴露出来。这表面上看是让测试更快失败实际上是节省了整个回归套件的时间。7. 核心优化四浏览器实例复用和测试代码写法优化7.1 避免每个用例都重新启动浏览器很多测试框架的初始模板都是一个用例就启动一次driver用例结束就driver.quit()。这种做法干净但代价极大。启动一个干净的Chrome实例冷启动耗时要2到5秒如果套件里有两百个用例光启动浏览器就要十分钟。我常用的两种优化思路在pytest里用session级别的fixture让整个测试会话共享同一个driver实例。在用例之间做页面状态清理而不是重复启动浏览器。以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()但要注意共享浏览器实例后会引入用例间的状态耦合问题比如登录态、localStorage缓存互相影响。所以在用例设计阶段就要规划好哪些用例可以共享会话哪些必须用独立的浏览器上下文。7.2 控制用例粒度减少不必要的页面导航和重复操作我遇到过一种极端的用例写法每条用例都从登录开始然后走一遍完整业务流程最后再退出登录。两百条用例全部重复登录登出这个时间是巨大的浪费。优化的思路是进行用例分层登录验证本身保留一两个完整登录流程的用例。业务功能用例基于已登录状态执行避免频繁跳转回登录页。通过设置cookie、调接口预置数据等方式跳过无关的页面操作。比如在UI自动化中可以通过CDP直接添加cookie来维持登录态driver.execute_cdp_cmd(Network.enable, {}) # 导出一条已登录会话的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)这种做法对于前后端分离的系统尤其有效省掉了每次打开登录页、输入账号、等待跳转的时间。7.3 JavaScript滚动、点击与属性获取的加速替代方案Selenium定位元素之后执行click()理论上都是通过驱动转发命令。有些场景下用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直接触发点击不仅快而且更稳。Canvas里的元素用DOM定位根本定位不到这种场景下JS执行几乎是唯一选择。需要说明的是这个优化点带来的是每条操作节省几十毫秒级别的收益看起来不起眼但一个用例几十个操作累积下来差别还是可以感知的。8. 慢之外更要稳提速后容易踩的太快导致失败的坑8.1 元素还没挂到DOM上就开始操作提速之后最讽刺的事情是以前是等太久现在是操作得太快反而把用例搞挂了。典型场景是设置page_load_strategyeager之后driver.get()返回了但页面JavaScript还没执行完按钮还没绑定事件此时去click只会得到一个宽高为0或没绑事件的元素。解决思路很明确所有关键操作前务必加一道显式等待可交互的条件而不是存在条件。WebDriverWait(driver, 10).until( EC.element_to_be_clickable((By.ID, submit-btn)) )8.2 登录态和缓存导致的用例间数据污染共享浏览器实例之后页面间的localStorage、sessionStorage可能会互相污染。比如用例A往localStorage里写了一个token用例B启动时读到了这个token用例B的执行结果就不再是从干净状态开始的结果了。对此我的建议是在关键用例前后做一次状态清理try: driver.execute_script(window.localStorage.clear(); window.sessionStorage.clear();) except Exception: pass同时在测试数据设计上尽量让用例之间不共享可变数据比如每个人使用自己的测试账号和数据记录。9. 实测对比同一套件优化前后的时间变化光说理论和方案不够直观。拿我自己维护的那套商城回归用例来举例两百一十二条用例测试环境是公司内网的预发布环境。优化前状态Chrome默认配置未设置page_load_strategy。代码里到处都是time.sleep(3)或time.sleep(5)。每个用例独立启动driver。未屏蔽任何静态资源或第三方请求。跑完全部的执行时间大约是两个小时五十分钟失败率在3%左右。优化动作page_load_strategy设为eager。移除全部time.sleep替换为显式等待和lambda条件等待。禁用图片、视频等媒体资源加载。拦截第三方统计和广告SDK域名。pytest fixture改为session级别复用driver实例。删除每个用例的重复登录逻辑仅在会话开始时做一次登录。优化后同一套件的执行时间大约是四十二分钟。时间缩短了近八成。当然这个结果和用例的具体场景有关但整体趋势是很有代表性的。有一点必须强调这些优化对测试稳定性的影响是双面的。正确配置的等待策略会让测试更稳因为条件等待本身就比固定等待更健壮但如果为了提速把所有等待都删掉那失败率会直线上升。提速的目的是让测试在可控的时间内跑完而不是为了快而牺牲可靠性。10. 终极建议什么情况下该优化Selenium什么情况下该换工具聊了这么多提速手段最后必须说一个更根本的问题。Selenium天然是一个偏重模拟用户操作的工具它的架构决定了它不可能比接口测试快。如果你的自动化测试场景里90%的时间都花在等页面加载而不是验证业务逻辑上那可能你根本用错工具了。我的个人判断是如果只是验证后端接口返回的数据和状态码直接用Requests/HTTP客户端、或者接口自动化测试框架速度是Selenium的几十倍。如果要做的是核心业务链路冒烟测试比如下单、支付、审批流这些必须验证真实浏览器交互的才适合继续用Selenium。如果要做大规模数据抓取Selenium也是下策换成直接构造HTTP请求的方式配合简单的登录态维持效率会高得多。所谓AI自动化测试平台搭建也不是直接拿Selenium裸跑。我曾经参与过一个小型测试平台的设计底层用Selenium Grid做分布式执行可以同时把用例分到多台机器上跑从架构层面横向扩展执行能力。这也是Selenium提速的一个深层方向——单机优化终究有天花板分布式并行才是大规模回归的最终解法。所以最后我的建议是先把本篇文章里的单机优化方案落地如果还不够快再往分布式和分层自动化方向走。工具永远是为目标服务的别被UI自动化这四个字框住思路。 
长河君 · 2026/9/8 10:10:19 · 阅读 1.2k Selenium自动化测试提速：从页面加载策略到等待机制优化
1. 从一次深夜发版说起Selenium慢的根子到底在哪先说个真实场景。上个月我维护的一个核心商城项目要做大版本回归UI自动化用例两百多条跑完一轮要将近三个小时。那天晚上十点开始跑本打算十二点收工结果凌晨两点半才跑完中途还挂了六条用例——全是超时不是功能bug。第二天开发改了个字段我下午想快速验证一下核心链路结果光等页面加载就等了快四十秒。如果你也干过UI自动化这种感受应该不陌生Selenium的执行速度很多时候不是被测系统慢而是我们的用法不对。很多新手会把网页加载太慢直接归咎于网络或者服务器响应慢但实际上用Selenium做自动化测试时页面加载慢的原因往往是多层的。这个问题的核心关键词是Selenium、自动化测试、网页加载今天这篇文章不打算泛泛讲理论而是从根因拆解、诊断方法、到具体的优化手段把我实际在项目里验证过的方案完整梳理一遍。先说结论Selenium慢通常不是某一个原因造成的而是浏览器加载策略、等待机制、资源请求、测试代码写法这四个维度叠加的结果。你只用对了一半速度可能就翻倍全都用对两百条用例的回归时间从三小时压到四十分钟是完全可行的。我的一个判断原则是先诊断后优化不要一上来就改代码。很多人在网上看到设置page_load_strategy为none就抄过来结果页面还没渲染完就开始找元素报错更多了。所以这篇文章的第一部分先把Selenium为什么慢的机理讲清楚然后再说怎么科学地把速度提上来。2. 打开网页到底卡在哪加载过程全链路拆解2.1 阻塞时间线从发出请求到元素可交互中间发生了什么我用一个简单例子来还原Selenium打开页面的完整过程。假设你用webdriver.get()去访问一个电商首页表面上看只是打开网页但底层要经历这些步骤驱动进程启动浏览器实例ChromeDriver启动Chrome这一步本身就要占用几百毫秒到一两秒。浏览器发起HTTP请求经历了DNS解析、TCP握手、TLS协商、服务器处理、响应返回。浏览器开始解析HTML构建DOM树。加载过程中遇到script脚本默认会阻塞解析。CSS、图片、字体、iframe等子资源继续加载。触发onload事件——注意Selenium的get()方法默认会等到onload事件触发才返回。麻烦就出在第6步。Selenium WebDriver按照W3C规范默认的页面加载策略是normal意味着driver.get()要一直等到window.onload触发完毕才把控制权交还给你。如果一个页面上有第三方统计脚本、广告SDK、埋点上报之类的组件这些资源加载慢或者干脆挂起onload就迟迟不触发你的自动化脚本就只能干等。我在测试一个资讯类网站时遇到过特别典型的情况正文内容两秒就渲染完了但页面上嵌了一个第三方登录SDK的脚本那个脚本的服务器在境外响应时间忽快忽慢离谱的时候要等十几秒。用Selenium默认配置去跑每次访问文章详情页都要卡十几秒实际上页面主体内容早就可用了。这解释了为什么有时候你手动打开网页觉得挺快但自动化脚本却慢得离谱——你手动感知的加载完和浏览器onload事件触发的加载完压根不是一回事。2.2 除了onload之外隐式等待和显式等待的叠加效应另一个让Selenium变慢的隐藏因素是等待策略配置不当。很多教程会让你在初始化driver之后加一句driver.implicitly_wait(10)意思是找不到元素时最多等10秒。这个等待不是轮询到元素就立刻返回吗是但问题在于隐式等待对find_element系列方法生效而且不会和其他等待策略互相抵消。如果你同时设置了隐式等待和显式等待WebDriverWait那情况就会很微妙。举个例子driver webdriver.Chrome() driver.implicitly_wait(10) # 在代码后面某处 element WebDriverWait(driver, 10).until( EC.element_to_be_clickable((By.ID, submit-btn)) )这种写法下显式等待本身会轮询条件。每轮询一次底层都会执行一次find_element而这个find_element又会受到隐式等待的影响——也就是说element_to_be_clickable每次轮询检查元素是否存在时都可能额外等待最长10秒。如果元素一直没出现你的总等待时间就不是10秒而是远远超过10秒。网上有很多人反映WebDriverWait等待20秒却报了超时的帖子多半就是隐式等待和显式等待打架造成的。我处理这个问题的原则很简单代码里只保留一种等待机制。项目里统一用显式等待初始化driver之后不再设置implicitly_wait。2.3 盲等time.sleep()是拖慢测试的最大元凶还有一个常见写法初学Selenium的人喜欢到处time.sleep(5)等个固定时间再继续操作。这在小规模演示脚本里问题不大但在大型测试套件里就是灾难。固定sleep有两大问题。一是如果网络快、页面加载快sleep的固定时间就纯属浪费二是如果网络慢、页面加载超过了sleep时间脚本照样会失败。两全其美靠的应该是基于条件的等待而不是基于时间的猜测。我见过一个外包团队写的脚本每个页面上都有五六个time.sleep(3)一个用例跑下来光sleep就要二十多秒整个套件两百条用例光浪费在blind sleep上的时间就有七千多秒——两个多小时。把sleep全部改成显式等待之后执行时间直接砍半。3. 定位瓶颈三板斧先给Selenium提速前先做这四件事3.1 用性能分析工具记录每一段操作的耗时动手优化前你得知道时间到底花在哪了。我习惯在测试脚本里加轻量级的计时逻辑具体做法是给每个关键步骤打点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(首屏关键元素出现, start) start time.time() WebDriverWait(driver, 3).until( EC.text_to_be_present_in_element((By.TAG_NAME, body), 订单号) ) log_time(业务数据渲染完成, start)跑一次用例输出的时间点清清楚楚到底是get()耗时高还是等待元素出现耗时高又或者是点击之后到下一个页面可交互耗时高。有了这条时间线优化才有依据。3.2 区分服务端慢前端渲染慢和自动化机制慢这是最容易被忽略的一道分界线。同一个页面在浏览器手动打开很快但自动化脚本慢问题大概率出在自动化机制上反过来你要在Selenium里通过navigation timing接口拿到真实数据来区分。Chrome DevTools ProtocolCDP允许Selenium直接获取performance日志。借助这个能力可以精确拿到页面各阶段的耗时from selenium.webdriver.common.devtools.v85 import performance # 启用性能日志 driver.execute_cdp_cmd(Performance.enable, {}) # 获取导航时间线数据 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的数据你可以看到DOMContentLoadedDOM解析完成和loadEventFiredonload触发之间的时间差。如果loadEventFired比domContentLoaded晚了三五秒那多出来的时间多半就是你等第三方资源白白浪费的也就是说服务端很快前端渲染也很快纯粹是页面设计上的资源加载拖了后腿。这种时候调整Selenium的页面加载策略就是最直接的优化手段。3.3 抓包看资源请求是不是在等无关紧要的静态资源如果页面加载偏慢且带有随机性我建议你用BrowserMob Proxy这类代理工具做一次抓包分析或者直接打开DevTools的Network面板手动看一眼。重点观察这几个指标有没有长时间pending的请求。有没有第三方域名的脚本或图片。静态资源有没有走CDN还是直接打到源站。有没有大体积图片、未压缩的JS/CSS文件。这步诊断的意义在于如果慢的根源是测试环境本身的网络差那优化Selenium配置是治标不治本如果慢的根源是页面挂了外部依赖那可以从测试环境层面做处理比如屏蔽或者mock掉这些无关请求。4. 核心优化一拦截无关资源加载给浏览器减负4.1 禁用图片、CSS、字体和媒体资源加载页面加载慢很多时候不是HTML本身慢而是因为浏览器要把图片、CSS、视频、广告脚本全都下载一遍。做自动化测试尤其是功能逻辑回归很多视觉资源根本不需要加载。用ChromeOptions禁用这些资源的加载速度提升非常明显。下面这段是我在项目里常用的配置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谨慎使用 } options.add_experimental_option(prefs, prefs) driver webdriver.Chrome(optionsoptions)需要特别提醒的是禁用CSS需要谨慎。很多前端框架的点击事件依赖CSS控制的可点击区域而且有些元素在CSS未加载时宽高为0Selenium的点击会报element not interactable。所以更稳妥的做法是只禁用图片和媒体资源CSS保持加载。我实测过一个后台管理系统禁用图片后登录页加载时间从7秒降低到3秒左右列表页从5秒降到2秒。而且测试用例本身不依赖页面上的图片是否显示完全没有影响。4.2 拦截第三方域名请求屏蔽广告SDK和统计脚本如果页面上集成了一堆第三方服务比如数据统计、广告、在线客服、异常上报它们虽然不影响业务功能但会拖慢onload的触发时间。一个很有效的做法是用Chrome DevTools Protocol的Network.setBlockedURLs方法把这些域名直接拦掉。driver.execute_cdp_cmd(Network.enable, {}) driver.execute_cdp_cmd(Network.setBlockedURLs, { urls: [ *.google-analytics.com/*, *.googletagmanager.com/*, *.hm.baidu.com/*, *.cnzz.com/*, *ads*.com/* ] })需要注意顺序这段代码必须在driver.get()之前执行否则页面已经开始加载了再去拦截就起不到省时的作用了。我之前负责过一个嵌了五六个第三方SDK的活动页不拦截第三方时get()要等12秒拦截之后3秒内就返回了。差异就是这么夸张。4.3 条件允许时直接上无头模式如果你的用例不需要真的看到浏览器界面比如纯回归、纯接口链路验证无头模式是性价比最高的提速手段。去掉了渲染和GPU合成的大量开销同一条用例的执行时间通常能减少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)不过要说句公道话无头模式并不等于永远更快。在某些复杂交互场景下比如文件上传中有flash组件、拖拽依赖物理像素级坐标、或者某些canvas渲染动画无头模式反而可能出问题。所以我的建议是分层执行——本地调试和排查问题时用有头模式CI流水线和夜间回归用无头模式。5. 核心优化二页面加载策略的正确配置5.1 normal、eager、none三种策略到底怎么选Selenium的page_load_strategy有三种取值这是解决网页加载慢最直接的参数但很多人没用对。三种策略的区别如下策略特点driver.get()何时返回适用场景normal默认策略等待onload事件所有资源加载完成后返回对页面完整性要求高的场景eager等待DOMContentLoaded事件DOM解析完成后即返回大多数页面交互测试none不等待页面加载事件导航开始后立即返回需要完全自己控制等待逻辑的高级操作切换到eager是最稳妥的提速手段。它不需要等到图片、iframe、广告脚本全部加载完才返回控制权而只需要DOM解析完成。对大部分业务系统来说DOM解析完成时关键元素基本都已经可用了后面配合显式等待即可。配置方法很简单options.page_load_strategy eager driver webdriver.Chrome(optionsoptions)我建议在绝大多数项目里直接用eager而不是一上来就上none。原因后面会讲。5.2 关于页面加载策略设为none的进阶用法与雷区none策略确实是最激进的提速方案设置为none后driver.get()在发起导航请求后就立刻返回不等任何加载事件。听起来很香但坑也很深。我见过很多人把page_load_strategy设成none之后紧接着就写driver.find_element(...)去定位元素结果浏览器地址栏都还没跳转直接报NoSuchElementException。原因很简单——none模式下浏览器可能在后台还没开始发起真正的导航请求页面还停留在old page状态。所以如果要使用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) # 主动等待导航发生并且页面出现标志性元素 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)) )这样写虽然灵活但每到一个新页面你都要写一堆显式等待代码维护成本会上升。我的取舍是除非某个页面的onload尤其慢且不可控否则优先用eager而不是none。eager已经能解决90%的等太久问题而且代码改动量最小。6. 核心优化三等待策略重构把固定sleep全部替换掉6.1 用显式等待替代time.sleep()的完整思路这次优化的逻辑很简单等待的目的不是等一段时间而是等到某个条件满足。显式等待WebDriverWait干的正是这件事。通用做法是写一个专门等待元素可用的工具函数。我项目里有个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): 等待元素可见且可点击返回元素对象 return WebDriverWait(driver, timeout, poll_frequency).until( EC.element_to_be_clickable((by, locator)), f元素 {locator} 在 {timeout}s 内未可点击 ) def wait_for_text(driver, text, timeout10): 等待页面上出现指定文本 return WebDriverWait(driver, timeout).until( EC.text_to_be_present_in_element((By.TAG_NAME, body), text), f文本 {text} 在 {timeout}s 内未出现 )然后在业务代码里把time.sleep(5)替换成wait_until_clickable(driver, By.ID, submit-btn).click() wait_for_text(driver, 订单提交成功)这套写法的好处是页面快的时候条件立刻满足一秒都不多等页面慢的时候最长等待时间可控不会因为网络抖动直接失败。6.2 处理Selenium中AJAX数据加载的等待技巧现代前端应用大量使用AJAX异步加载数据比如列表页先渲染出空壳再通过接口调取数据填充表格。这种场景下等待元素存在还不够必须等待数据渲染完成。我的做法是瞄着一个数据渲染完成的标志性表现下条件常用几种表格中出现了预期行数的数据记录。页面上的loading spinner消失。某个特定文本如共X条记录出现。某个元素的class属性变化比如从loading变为loaded。以表格数据为例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)) ) # 等待表格数据行的数量达到预期 WebDriverWait(driver, 15).until( lambda d: len(d.find_elements(By.CSS_SELECTOR, table tbody tr)) 10 )lambda写法是我特别推荐的一个技巧。WebDriverWait的until方法接受一个可调用对象这个对象接收driver参数并返回一个布尔值或元素列表。你可以用它来写任意复杂的等待条件而不只是依赖Selenium预置的expected_conditions。6.3 轮询频率设置别让默认0.5秒的轮询拖累你的速度一个很容易被忽略的细节是WebDriverWait的poll_frequency参数。默认值是0.5秒也就是说如果预期条件在第0.1秒就满足了你也得等到第0.5秒的轮询点才能拿到结果。在页面数量多的测试套件里每次等待白白空转0.4秒几百次累积起来也很可观。对于响应极快的本地系统我习惯把轮询频率调小WebDriverWait(driver, 10, poll_frequency0.1).until(...)反之如果页面加载本身就很慢轮询太频繁反而给浏览器增加压力一般0.5秒已经够用。我的建议是本地调试和测试环境用0.1秒生产环境压测或远程环境用0.2到0.5秒。6.4 设置合理的全局脚本超时和页面加载超时还有两个超时设置容易被忽略driver.set_page_load_timeout()和driver.set_script_timeout()。driver.set_page_load_timeout(30) # 页面加载超时 driver.set_script_timeout(30) # 异步脚本执行超时合理设置超时的价值在于当一个页面真的卡死或者第三方资源长时间无响应时测试不会无限期等下去而是快速失败把问题暴露出来。这表面上看是让测试更快失败实际上是节省了整个回归套件的时间。7. 核心优化四浏览器实例复用和测试代码写法优化7.1 避免每个用例都重新启动浏览器很多测试框架的初始模板都是一个用例就启动一次driver用例结束就driver.quit()。这种做法干净但代价极大。启动一个干净的Chrome实例冷启动耗时要2到5秒如果套件里有两百个用例光启动浏览器就要十分钟。我常用的两种优化思路在pytest里用session级别的fixture让整个测试会话共享同一个driver实例。在用例之间做页面状态清理而不是重复启动浏览器。以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()但要注意共享浏览器实例后会引入用例间的状态耦合问题比如登录态、localStorage缓存互相影响。所以在用例设计阶段就要规划好哪些用例可以共享会话哪些必须用独立的浏览器上下文。7.2 控制用例粒度减少不必要的页面导航和重复操作我遇到过一种极端的用例写法每条用例都从登录开始然后走一遍完整业务流程最后再退出登录。两百条用例全部重复登录登出这个时间是巨大的浪费。优化的思路是进行用例分层登录验证本身保留一两个完整登录流程的用例。业务功能用例基于已登录状态执行避免频繁跳转回登录页。通过设置cookie、调接口预置数据等方式跳过无关的页面操作。比如在UI自动化中可以通过CDP直接添加cookie来维持登录态driver.execute_cdp_cmd(Network.enable, {}) # 导出一条已登录会话的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)这种做法对于前后端分离的系统尤其有效省掉了每次打开登录页、输入账号、等待跳转的时间。7.3 JavaScript滚动、点击与属性获取的加速替代方案Selenium定位元素之后执行click()理论上都是通过驱动转发命令。有些场景下用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直接触发点击不仅快而且更稳。Canvas里的元素用DOM定位根本定位不到这种场景下JS执行几乎是唯一选择。需要说明的是这个优化点带来的是每条操作节省几十毫秒级别的收益看起来不起眼但一个用例几十个操作累积下来差别还是可以感知的。8. 慢之外更要稳提速后容易踩的太快导致失败的坑8.1 元素还没挂到DOM上就开始操作提速之后最讽刺的事情是以前是等太久现在是操作得太快反而把用例搞挂了。典型场景是设置page_load_strategyeager之后driver.get()返回了但页面JavaScript还没执行完按钮还没绑定事件此时去click只会得到一个宽高为0或没绑事件的元素。解决思路很明确所有关键操作前务必加一道显式等待可交互的条件而不是存在条件。WebDriverWait(driver, 10).until( EC.element_to_be_clickable((By.ID, submit-btn)) )8.2 登录态和缓存导致的用例间数据污染共享浏览器实例之后页面间的localStorage、sessionStorage可能会互相污染。比如用例A往localStorage里写了一个token用例B启动时读到了这个token用例B的执行结果就不再是从干净状态开始的结果了。对此我的建议是在关键用例前后做一次状态清理try: driver.execute_script(window.localStorage.clear(); window.sessionStorage.clear();) except Exception: pass同时在测试数据设计上尽量让用例之间不共享可变数据比如每个人使用自己的测试账号和数据记录。9. 实测对比同一套件优化前后的时间变化光说理论和方案不够直观。拿我自己维护的那套商城回归用例来举例两百一十二条用例测试环境是公司内网的预发布环境。优化前状态Chrome默认配置未设置page_load_strategy。代码里到处都是time.sleep(3)或time.sleep(5)。每个用例独立启动driver。未屏蔽任何静态资源或第三方请求。跑完全部的执行时间大约是两个小时五十分钟失败率在3%左右。优化动作page_load_strategy设为eager。移除全部time.sleep替换为显式等待和lambda条件等待。禁用图片、视频等媒体资源加载。拦截第三方统计和广告SDK域名。pytest fixture改为session级别复用driver实例。删除每个用例的重复登录逻辑仅在会话开始时做一次登录。优化后同一套件的执行时间大约是四十二分钟。时间缩短了近八成。当然这个结果和用例的具体场景有关但整体趋势是很有代表性的。有一点必须强调这些优化对测试稳定性的影响是双面的。正确配置的等待策略会让测试更稳因为条件等待本身就比固定等待更健壮但如果为了提速把所有等待都删掉那失败率会直线上升。提速的目的是让测试在可控的时间内跑完而不是为了快而牺牲可靠性。10. 终极建议什么情况下该优化Selenium什么情况下该换工具聊了这么多提速手段最后必须说一个更根本的问题。Selenium天然是一个偏重模拟用户操作的工具它的架构决定了它不可能比接口测试快。如果你的自动化测试场景里90%的时间都花在等页面加载而不是验证业务逻辑上那可能你根本用错工具了。我的个人判断是如果只是验证后端接口返回的数据和状态码直接用Requests/HTTP客户端、或者接口自动化测试框架速度是Selenium的几十倍。如果要做的是核心业务链路冒烟测试比如下单、支付、审批流这些必须验证真实浏览器交互的才适合继续用Selenium。如果要做大规模数据抓取Selenium也是下策换成直接构造HTTP请求的方式配合简单的登录态维持效率会高得多。所谓AI自动化测试平台搭建也不是直接拿Selenium裸跑。我曾经参与过一个小型测试平台的设计底层用Selenium Grid做分布式执行可以同时把用例分到多台机器上跑从架构层面横向扩展执行能力。这也是Selenium提速的一个深层方向——单机优化终究有天花板分布式并行才是大规模回归的最终解法。所以最后我的建议是先把本篇文章里的单机优化方案落地如果还不够快再往分布式和分层自动化方向走。工具永远是为目标服务的别被UI自动化这四个字框住思路。