Selenium（Docker、Python、Behave）CI执行耗时过长的排查咨询

这问题我之前帮团队排查过类似的，核心是CI环境和本地的网络、资源、环境配置差异导致的，给你几个实操的调试方向，一步步定位慢资源：

要找出加载慢的资源，最直接的就是拿到完整的网络请求日志：

• 启用Selenium的Performance Logs：启动Chrome时配置ChromeOptions开启性能日志，代码示例：

  from selenium import webdriver
  options = webdriver.ChromeOptions()
  options.set_capability('goog:loggingPrefs', {'performance': 'ALL'})
  driver = webdriver.Chrome(options=options)
  

  在每个关键步骤（比如页面加载后、POST请求提交后），导出日志到文件：

  import json
  logs = driver.get_log('performance')
  with open('ci_performance_logs.json', 'w') as f:
      json.dump(logs, f)
  

  这些日志里包含每个请求的发起时间、耗时、状态码、资源类型，你可以筛选出耗时超过10秒的请求，重点排查静态资源（JS/CSS/图片）和目标POST接口。
• 录制HAR文件：在CI环境启动Chrome时添加参数--auto-open-devtools-for-tabs，或者通过DevTools协议主动开启网络录制，测试结束后导出HAR文件，本地用Chrome的Network面板打开，能直观看到每个请求的等待时间、下载时间，一眼就能找到卡壳的环节。

CI环境的浏览器可能因为配置或版本问题导致渲染/执行缓慢：

• 优化Chrome启动参数：添加--disable-extensions、--disable-gpu、--no-sandbox、--disable-dev-shm-usage这些参数，排除扩展、GPU加速、沙箱机制带来的额外开销；还可以加上--enable-features=NetworkService,NetworkServiceInProcess优化网络请求处理。
• 对齐浏览器版本：确认CI环境的Chrome版本和本地完全一致，有时候不同版本的V8引擎对某些JS代码的解析效率差异很大，甚至会出现阻塞性的兼容性问题。
• 检查浏览器运行状态：在CI环境测试时，用ps aux | grep chrome查看浏览器进程的资源占用，看是不是有多个进程抢占资源，或者内存占用过高导致卡顿。

很多时候慢的根源不在测试代码，而在CI环境本身：

• 监控CI代理的资源使用率：测试运行时用top（Linux）或任务管理器（Windows）查看CPU、内存、磁盘IO的占用情况，如果CPU长期跑满、内存不足，浏览器和测试进程都会卡顿。还要检查Docker容器的资源限制，是不是给的CPU核数太少（比如只分配了1核）、内存配额不足。
• 测试网络链路质量：在CI代理上直接用ping <目标域名>测延迟，用traceroute <目标域名>看网络路径是否有跳数过多或丢包的情况；针对POST接口，用curl -w "Total time: %{time_total}s\n" -X POST <接口URL> -d <请求体>单独测试接口耗时，看是不是网络本身慢，还是接口在CI环境的响应就差。
• 排查限流/防火墙：确认CI代理的IP没有被目标服务的限流策略限制，或者是否需要通过额外的代理服务器访问目标服务，这些都会导致请求被延迟处理。

有时候Selenium日志不够细，需要自己加更精准的时间戳：

• 在Behave的步骤定义中添加时间戳日志：

  from behave import given, when, then
  from datetime import datetime
  from selenium.webdriver.common.by import By
  
  @when("I submit the form")
  def step_impl(context):
      print(f"[START] Submit form at {datetime.now().isoformat()}")
      context.driver.find_element(By.ID, "submit-btn").click()
      print(f"[END] Submit form at {datetime.now().isoformat()}")
  

  通过这些日志，你能精准定位到哪几个步骤耗时最长，再针对这些步骤深入排查。
• 单独运行慢步骤：把最耗时的那个POST请求的测试用例单独拎出来在CI环境运行，看是不是每次都慢，还是因为测试用例之间的依赖（比如前序步骤占用了资源）导致的。

内容的提问来源于stack exchange，提问作者Edel WeizzX