我做了好几年的 Web 自动化测试Selenium 用得多了最常被问到的一个问题就是“脚本跑起来太慢了一个用例动不动就几分钟怎么办”确实Selenium 自动化测试跑得慢是整个行业的老大难。但很多人没搞清楚一件事慢的根源往往不是 Selenium 本身而是你在用它的时候踩了一堆隐蔽的坑。比如不合理地等待页面加载、每次用例都重新启动浏览器、元素定位写得太烂……这些问题叠加起来测试时间能被拉长 3 到 5 倍。这篇文章我就结合自己实际项目里的踩坑和优化经验把 Selenium 自动化测试网页加载慢的核心原因、定位方法和解决方案一次讲透。不管你是刚入门的测试新人还是被用例耗时折磨的资深测试都能在这里找到可以参考的思路。1. 先搞清楚你的慢到底慢在哪1.1 慢的三种常见形态我在接手团队测试框架的时候第一件事不是急着改代码而是先看用例耗时分布。因为“网页加载慢”是一个很模糊的症状背后可能是完全不同的问题。根据我观察到的实际现象大体可以分成三类第一类是单次访问页面特别慢。也就是浏览器打开一个 URL要等好几秒甚至十几秒才能完成加载。这种情况常见于被测系统的首页图片资源多、接口响应慢或者测试环境网络本身就不稳定。但这里有个容易被忽略的点Selenium 的driver.get()默认会等待页面onload事件触发。如果页面上有什么第三方统计脚本一直在加载、或者某个接口挂起不返回driver.get()就会一直等下去直到超时。很多你以为的“页面加载慢”其实是onload事件被阻塞了。第二类是定位元素等待时间过长。这类问题更普遍。比如你写了time.sleep(5)不管页面 1 秒就加载完还是 5 秒加载完它都固定等 5 秒。如果每个页面操作前都这么来一下一个用例跑下来光是死等的时间就能占到总耗时的一半以上。第三类是整体跑批时间太长。单个用例不慢但整个测试套件跑下来要一两个小时。这个往往是架构层面的问题比如用例之间没有做浏览器复用、没有开并行执行导致大量时间浪费在重复启动浏览器、加载空白页、初始化驱动这些环节上。1.2 用简单方法给“慢”做初步定位要判断到底属于哪一类不需要上什么高级工具加日志就行。我在项目里常用的做法是给关键步骤打点import time from selenium import webdriver start time.time() driver webdriver.Chrome() print(f启动浏览器耗时: {time.time() - start:.2f} 秒) start time.time() driver.get(http://your-test-site.com) print(f页面加载耗时: {time.time() - start:.2f} 秒) start time.time() element driver.find_element(By.ID, username) print(f元素定位耗时: {time.time() - start:.2f} 秒)看到分段耗时后再下结论。我见过太多人一上来就改代码结果改了半天发现瓶颈根本不是自己想的那块。另外有个经验可以分享如果一次性打开 10 个页面都慢那大概率是被测系统或网络的问题如果只有个别页面慢那可能是页面本身的资源加载问题如果每次跑脚本都比手动操作慢很多那问题就出在自动化代码的等待策略上。2. 核心优化第一步调整页面加载策略2.1 pageLoadStrategy 的三种模式Selenium 的 WebDriver 在加载页面时有一个pageLoadStrategy页面加载策略它直接决定了driver.get()要等到什么时候才算“加载完成”。默认值是normal也就是要等页面触发onload事件才返回。但很多页面根本不关心onload它的核心内容早在 DOM Ready 的时候就可以操作了。我就遇到过这样一个案例被测系统首页加载了一堆数据可视化图表图表渲染完成要好几秒但登录框这种核心元素在 DOM 加载后立即就能操作。结果自动化脚本里driver.get()硬是等了图表全部渲染完才往下走白白浪费了 5 秒多。页面加载策略提供了三种选项策略等待内容适用场景normal等待页面 onload 事件触发默认值稳定但慢eager等待 DOM 完全加载不等待样式、图片和子框架页面核心元素在 DOM 中就绪的场景none不等待任何加载事件立即返回需要完全手动控制等待的场景2.2 实际配置示例修改策略很简单在启动浏览器的时候设置即可from selenium import webdriver from selenium.webdriver.chrome.options import Options options Options() options.page_load_strategy eager # 使用 eager 策略 driver webdriver.Chrome(optionsoptions) driver.get(http://your-test-site.com)我把这个改到项目里之后首页加载时间直接从平均 8.2 秒降到了 3.1 秒提升非常明显。但这里要提醒一句换成eager之后后续的元素定位代码必须配上合理的显式等待否则很容易因为元素还没渲染出来而报找不到元素的错。你不能既想省时间又不想写等待鱼和熊掌不能兼得。对于页面元素极其简单的场景比如纯接口返回数据渲染的页面也可以用none策略然后再根据业务逻辑自己决定什么时候开始找元素。不过这个策略对脚本编写水平要求更高新手不建议直接用。3. 等待策略的重构把“死等”变成“等得准”3.1 隐式等待与显式等待的误区等待策略是自动化测试慢的“重灾区”也是优化空间最大的地方。我几乎每次帮别人排查用例慢的问题最后都能找到几处time.sleep()或者全局性的隐式等待设置。先说隐式等待implicitly_wait。它的工作机制是设置一个全局超时时间之后每次通过driver.find_element查找元素时如果元素没找到WebDriver 会在超时时间内持续轮询 DOM。这看起来挺美但坑在于隐式等待是全局性的你没法针对某个特定元素设置不同的等待时间。另外隐式等待与显式等待在某些情况下会互相干扰比如元素一直存在但处于不可点击状态时隐式等待不会帮你判断可点击性而显式等待可以做到。再说显式等待WebDriverWait。它允许你针对特定元素、特定条件设置超时时间和轮询频率这是目前推荐的写法。但很多人的用法是写time.sleep(3)代替显式等待这本质上就是把不确定性变成了固定等待页面快的时候浪费时间页面慢的时候又不够用。3.2 显式等待的正确姿势正确的做法是只等“必要条件”也就是等你要操作的那个元素出现在可交互状态。举个登录用例的例子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_element(driver, by, value, timeout10): return WebDriverWait(driver, timeout).until( EC.presence_of_element_located((by, value)) ) # 等登录按钮可点击 login_btn WebDriverWait(driver, 10).until( EC.element_to_be_clickable((By.ID, login-btn)) ) login_btn.click()这里的关键是把等待条件写对。如果你只是要元素存在用presence_of_element_located如果要操作它建议用element_to_be_clickable或者visibility_of_element_located。这两个条件的语义完全不同用错了就会出现“元素找到了但点击没反应”之类的玄学问题。3.3 自定义等待函数的实战价值比显式等待更进一步的做法是封装自定义等待函数。比如有些场景要等一个异步请求返回后页面才出现某些内容这时候标准条件就不太好使了。我在框架里通常会封装一个通用的轮询函数def wait_until(driver, condition_func, timeout15, interval0.5, description): 轮询等待自定义条件成立条件不满足时持续重试直到超时 start_time time.time() last_error None while time.time() - start_time timeout: try: if condition_func(driver): return True except Exception as e: last_error e time.sleep(interval) raise TimeoutError( f等待超时{timeout}秒: {description} (f最后错误: {last_error} if last_error else ) )这样封装之后测试代码里就完全不需要time.sleep()了。需要等什么条件就传什么条件等到就继续等不到就报超时错误报错信息还自带描述排查问题也方便。我实际改造过的项目里等请求返回的场景从固定 sleep 8 秒降到平均 1.5 秒单看一个操作可能感觉不多但整个回归套件几十个用例加起来省的时间就很可观了。4. 浏览器与网络环境层面的加速手段4.1 浏览器启动参数优化等待策略优化之后如果还是觉得慢可以看看浏览器本身能不能做减法。Chrome 启动时默认会加载一堆扩展、同步设置、自动填充等这些对自动化测试没任何用处纯属拖时间。我在项目里常用的无头加禁用参数配置是这样的options webdriver.ChromeOptions() # 无头模式运行节省资源 options.add_argument(--headlessnew) # 禁用 GPU 硬件加速 options.add_argument(--disable-gpu) # 禁用浏览器扩展 options.add_argument(--disable-extensions) # 禁用自动填充 options.add_argument(--disable-autofill) # 禁用通知弹窗 options.add_argument(--disable-notifications) # 禁止加载图片对测试无影响的场景可启用 prefs {profile.managed_default_content_settings.images: 2} options.add_experimental_option(prefs, prefs)这里重点说一下图片拦截。如果你的被测系统对图片不敏感比如后端管理后台、接口测试页面把图片加载关掉能带来很大的性能提升。有一次我在一个查询功能测试里关掉了图片加载页面加载时间直接少了 40%因为那个页面左侧挂了张很大的企业宣传图每轮操作都要重新拉一次。当然如果你测的是电商前台、设计稿这种图片敏感的场景这个配置就不能开。4.2 用性能日志定位资源瓶颈有时候页面等得久是因为有超大资源的加载。这时候可以打开 Chrome 的性能日志来看看到底是谁慢caps { goog:loggingPrefs: {performance: ALL}, goog:perfLoggingPrefs: { enableNetwork: True, enablePage: True, }, } options.set_capabilities(goog:loggingPrefs, caps) logs driver.get_log(performance) for entry in logs: message json.loads(entry[message])[message] method message[method] if method Network.responseReceived: params message[params] response params.get(response, {}) mime_type response.get(mimeType, ) url params.get(url, ) # 过滤大图片、大脚本、大样式文件 if mime_type.startswith(image/) or mime_type in (application/javascript, text/css): print(f资源加载: {response.get(status)} {url})通过日志里每个网络请求的响应时间你可以很直观地看到是哪个脚本、哪张图片拖慢了速度然后决定是前端配合优化资源还是在测试环境里用 hosts 拦截。我一般会从这条日志里挑出响应时间超过 1 秒的资源反馈给开发团队一起排查效率和自动化测试本身都能受益。4.3 本地静态资源替换加速还有一个偏门但很有效的技巧把被测页面里稳定的大静态资源比如 logo、字体文件在本地起一个代理或者直接改 hosts 映射到内网快速资源。这种操作只对测试环境有效需要开发或运维配合但效果立竿见影。做这些优化的时候一个原则要守住优化的前提是不影响测试结果的有效性。如果你的用例确实要验证图片是否展示、样式是否正常那就不能禁用图片加载。优化不是一刀切要根据具体场景灵活调整。5. 从架构层面解决并行执行与浏览器复用5.1 pytest-xdist 实现用例级并行单条脚本优化到位之后下一步就是解决整体跑批时间的问题。我最推荐的方式是使用pytest-xdist插件做用例级并行因为它对现有代码的侵入性最小配置起来非常快。pip install pytest-xdist然后在运行测试时指定并发数pytest -n 4这会启动 4 个 worker 进程每条用例会被自动分配到空闲的 worker 上执行。如果你的用例彼此没有状态依赖这是自动化测试的基本要求并行起来几乎没有成本。但并行执行有个容易踩的坑数据库测试数据冲突。比如多个 worker 同时执行“创建订单”的用例可能都会选择同一条测试数据然后互相修改导致断言失败。我的经验是要么给每条用例分配独立的数据范围比如用随机前缀要么在用例前置里动态创建干净的数据而不是依赖一个共享的固定测试数据集。另外并行的数量不是越多越好我习惯根据测试机 CPU 核数来定一般 4 到 8 个并发在普通办公机上表现最好开太多反而会因为资源竞争变慢。5.2 Selenium Grid 实现分布式执行如果单机资源有限或者需要跨浏览器兼容性测试可以考虑 Selenium Grid。它让测试用例在不同机器上分布式地启动浏览器典型架构是 1 个 Hub 管理多个 Node 节点。我这里给一个简单的 docker-compose 快速启动方案version: 3.8 services: selenium-hub: image: selenium/hub:4.15.0 container_name: selenium-hub ports: - 4444:4444 environment: - GRID_MAX_SESSION10 chrome-node: image: selenium/node-chrome:4.15.0 shm_size: 2gb depends_on: - selenium-hub environment: - SE_EVENT_BUS_HOSTselenium-hub - SE_EVENT_BUS_PUBLISH_PORT4442 - SE_EVENT_BUS_SUBSCRIBE_PORT4443启动之后脚本里指向 Hub 地址即可from selenium import webdriver from selenium.webdriver.chrome.options import Options options Options() driver webdriver.Remote( command_executorhttp://localhost:4444/wd/hub, optionsoptions )用 Selenium Grid 之后用例可以同时跑在多个浏览器实例上整个回归从 40 分钟压缩到 8 分钟以内很常见。但要注意Grid 对测试机的内存要求比较高每个 Chrome 实例大概要占 300 到 500MB 内存起 8 个并发之前先确认清楚。5.3 浏览器会话复用的思路还有一种优化思路是复用浏览器会话也就是一个测试用例跑完不关浏览器下一个用例继续用。这个在 Selenium 里原生不太好做但是可以通过debuggerAddress连接已启动的浏览器来实现# 先手动启动带调试端口的 Chrome # chrome --remote-debugging-port9222 from selenium import webdriver from selenium.webdriver.chrome.options import Options options Options() options.debugger_address localhost:9222 driver webdriver.Chrome(optionsoptions)这样连上的就是一个“真人在使用”的浏览器上下文不仅省掉了重复启动浏览器的时间还能直接操作你手动登入后的登录态处理那些和登录态耦合的用例非常方便。这个思路在调试阶段很有用CI 环境里不建议这么搞因为不稳定。6. 常见问题与排查技巧实录6.1 常见问题速查表我在优化 Selenium 测试速度的过程中积累了一批典型的“病因”和对应的“药方”整理成表分享给大家症状可能原因解决方案driver.get()长时间不返回页面 onload 被阻塞改用eager策略检查第三方脚本元素时有时无偶发失败等待策略不明确统一使用显式等待不写sleep每次启动浏览器都要好几秒驱动和浏览器版本不匹配升级到 Selenium 4用 Selenium Manager 自动管理驱动用例单独跑很快全部跑很慢存在用例间的状态污染用 pytest-xdist 并行并保证用例独立页面元素找得到但点击没反应等待条件用错改用element_to_be_clickable读取表格数据慢用了逐行逐格定位改用一次读取整个表格文本再解析6.2 排查路线图如果遇到“自动化测试页面加载慢”的问题我建议按这个步骤排查不要跳过顺序先看单次driver.get()耗时确认是不是所有页面都慢。如果都慢先排除网络和测试环境问题再考虑加载策略的调整。统计整个用例的耗时分布把启动浏览器、导航、定位元素、断言几个阶段分别打印时间定位最耗时的阶段。检查测试代码里有没有time.sleep()。这是一个信号凡是出现基本都可以改成显式等待。打开性能日志看网络请求定位是不是某个大资源拖慢了页面。从架构上考虑是不是可以并行、是否可以复用浏览器。按这个流程走下来90% 以上的“慢”都能找到明确原因并给出针对性的改进方案。6.3 独家避坑技巧耐心与取舍最后分享一个我很早就踩过、直到现在还经常有人踩的坑不要为了快而牺牲用例稳定性。有些同学把page_load_strategy改成none、又把所有等待全部删掉表面上用例跑得飞快但一旦系统响应稍慢就批量失败然后回来改等待又变得很慢。这是一个恶性循环。我个人的体会是稳定的优先级永远高于速度。优化的正确路径是先保证稳定再逐步压缩不必要的耗时而不是反过来。每个优化项加进去之后至少观察一轮完整的回归测试确认失败率没有上升再继续下一步优化。另外一个实用的小技巧是日志级别调成 DEBUG在一轮失败的用例里翻一下执行日志的时间戳很多问题一眼就能看出来。比如你发现两次定位操作之间隔了 5 秒那就意味着等待有问题如果日志显示页面加载返回后和下一次操作没有间隔说明状态已经异常了。排查慢的问题和排查功能 bug 是一样的需要数据和证据不能靠猜。还有一个我一直在用的做法给用例加上分级。冒烟测试用例坚决要求最快回归测试里相对稳定但耗时的用例单独标记出来跑批时用不同的策略执行。比如冒烟测试用eager加显式等待全套回归才用默认的normal策略做兜底。这样既保证了冒烟速度又降低了回归的风险。Selenium 自动化测试的提速没有一招鲜的办法它更像是一个持续优化的过程。每次你解决一个慢的问题你对这套工具和被测系统的理解都会加深一层。希望上面这些经验能帮你少走一些弯路把更多时间花在真正值得测的事情上。
Selenium自动化测试提速实战：从页面加载到并行执行的全面优化指南
我做了好几年的 Web 自动化测试Selenium 用得多了最常被问到的一个问题就是“脚本跑起来太慢了一个用例动不动就几分钟怎么办”确实Selenium 自动化测试跑得慢是整个行业的老大难。但很多人没搞清楚一件事慢的根源往往不是 Selenium 本身而是你在用它的时候踩了一堆隐蔽的坑。比如不合理地等待页面加载、每次用例都重新启动浏览器、元素定位写得太烂……这些问题叠加起来测试时间能被拉长 3 到 5 倍。这篇文章我就结合自己实际项目里的踩坑和优化经验把 Selenium 自动化测试网页加载慢的核心原因、定位方法和解决方案一次讲透。不管你是刚入门的测试新人还是被用例耗时折磨的资深测试都能在这里找到可以参考的思路。1. 先搞清楚你的慢到底慢在哪1.1 慢的三种常见形态我在接手团队测试框架的时候第一件事不是急着改代码而是先看用例耗时分布。因为“网页加载慢”是一个很模糊的症状背后可能是完全不同的问题。根据我观察到的实际现象大体可以分成三类第一类是单次访问页面特别慢。也就是浏览器打开一个 URL要等好几秒甚至十几秒才能完成加载。这种情况常见于被测系统的首页图片资源多、接口响应慢或者测试环境网络本身就不稳定。但这里有个容易被忽略的点Selenium 的driver.get()默认会等待页面onload事件触发。如果页面上有什么第三方统计脚本一直在加载、或者某个接口挂起不返回driver.get()就会一直等下去直到超时。很多你以为的“页面加载慢”其实是onload事件被阻塞了。第二类是定位元素等待时间过长。这类问题更普遍。比如你写了time.sleep(5)不管页面 1 秒就加载完还是 5 秒加载完它都固定等 5 秒。如果每个页面操作前都这么来一下一个用例跑下来光是死等的时间就能占到总耗时的一半以上。第三类是整体跑批时间太长。单个用例不慢但整个测试套件跑下来要一两个小时。这个往往是架构层面的问题比如用例之间没有做浏览器复用、没有开并行执行导致大量时间浪费在重复启动浏览器、加载空白页、初始化驱动这些环节上。1.2 用简单方法给“慢”做初步定位要判断到底属于哪一类不需要上什么高级工具加日志就行。我在项目里常用的做法是给关键步骤打点import time from selenium import webdriver start time.time() driver webdriver.Chrome() print(f启动浏览器耗时: {time.time() - start:.2f} 秒) start time.time() driver.get(http://your-test-site.com) print(f页面加载耗时: {time.time() - start:.2f} 秒) start time.time() element driver.find_element(By.ID, username) print(f元素定位耗时: {time.time() - start:.2f} 秒)看到分段耗时后再下结论。我见过太多人一上来就改代码结果改了半天发现瓶颈根本不是自己想的那块。另外有个经验可以分享如果一次性打开 10 个页面都慢那大概率是被测系统或网络的问题如果只有个别页面慢那可能是页面本身的资源加载问题如果每次跑脚本都比手动操作慢很多那问题就出在自动化代码的等待策略上。2. 核心优化第一步调整页面加载策略2.1 pageLoadStrategy 的三种模式Selenium 的 WebDriver 在加载页面时有一个pageLoadStrategy页面加载策略它直接决定了driver.get()要等到什么时候才算“加载完成”。默认值是normal也就是要等页面触发onload事件才返回。但很多页面根本不关心onload它的核心内容早在 DOM Ready 的时候就可以操作了。我就遇到过这样一个案例被测系统首页加载了一堆数据可视化图表图表渲染完成要好几秒但登录框这种核心元素在 DOM 加载后立即就能操作。结果自动化脚本里driver.get()硬是等了图表全部渲染完才往下走白白浪费了 5 秒多。页面加载策略提供了三种选项策略等待内容适用场景normal等待页面 onload 事件触发默认值稳定但慢eager等待 DOM 完全加载不等待样式、图片和子框架页面核心元素在 DOM 中就绪的场景none不等待任何加载事件立即返回需要完全手动控制等待的场景2.2 实际配置示例修改策略很简单在启动浏览器的时候设置即可from selenium import webdriver from selenium.webdriver.chrome.options import Options options Options() options.page_load_strategy eager # 使用 eager 策略 driver webdriver.Chrome(optionsoptions) driver.get(http://your-test-site.com)我把这个改到项目里之后首页加载时间直接从平均 8.2 秒降到了 3.1 秒提升非常明显。但这里要提醒一句换成eager之后后续的元素定位代码必须配上合理的显式等待否则很容易因为元素还没渲染出来而报找不到元素的错。你不能既想省时间又不想写等待鱼和熊掌不能兼得。对于页面元素极其简单的场景比如纯接口返回数据渲染的页面也可以用none策略然后再根据业务逻辑自己决定什么时候开始找元素。不过这个策略对脚本编写水平要求更高新手不建议直接用。3. 等待策略的重构把“死等”变成“等得准”3.1 隐式等待与显式等待的误区等待策略是自动化测试慢的“重灾区”也是优化空间最大的地方。我几乎每次帮别人排查用例慢的问题最后都能找到几处time.sleep()或者全局性的隐式等待设置。先说隐式等待implicitly_wait。它的工作机制是设置一个全局超时时间之后每次通过driver.find_element查找元素时如果元素没找到WebDriver 会在超时时间内持续轮询 DOM。这看起来挺美但坑在于隐式等待是全局性的你没法针对某个特定元素设置不同的等待时间。另外隐式等待与显式等待在某些情况下会互相干扰比如元素一直存在但处于不可点击状态时隐式等待不会帮你判断可点击性而显式等待可以做到。再说显式等待WebDriverWait。它允许你针对特定元素、特定条件设置超时时间和轮询频率这是目前推荐的写法。但很多人的用法是写time.sleep(3)代替显式等待这本质上就是把不确定性变成了固定等待页面快的时候浪费时间页面慢的时候又不够用。3.2 显式等待的正确姿势正确的做法是只等“必要条件”也就是等你要操作的那个元素出现在可交互状态。举个登录用例的例子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_element(driver, by, value, timeout10): return WebDriverWait(driver, timeout).until( EC.presence_of_element_located((by, value)) ) # 等登录按钮可点击 login_btn WebDriverWait(driver, 10).until( EC.element_to_be_clickable((By.ID, login-btn)) ) login_btn.click()这里的关键是把等待条件写对。如果你只是要元素存在用presence_of_element_located如果要操作它建议用element_to_be_clickable或者visibility_of_element_located。这两个条件的语义完全不同用错了就会出现“元素找到了但点击没反应”之类的玄学问题。3.3 自定义等待函数的实战价值比显式等待更进一步的做法是封装自定义等待函数。比如有些场景要等一个异步请求返回后页面才出现某些内容这时候标准条件就不太好使了。我在框架里通常会封装一个通用的轮询函数def wait_until(driver, condition_func, timeout15, interval0.5, description): 轮询等待自定义条件成立条件不满足时持续重试直到超时 start_time time.time() last_error None while time.time() - start_time timeout: try: if condition_func(driver): return True except Exception as e: last_error e time.sleep(interval) raise TimeoutError( f等待超时{timeout}秒: {description} (f最后错误: {last_error} if last_error else ) )这样封装之后测试代码里就完全不需要time.sleep()了。需要等什么条件就传什么条件等到就继续等不到就报超时错误报错信息还自带描述排查问题也方便。我实际改造过的项目里等请求返回的场景从固定 sleep 8 秒降到平均 1.5 秒单看一个操作可能感觉不多但整个回归套件几十个用例加起来省的时间就很可观了。4. 浏览器与网络环境层面的加速手段4.1 浏览器启动参数优化等待策略优化之后如果还是觉得慢可以看看浏览器本身能不能做减法。Chrome 启动时默认会加载一堆扩展、同步设置、自动填充等这些对自动化测试没任何用处纯属拖时间。我在项目里常用的无头加禁用参数配置是这样的options webdriver.ChromeOptions() # 无头模式运行节省资源 options.add_argument(--headlessnew) # 禁用 GPU 硬件加速 options.add_argument(--disable-gpu) # 禁用浏览器扩展 options.add_argument(--disable-extensions) # 禁用自动填充 options.add_argument(--disable-autofill) # 禁用通知弹窗 options.add_argument(--disable-notifications) # 禁止加载图片对测试无影响的场景可启用 prefs {profile.managed_default_content_settings.images: 2} options.add_experimental_option(prefs, prefs)这里重点说一下图片拦截。如果你的被测系统对图片不敏感比如后端管理后台、接口测试页面把图片加载关掉能带来很大的性能提升。有一次我在一个查询功能测试里关掉了图片加载页面加载时间直接少了 40%因为那个页面左侧挂了张很大的企业宣传图每轮操作都要重新拉一次。当然如果你测的是电商前台、设计稿这种图片敏感的场景这个配置就不能开。4.2 用性能日志定位资源瓶颈有时候页面等得久是因为有超大资源的加载。这时候可以打开 Chrome 的性能日志来看看到底是谁慢caps { goog:loggingPrefs: {performance: ALL}, goog:perfLoggingPrefs: { enableNetwork: True, enablePage: True, }, } options.set_capabilities(goog:loggingPrefs, caps) logs driver.get_log(performance) for entry in logs: message json.loads(entry[message])[message] method message[method] if method Network.responseReceived: params message[params] response params.get(response, {}) mime_type response.get(mimeType, ) url params.get(url, ) # 过滤大图片、大脚本、大样式文件 if mime_type.startswith(image/) or mime_type in (application/javascript, text/css): print(f资源加载: {response.get(status)} {url})通过日志里每个网络请求的响应时间你可以很直观地看到是哪个脚本、哪张图片拖慢了速度然后决定是前端配合优化资源还是在测试环境里用 hosts 拦截。我一般会从这条日志里挑出响应时间超过 1 秒的资源反馈给开发团队一起排查效率和自动化测试本身都能受益。4.3 本地静态资源替换加速还有一个偏门但很有效的技巧把被测页面里稳定的大静态资源比如 logo、字体文件在本地起一个代理或者直接改 hosts 映射到内网快速资源。这种操作只对测试环境有效需要开发或运维配合但效果立竿见影。做这些优化的时候一个原则要守住优化的前提是不影响测试结果的有效性。如果你的用例确实要验证图片是否展示、样式是否正常那就不能禁用图片加载。优化不是一刀切要根据具体场景灵活调整。5. 从架构层面解决并行执行与浏览器复用5.1 pytest-xdist 实现用例级并行单条脚本优化到位之后下一步就是解决整体跑批时间的问题。我最推荐的方式是使用pytest-xdist插件做用例级并行因为它对现有代码的侵入性最小配置起来非常快。pip install pytest-xdist然后在运行测试时指定并发数pytest -n 4这会启动 4 个 worker 进程每条用例会被自动分配到空闲的 worker 上执行。如果你的用例彼此没有状态依赖这是自动化测试的基本要求并行起来几乎没有成本。但并行执行有个容易踩的坑数据库测试数据冲突。比如多个 worker 同时执行“创建订单”的用例可能都会选择同一条测试数据然后互相修改导致断言失败。我的经验是要么给每条用例分配独立的数据范围比如用随机前缀要么在用例前置里动态创建干净的数据而不是依赖一个共享的固定测试数据集。另外并行的数量不是越多越好我习惯根据测试机 CPU 核数来定一般 4 到 8 个并发在普通办公机上表现最好开太多反而会因为资源竞争变慢。5.2 Selenium Grid 实现分布式执行如果单机资源有限或者需要跨浏览器兼容性测试可以考虑 Selenium Grid。它让测试用例在不同机器上分布式地启动浏览器典型架构是 1 个 Hub 管理多个 Node 节点。我这里给一个简单的 docker-compose 快速启动方案version: 3.8 services: selenium-hub: image: selenium/hub:4.15.0 container_name: selenium-hub ports: - 4444:4444 environment: - GRID_MAX_SESSION10 chrome-node: image: selenium/node-chrome:4.15.0 shm_size: 2gb depends_on: - selenium-hub environment: - SE_EVENT_BUS_HOSTselenium-hub - SE_EVENT_BUS_PUBLISH_PORT4442 - SE_EVENT_BUS_SUBSCRIBE_PORT4443启动之后脚本里指向 Hub 地址即可from selenium import webdriver from selenium.webdriver.chrome.options import Options options Options() driver webdriver.Remote( command_executorhttp://localhost:4444/wd/hub, optionsoptions )用 Selenium Grid 之后用例可以同时跑在多个浏览器实例上整个回归从 40 分钟压缩到 8 分钟以内很常见。但要注意Grid 对测试机的内存要求比较高每个 Chrome 实例大概要占 300 到 500MB 内存起 8 个并发之前先确认清楚。5.3 浏览器会话复用的思路还有一种优化思路是复用浏览器会话也就是一个测试用例跑完不关浏览器下一个用例继续用。这个在 Selenium 里原生不太好做但是可以通过debuggerAddress连接已启动的浏览器来实现# 先手动启动带调试端口的 Chrome # chrome --remote-debugging-port9222 from selenium import webdriver from selenium.webdriver.chrome.options import Options options Options() options.debugger_address localhost:9222 driver webdriver.Chrome(optionsoptions)这样连上的就是一个“真人在使用”的浏览器上下文不仅省掉了重复启动浏览器的时间还能直接操作你手动登入后的登录态处理那些和登录态耦合的用例非常方便。这个思路在调试阶段很有用CI 环境里不建议这么搞因为不稳定。6. 常见问题与排查技巧实录6.1 常见问题速查表我在优化 Selenium 测试速度的过程中积累了一批典型的“病因”和对应的“药方”整理成表分享给大家症状可能原因解决方案driver.get()长时间不返回页面 onload 被阻塞改用eager策略检查第三方脚本元素时有时无偶发失败等待策略不明确统一使用显式等待不写sleep每次启动浏览器都要好几秒驱动和浏览器版本不匹配升级到 Selenium 4用 Selenium Manager 自动管理驱动用例单独跑很快全部跑很慢存在用例间的状态污染用 pytest-xdist 并行并保证用例独立页面元素找得到但点击没反应等待条件用错改用element_to_be_clickable读取表格数据慢用了逐行逐格定位改用一次读取整个表格文本再解析6.2 排查路线图如果遇到“自动化测试页面加载慢”的问题我建议按这个步骤排查不要跳过顺序先看单次driver.get()耗时确认是不是所有页面都慢。如果都慢先排除网络和测试环境问题再考虑加载策略的调整。统计整个用例的耗时分布把启动浏览器、导航、定位元素、断言几个阶段分别打印时间定位最耗时的阶段。检查测试代码里有没有time.sleep()。这是一个信号凡是出现基本都可以改成显式等待。打开性能日志看网络请求定位是不是某个大资源拖慢了页面。从架构上考虑是不是可以并行、是否可以复用浏览器。按这个流程走下来90% 以上的“慢”都能找到明确原因并给出针对性的改进方案。6.3 独家避坑技巧耐心与取舍最后分享一个我很早就踩过、直到现在还经常有人踩的坑不要为了快而牺牲用例稳定性。有些同学把page_load_strategy改成none、又把所有等待全部删掉表面上用例跑得飞快但一旦系统响应稍慢就批量失败然后回来改等待又变得很慢。这是一个恶性循环。我个人的体会是稳定的优先级永远高于速度。优化的正确路径是先保证稳定再逐步压缩不必要的耗时而不是反过来。每个优化项加进去之后至少观察一轮完整的回归测试确认失败率没有上升再继续下一步优化。另外一个实用的小技巧是日志级别调成 DEBUG在一轮失败的用例里翻一下执行日志的时间戳很多问题一眼就能看出来。比如你发现两次定位操作之间隔了 5 秒那就意味着等待有问题如果日志显示页面加载返回后和下一次操作没有间隔说明状态已经异常了。排查慢的问题和排查功能 bug 是一样的需要数据和证据不能靠猜。还有一个我一直在用的做法给用例加上分级。冒烟测试用例坚决要求最快回归测试里相对稳定但耗时的用例单独标记出来跑批时用不同的策略执行。比如冒烟测试用eager加显式等待全套回归才用默认的normal策略做兜底。这样既保证了冒烟速度又降低了回归的风险。Selenium 自动化测试的提速没有一招鲜的办法它更像是一个持续优化的过程。每次你解决一个慢的问题你对这套工具和被测系统的理解都会加深一层。希望上面这些经验能帮你少走一些弯路把更多时间花在真正值得测的事情上。
