1. 项目概述为什么我们需要一个完整的Firefox自动化测试方案如果你是一名测试工程师或者正在向自动化测试转型的开发者面对Firefox浏览器时你可能会遇到这样的场景本地脚本跑得好好的一到CI/CD流水线就报错团队里每个人的环境配置千差万别一个脚本很难在所有人的机器上稳定运行或者你只是想用Selenium写个简单的页面抓取脚本却在WebDriver版本、浏览器版本和系统环境的三角关系里折腾半天。这些问题根源往往不在于代码逻辑而在于测试环境本身——一个被很多人忽视却又至关重要的“地基”。“Firefox自动化测试与WebDriver配置完全指南”这个标题指向的正是解决这个核心痛点。它不是一个简单的“三步安装”教程而是一套从零开始构建一个稳定、可复现、可工程化部署的Firefox自动化测试环境的完整方法论。这背后涉及几个关键需求首先是环境的一致性确保开发、测试、生产或CI环境下的浏览器与驱动行为一致其次是配置的自动化避免手动下载、放置驱动文件这种低效且易错的操作最后是流程的工程化将测试环境作为代码的一部分进行管理实现一键部署和团队共享。我经历过太多因为环境问题导致的测试失败比如Firefox自动更新后WebDriver不兼容或者Linux服务器上缺少必要的图形库导致浏览器无法启动。因此这篇指南将围绕“稳定”和“可复制”两个核心带你从最基础的驱动下载与配置一直走到使用容器化技术封装测试环境并集成到现代CI/CD流程中。无论你是想为个人项目搭建一个可靠的自动化测试套件还是为团队建立标准化的测试基础设施这里的内容都能提供一条清晰的路径。2. 核心工具链解析GeckoDriver、Selenium与浏览器版本的三位一体进行Firefox自动化测试核心是处理好三个组件的关系Firefox浏览器、GeckoDriverFirefox的WebDriver实现、以及Selenium客户端库如Selenium WebDriver for Python/Java/JavaScript等。它们之间存在着严格的版本依赖和协作关系理解这个关系是避免后续无数坑的关键。2.1 GeckoDriver连接测试脚本与浏览器的桥梁GeckoDriver是一个独立的可执行文件它实现了W3C WebDriver协议。你可以把它想象成一个“翻译官”你的测试脚本用Selenium库编写发出标准化的WebDriver指令如“打开某个URL”、“点击某个元素”GeckoDriver接收这些指令并将其“翻译”成Firefox浏览器能够理解的内部协议Marionette协议从而驱动浏览器执行相应操作。关键点与避坑指南版本匹配是重中之重GeckoDriver的版本必须与Firefox浏览器的版本大致兼容。通常较新版本的GeckoDriver支持一个范围内的Firefox版本。最稳妥的方式是查阅Mozilla官方GitHub仓库的发布说明。一个常见的误区是认为版本号必须完全一致实际上更需要关注的是兼容性列表。下载与放置你需要从官方仓库下载对应你操作系统的GeckoDriver。下载后需要将其放在系统PATH环境变量包含的目录下如/usr/local/binon Linux/macOS或添加到Windows的系统环境变量或者在你的测试脚本中显式指定其路径。前者更方便后者更利于项目级别的环境控制。Headless模式支持现代GeckoDriver完美支持无头模式-headless这对于在服务器等没有图形界面的环境中运行测试至关重要。在代码中通过options.add_argument(‘-headless’)来启用。2.2 Selenium Client Library你的测试脚本编写工具Selenium提供了多种语言的客户端库Python的selenium包Java的selenium-java依赖等。这是你实际编写测试代码的接口。它的版本主要影响你可用的API特性与GeckoDriver和浏览器版本的耦合度相对较低但使用较新的客户端库通常能获得更好的稳定性和功能支持。实操心得我强烈建议使用虚拟环境Python的venv或依赖管理工具Java的Maven/GradleNode.js的npm来管理Selenium客户端库的版本。这能有效隔离不同项目间的依赖避免冲突。例如在Python项目中# 创建并激活虚拟环境 python -m venv .venv source .venv/bin/activate # Linux/macOS # .venv\Scripts\activate # Windows # 安装Selenium pip install selenium2.3 Firefox浏览器被测对象本身Firefox本身有两个版本线需要留意常规的Release版本和ESRExtended Support Release延长支持版。对于自动化测试尤其是企业级CI环境使用ESR版本通常是更明智的选择。ESR版本更新周期长大约一年一个主版本安全更新和关键修复会持续提供但功能更新频率低这带来了极高的稳定性非常适合作为自动化测试的基准环境。配置建议禁用自动更新在自动化测试环境中浏览器版本必须固定。你可以在Firefox的配置页面about:preferences或通过启动参数来禁用自动更新。使用独立安装/便携版不要在CI服务器上使用系统自带的或可能被其他进程更新的Firefox。应该下载特定版本的二进制包将其安装或解压到项目目录下并在测试代码中指向这个独立路径。这实现了环境的完全自包含。配置文件管理Firefox的用户配置文件Profile包含了扩展、书签、缓存等。在自动化测试中我们通常需要创建一个全新的、干净的配置文件或者使用特定的配置来禁用一些可能干扰测试的功能如弹出窗口阻止、密码保存提示等。Selenium WebDriver允许你在启动时指定一个自定义的配置文件路径或配置选项。三者协同工作流程你的测试脚本使用Selenium库启动 → 脚本通过WebDriver协议向localhost上的某个端口发送指令 → GeckoDriver进程在该端口监听收到指令后启动或连接一个Firefox实例使用指定的配置文件 → GeckoDriver将指令转换为Marionette协议与Firefox内部通信 → Firefox执行操作并将结果通过GeckoDriver返回给测试脚本。3. 从零开始跨平台环境搭建实战理论清晰后我们进入实战环节。我将分别演示在Windows、macOS和Linux以Ubuntu为例上如何一步步搭建一个最小化、可用的Firefox自动化测试环境。我们的目标是安装指定版本的Firefox配置匹配的GeckoDriver并编写一个简单的验证脚本。3.1 Windows平台搭建步骤Windows环境由于图形化操作普及手动搭建相对直观但自动化部署时需要特别注意路径和权限。步骤一安装固定版本的Firefox访问Mozilla FTP服务器例如https://ftp.mozilla.org/pub/firefox/releases/找到你需要的版本号如115.0.3/和系统架构win64/。下载Firefox Setup XXXX.exe安装程序。但更推荐下载win64/zh-CN/Firefox Setup XXXX.exe这样的完整安装包避免在线下载。运行安装程序。为了便于管理可以安装到非系统盘的自定义目录例如D:\AutomationTools\Firefox\。记录下安装路径如D:\AutomationTools\Firefox\firefox.exe。步骤二下载并配置GeckoDriver访问GeckoDriver的GitHub发布页。下载对应版本的geckodriver-vX.XX.X-win64.zip。解压ZIP文件你会得到一个geckodriver.exe文件。将其放置在一个目录下有两种推荐方案方案A加入PATH将geckodriver.exe复制到C:\Windows\或C:\Windows\System32\需要管理员权限这样系统任何位置都能找到它。方案B项目内管理在项目根目录创建一个drivers/文件夹将geckodriver.exe放进去。然后在代码中指定绝对路径。这种方式更利于项目隔离和版本控制。步骤三编写验证脚本Python示例创建一个test_firefox.py文件from selenium import webdriver from selenium.webdriver.firefox.service import Service from selenium.webdriver.firefox.options import Options import os # 1. 配置路径使用方案B firefox_binary_path r”D:\AutomationTools\Firefox\firefox.exe” geckodriver_path os.path.join(os.getcwd(), “drivers”, “geckodriver.exe”) # 2. 设置浏览器选项 options Options() options.binary_location firefox_binary_path # 指定Firefox可执行文件路径 # options.add_argument(“-headless”) # 如需无头模式取消注释 # 3. 创建WebDriver服务并指定GeckoDriver路径 service Service(executable_pathgeckodriver_path) # 4. 启动浏览器 driver webdriver.Firefox(serviceservice, optionsoptions) try: # 执行测试操作 driver.get(“https://www.baidu.com”) print(“页面标题”, driver.title) # 进行一些断言或操作... input(“按回车键关闭浏览器...”) finally: # 确保关闭浏览器 driver.quit()运行此脚本如果能看到Firefox浏览器打开并访问百度且控制台打印出标题则说明环境配置成功。3.2 macOS/Linux平台搭建步骤在类Unix系统上我们更倾向于使用包管理器或脚本进行自动化安装。步骤一安装固定版本的FirefoxmacOS可以从Mozilla FTP下载.dmg包手动安装或者使用Homebrew安装特定版本brew install firefox115但需注意brew的版本更新策略。对于自动化环境手动下载并安装到/Applications或自定义目录更可控。Linux (Ubuntu/Debian)卸载可能存在的snap版本Firefoxsudo snap remove firefox。从Mozilla FTP下载.tar.bz2压缩包例如firefox-115.0.3.tar.bz2。解压到目标目录sudo tar -xjf firefox-*.tar.bz2 -C /opt/。这样Firefox就安装在/opt/firefox/目录下。可以创建一个软链接方便全局调用sudo ln -s /opt/firefox/firefox /usr/local/bin/firefox。步骤二下载并配置GeckoDriver根据系统下载对应的GeckoDriverLinux 64位通常为geckodriver-vX.XX.X-linux64.tar.gz macOS为geckodriver-vX.XX.X-macos.tar.gz。解压tar -xzf geckodriver-*.tar.gz。将其移动到系统PATH目录sudo mv geckodriver /usr/local/bin/。或者放到项目目录下。赋予执行权限sudo chmod x /usr/local/bin/geckodriver。步骤三Linux无头模式额外依赖在无图形界面的Linux服务器上运行Firefox可能需要安装一些额外的库来模拟图形环境。一个常见的错误是Cannot find libgtk-3.so.0或类似缺失库的错误。# Ubuntu/Debian 系统 sudo apt-get update sudo apt-get install -y libgtk-3-0 libdbus-glib-1-2 libxt6 xvfb # CentOS/RHEL 系统 sudo yum install -y gtk3 dbus-glib libXt xorg-x11-server-XvfbXvfbX Virtual Framebuffer是一个虚拟显示服务器允许你在没有物理显示器的环境下运行图形程序。你可以通过xvfb-run命令来启动你的测试脚本xvfb-run --auto-servernum --server-args“-screen 0 1920x1080x24” python test_firefox.py。验证脚本Linux/macOS通用 脚本与Windows版类似只需修改路径。在Linux上如果Firefox安装在/opt/firefox/firefox且GeckoDriver已在PATH中代码可以简化为from selenium import webdriver from selenium.webdriver.firefox.options import Options options Options() # options.binary_location “/opt/firefox/firefox” # 如果未在PATH需指定 options.add_argument(“-headless”) # Linux服务器通常启用无头模式 driver webdriver.Firefox(optionsoptions) # 如果geckodriver在PATH无需指定service try: driver.get(“https://www.baidu.com”) print(“页面标题”, driver.title) assert “百度” in driver.title finally: driver.quit()4. 工程化实践将环境配置提升到团队级标准个人环境搭建只是第一步。要让自动化测试在团队协作和持续集成中可靠运行必须进行工程化改造。核心思想是将环境依赖固化并通过代码或配置进行管理实现一键部署和一致性保障。4.1 使用Docker容器化测试环境Docker是解决“在我机器上能跑”问题的终极方案之一。我们将Firefox、GeckoDriver、测试运行时如Python及其依赖打包成一个镜像。创建Dockerfile示例# 使用一个轻量级的基础镜像例如带有Python的Alpine Linux FROM python:3.11-alpine # 安装系统依赖包括Firefox运行所需的库 RUN apk add --no-cache \ firefox-esr \ dbus-glib \ ttf-freefont \ xvfb \ wait4ports \ # 清理缓存以减小镜像体积 rm -rf /var/cache/apk/* # 安装GeckoDriver # 可以从官方URL下载注意版本匹配。这里以一个特定版本为例实际应使用变量或固定稳定版本。 ENV GECKODRIVER_VERSION v0.34.0 RUN wget -q “https://github.com/mozilla/geckodriver/releases/download/${GECKODRIVER_VERSION}/geckodriver-${GECKODRIVER_VERSION}-linux64.tar.gz” \ tar -xzf geckodriver-*.tar.gz -C /usr/local/bin \ rm geckodriver-*.tar.gz \ chmod x /usr/local/bin/geckodriver # 验证安装 RUN firefox --version geckodriver --version # 设置工作目录并复制测试代码和依赖 WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . # 默认命令使用xvfb-run来启动无头测试 CMD [“xvfb-run”, “–auto-servernum”, “–server-args-screen 0 1920x1080x24”, “pytest”, “-v”]requirements.txt内容selenium4.10.0 pytest7.0.0工程化优势一致性所有团队成员和CI服务器都使用完全相同的镜像彻底杜绝环境差异。可移植性镜像可以上传到仓库如Docker Hub、私有Harbor在任何支持Docker的地方拉取运行。隔离性测试运行在独立的容器中不会污染宿主机环境测试结束后容器销毁环境干净如初。版本控制Dockerfile和requirements.txt可以纳入代码仓库环境变更历史清晰可查。4.2 集成到CI/CD流水线以GitHub Actions为例将容器化或脚本化的测试环境集成到CI/CD中实现代码提交后自动运行测试。GitHub Actions工作流示例 (.github/workflows/firefox-test.yml)name: Firefox UI Automation Tests on: [push, pull_request] jobs: test: runs-on: ubuntu-latest container: # 使用你自己构建的包含Firefox和依赖的Docker镜像或使用社区维护的镜像 image: selenium/standalone-firefox:latest # 如果使用自定义镜像替换为你的镜像名如 myorg/firefox-test-env:115-esr options: –shm-size2g # 增加共享内存防止浏览器崩溃 steps: - name: Checkout code uses: actions/checkoutv4 - name: Install Python dependencies run: | python -m pip install –upgrade pip pip install -r requirements.txt - name: Run tests run: | # 在容器内浏览器和驱动已就绪。我们连接到容器内的Selenium Standalone服务。 # 如果你的测试脚本是直接启动浏览器则需要使用包含浏览器和驱动的镜像并直接运行pytest。 # 这里假设我们使用了一个包含完整环境的自定义镜像并直接运行测试。 pytest tests/ –headless –htmlreport.html –self-contained-html - name: Upload test report uses: actions/upload-artifactv4 if: always() # 即使测试失败也上传报告 with: name: test-report path: report.html关键配置解析container指定任务在特定容器中运行这是保证环境一致性的关键。options: –shm-size2gDocker容器默认的共享内存较小可能导致Firefox崩溃。增加shm-size是解决此类问题的标准做法。步骤中的Run tests这里直接运行pytest。因为我们使用的镜像无论是自定义的还是selenium/standalone-firefox已经包含了运行环境。如果使用selenium/standalone-firefox你的测试脚本需要以远程模式Remote WebDriver连接到http://localhost:4444。4.3 使用WebDriver Manager进行自动化驱动管理对于非容器化环境或者希望简化本地开发配置可以使用像webdriver-managerPython或WebDriverManagerJava这样的第三方库。它们能自动检测浏览器版本并下载、配置匹配的WebDriver。Python示例使用webdriver-managerfrom selenium import webdriver from selenium.webdriver.firefox.service import Service as FirefoxService from webdriver_manager.firefox import GeckoDriverManager from selenium.webdriver.firefox.options import Options options Options() # options.add_argument(“-headless”) # 关键GeckoDriverManager().install() 会自动下载和管理驱动 service FirefoxService(GeckoDriverManager().install()) driver webdriver.Firefox(serviceservice, optionsoptions) driver.get(“https://www.baidu.com”) print(driver.title) driver.quit()优势与注意事项优势极大简化了环境准备流程开发者无需手动下载和放置驱动。库会自动处理版本兼容性问题。注意事项在CI/CD环境中由于每次都会尝试下载驱动可能会受到网络因素影响。通常建议在CI环境中缓存下载的驱动或者直接使用固定版本的驱动以提升构建速度和稳定性。对于追求极致稳定和构建速度的生产级CI直接使用预装好驱动的容器镜像仍是更优选择。5. 高级配置与最佳实践打造稳定高效的测试套件基础环境搭好工程化框架建完接下来就是打磨细节让你的自动化测试运行得更稳定、更快速、更健壮。5.1 Firefox配置优化选项通过Options对象我们可以对Firefox实例进行深度定制以适配自动化测试的需求。from selenium.webdriver.firefox.options import Options options Options() # 1. 无头模式服务器环境必备 options.add_argument(“-headless”) # 2. 禁用GPU加速在虚拟化或无头环境中GPU加速可能导致问题 options.add_argument(“–disable-gpu”) # 3. 禁用沙箱在某些Linux配置下可能需要禁用沙箱以解决启动问题安全考虑仅在必要时使用 # options.add_argument(“–no-sandbox”) # 通常Chrome需要Firefox较少需要但某些容器环境可能需要 options.add_argument(“–disable-dev-shm-usage”) # 使用/dev/shm替代/tmp解决共享内存不足问题 # 4. 设置初始窗口大小 options.add_argument(“–width1920”) options.add_argument(“–height1080”) # 5. 设置自定义用户配置文件Prefs # 你可以设置about:config中的各种偏好设置 options.set_preference(“browser.download.folderList”, 2) # 下载到指定目录 options.set_preference(“browser.download.dir”, “/tmp/downloads”) options.set_preference(“browser.helperApps.neverAsk.saveToDisk”, “application/pdf”) options.set_preference(“pdfjs.disabled”, True) # 禁用Firefox内置PDF查看器 # 6. 禁用自动化控制栏提示“Firefox正受到自动化测试软件控制” options.set_preference(“dom.webdriver.enabled”, False) options.set_preference(“useAutomationExtension”, False) # 注意修改这些指纹属性可能用于绕过简单的反爬但应遵守网站服务条款。 # 7. 日志级别控制 options.log.level “trace” # 可选 “debug”, “info”, “warn”, “error”实操心得不是所有选项都越多越好。例如在资源受限的CI环境中–disable-gpu和–disable-dev-shm-usage非常有用。而偏好设置则需要根据测试场景仔细挑选比如测试文件下载功能时必须正确配置下载路径和MIME类型。5.2 等待策略告别time.sleep的智慧不稳定的测试用例十有八九是等待问题。硬编码的time.sleep是万恶之源。隐式等待 (Implicit Wait)driver.implicitly_wait(10)。设置一个全局的超时时间在查找任何元素时如果元素没有立即出现WebDriver会轮询DOM直到找到它或超时。缺点它只对find_element这类查找操作有效对元素的状态如可点击、可见无效。并且一旦设置对整个driver生命周期都有效可能在某些不需要等待的场景造成不必要的延迟。显式等待 (Explicit Wait)这是推荐的最佳实践。它为某个特定条件设置等待。from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from selenium.webdriver.common.by import By # 等待最多10秒直到ID为’submit-btn‘的元素可被点击 element WebDriverWait(driver, 10).until( EC.element_to_be_clickable((By.ID, “submit-btn”)) ) element.click()expected_conditions模块提供了丰富的条件如presence_of_element_located元素出现在DOM、visibility_of_element_located元素可见、text_to_be_present_in_element元素包含特定文本等。固定等待仅在极少数情况下使用例如等待一个非Web的动画或后端处理完成且没有更好的检测手段时。即使如此也应尽量使用WebDriverWait配合自定义条件。最佳实践组合通常我会设置一个较短的全局隐式等待如5秒作为后备然后在所有关键交互步骤点击、输入、获取文本前使用针对性的显式等待。这既保证了代码的健壮性又避免了不必要的全局延迟。5.3 页面对象模型Page Object Model, POM设计模式当测试用例越来越多时直接在测试脚本中编写查找元素和操作的代码会导致大量重复且一旦页面结构变化维护成本极高。POM模式将每个页面封装成一个类页面的元素定位器和基本操作作为类的方法测试用例则通过调用这些页面对象的方法来完成操作。示例登录页面的Page Object# pages/login_page.py from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC class LoginPage: def __init__(self, driver): self.driver driver self.wait WebDriverWait(driver, 10) # 定位器 USERNAME_INPUT (By.ID, “username”) PASSWORD_INPUT (By.ID, “password”) LOGIN_BUTTON (By.CSS_SELECTOR, “button[type‘submit’]”) ERROR_MESSAGE (By.CLASS_NAME, “alert-error”) # 页面操作方法 def enter_username(self, username): element self.wait.until(EC.visibility_of_element_located(self.USERNAME_INPUT)) element.clear() element.send_keys(username) return self def enter_password(self, password): self.driver.find_element(*self.PASSWORD_INPUT).send_keys(password) return self def click_login(self): self.wait.until(EC.element_to_be_clickable(self.LOGIN_BUTTON)).click() return self def get_error_message(self): try: return self.driver.find_element(*self.ERROR_MESSAGE).text except: return None # 在测试用例中使用 # test_login.py def test_invalid_login(driver): login_page LoginPage(driver) login_page.enter_username(“wrong”) login_page.enter_password(“wrong”) login_page.click_login() assert “Invalid credentials” in login_page.get_error_message()POM的优势高可维护性页面元素定位器集中管理页面结构变更只需修改一个地方。高可读性测试用例读起来像自然语言业务逻辑清晰。低冗余页面操作被封装复用避免代码重复。便于协作页面对象和测试用例可以由不同角色分工完成。6. 常见问题排查与调试技巧实录即使准备万全在实际运行中仍会遇到各种问题。这里记录了一些我踩过的坑和对应的解决方案。6.1 浏览器启动失败或驱动连接问题问题WebDriverException: Message: Process unexpectedly closed with status: 255或Unable to find a matching set of capabilities。排查版本不匹配这是最常见原因。用firefox –version和geckodriver –version检查版本。去GeckoDriver发布页面查看兼容的Firefox版本范围。路径错误检查binary_location选项指定的Firefox路径是否正确以及geckodriver是否在PATH中或Service路径指定正确。权限问题在Linux/macOS上确保geckodriver有执行权限chmod x。端口占用GeckoDriver默认使用端口4444。确保没有其他GeckoDriver或Selenium Standalone实例在运行。Firefox正在运行如果已有Firefox进程可能造成冲突。尝试在启动选项中加入options.add_argument(“-new-instance”)来启动一个新实例。6.2 元素找不到NoSuchElementException问题脚本报错NoSuchElementException: Unable to locate element。排查等待不足这是首要原因。确保在查找元素前使用了合适的显式等待WebDriverWait而不是依赖隐式等待或没有等待。定位器错误页面结构可能已更改。使用浏览器的开发者工具F12重新检查元素的选择器。优先使用ID、name等稳定属性其次才是XPath或CSS Selector。注意XPath是否依赖于可能变化的索引。iframe/Shadow DOM如果元素位于iframe或Shadow DOM内部需要先切换到对应的上下文。# 切换到iframe iframe driver.find_element(By.TAG_NAME, “iframe”) driver.switch_to.frame(iframe) # 操作iframe内的元素… driver.switch_to.default_content() # 操作完切回来页面未加载完全在driver.get(url)后添加一个等待页面关键元素如body标签或某个标志性元素出现的等待。6.3 性能问题与超时问题测试运行缓慢经常因超时而失败。优化启用无头模式无头模式-headless省去了渲染图形界面的开销速度显著提升。调整等待超时时间根据网络和服务器响应情况合理设置显式等待的超时时间如从10秒减至5秒。设置一个合理的全局隐式等待如2-3秒。复用浏览器实例对于一组相关的测试用例可以考虑复用同一个driver实例而不是每个用例都重启浏览器。但要注意用例间的状态隔离清理cookies、localStorage。禁用不必要的加载通过options.set_preference禁用图片、CSS、WebFonts加载可以极大提速但仅适用于不依赖样式的功能测试。options.set_preference(“permissions.default.image”, 2) # 2阻止 options.set_preference(“permissions.default.stylesheet”, 2)检查网络与资源慢可能是测试环境网络或被测应用服务器本身的问题。6.4 在CI/CD中的稳定性问题问题测试在本地通过但在CI服务器上随机失败。加固使用容器如前所述使用Docker镜像确保环境绝对一致。增加–shm-size这是Docker运行Firefox/Chrome的经典问题。在docker run命令或Compose文件或CI配置中务必增加共享内存大小例如–shm-size2g。使用xvfb对于非容器化的Linux CI环境确保安装了xvfb并用xvfb-run包装测试命令。截图与日志在测试失败时自动截屏和保存页面源码、浏览器日志这是定位CI上问题的生命线。Pytest等框架有相应的钩子函数可以实现。# 在teardown或异常处理中 driver.save_screenshot(“failure_screenshot.png”) with open(“page_source.html”, “w”, encoding“utf-8”) as f: f.write(driver.page_source) for entry in driver.get_log(“browser”): print(entry)重试机制对于不稳定的测试步骤如网络请求可以实现简单的重试逻辑。或者使用pytest的插件如pytest-rerunfailures对失败的测试用例进行自动重试。6.5 浏览器被检测为自动化工具问题某些网站会检测navigator.webdriver属性如果为true则判定为自动化浏览器并阻止访问。应对需谨慎遵守网站规则使用undetected-chromedriver针对Chrome对于Firefox社区也有类似尝试但不如Chrome成熟。修改指纹通过options.set_preference(“dom.webdriver.enabled”, False)可以隐藏最基本的WebDriver标识。但更高级的检测可能需要修改更多JavaScript暴露的属性这涉及到与反检测技术的对抗且可能违反服务条款。根本之道对于重要的生产环境测试应尽量与开发团队沟通为测试环境配置白名单或提供专门的测试模式避免触发反自动化机制。对于爬虫等场景则应严格遵守robots.txt和服务条款。