1. 项目概述：为什么下载目录配置是个“难题”？

做自动化测试的朋友，尤其是用SeleniumBase的，估计都遇到过这个场景：脚本跑得好好的，突然需要下载一个文件——可能是测试报告、导出的数据，或者是页面生成的PDF。然后问题就来了，文件下到哪里去了？怎么指定路径？怎么确保每次下载的文件名不冲突，还能被后续的脚本正确读取？这看似简单的一个“下载目录配置”，在实际项目中，尤其是持续集成（CI/CD）环境下，往往能卡住不少人，变成一个不大不小的“难题”。

我刚开始用SeleniumBase做Web自动化时，也在这个问题上栽过跟头。默认情况下，浏览器下载的文件会跑到系统的“下载”文件夹里。在本地单次运行或许没问题，但一旦放到服务器上跑自动化流水线，问题就全暴露了：权限不足导致下载失败、多任务并行时文件互相覆盖、CI环境找不到下载路径导致断言失败……这些坑我都踩过。所以，今天我们就来彻底拆解这个“难题”，把SeleniumBase中配置下载目录的几种方法、背后的原理、以及如何适配不同场景，一次讲清楚。无论你是刚接触自动化测试的新手，还是正在搭建测试框架的老鸟，这篇从实战中总结的配置指南，应该都能帮你省下不少排查的时间。

2. 核心需求解析：我们到底需要什么样的下载行为？

在动手配置之前，我们得先想明白，一个健壮的自动化测试脚本，对文件下载行为有哪些核心要求？这决定了我们选择哪种配置策略。

2.1 确定性路径管理

这是最基本也是最重要的需求。脚本必须明确知道文件下载到了哪个目录。不能是模糊的“系统下载文件夹”，而应该是一个脚本可预测、可访问的绝对路径。在CI/CD环境中，这个路径通常是一个临时工作空间或者指定的制品目录，方便后续步骤（如文件校验、上传到存储服务器）进行处理。

2.2 会话隔离与并发安全

当多个测试用例并行执行，或者同一个用例被反复执行时，必须避免下载的文件互相覆盖。理想情况下，每次测试会话（甚至每个测试用例）都应该有自己独立的下载目录。这不仅能防止数据污染，也便于追踪和归档每次运行产生的文件。

2.3 浏览器兼容性与无头模式支持

我们的配置方案需要在不同的浏览器（Chrome, Firefox, Edge等）上一致地工作。特别是在无头（Headless）模式下，浏览器没有可见的UI，传统的“另存为”对话框不会弹出，所有下载行为都必须通过预设的配置来静默完成。方案必须兼容这种模式。

2.4 清理与资源管理

自动化测试可能会产生大量临时下载文件。一个好的实践是，在测试开始前清理旧的下载目录，在测试结束后（或成功断言后）有选择地清理本次下载的文件，避免磁盘空间被无用文件占满。这需要在配置中考虑目录的初始化逻辑。

2.5 配置的灵活性与可维护性

下载路径最好不要硬编码在测试脚本里。它应该可以通过配置文件（如pytest.ini,conftest.py）、环境变量或者命令行参数进行灵活指定。这样，同一套脚本可以在开发者的本地机器、测试环境和生产CI服务器上无缝运行，只需改变配置即可。

3. 方案选型：SeleniumBase提供的几种配置之道

SeleniumBase本身提供了多种方式来配置浏览器选项，自然也包括下载目录。我们需要根据不同的测试框架使用方式（pytest, unittest）和场景复杂度来选择。

3.1 方案一：通过browser_options在测试类中直接配置

这是最直接、最常见的方式，适合在单个测试类或脚本中定义下载行为。

核心原理：SeleniumBase的BaseCase类（或TestCase类）在初始化浏览器驱动时，会读取browser_options属性。我们可以通过覆写这个属性，向其中添加特定的Chrome选项（prefs）或Firefox选项（profile.set_preference）来指定下载路径和行为。

示例代码（Chrome）：

import os from seleniumbase import BaseCase class FileDownloadTest(BaseCase): def setUp(self): # 在setUp中动态创建本次测试专用的下载目录 self.download_dir = os.path.join(os.getcwd(), “downloads”, self.id()) os.makedirs(self.download_dir, exist_ok=True) # 配置浏览器选项 chrome_options = self.get_driver_options() # 获取默认选项 prefs = { “download.default_directory”: self.download_dir, “download.prompt_for_download”: False, # 禁止弹出下载提示框 “download.directory_upgrade”: True, “safebrowsing.enabled”: True # 某些情况下需要关闭安全浏览以加速下载 } chrome_options.add_experimental_option(“prefs”, prefs) # 将配置好的选项赋给实例 self.browser_options = chrome_options super().setUp() # 调用父类setUp，此时会使用我们配置的browser_options def test_download_file(self): self.open(“https://example.com/download”) self.click(“a#download-link”) # 等待文件下载完成 self.wait_for_downloads(timeout=30) # 断言文件存在 expected_file = os.path.join(self.download_dir, “example.pdf”) self.assert_downloaded_file(expected_file) def tearDown(self): # 可选：测试结束后清理下载的文件 import shutil if os.path.exists(self.download_dir): shutil.rmtree(self.download_dir) super().tearDown()

为什么这么选？

1. download.prompt_for_download: False：这是关键。设为False后，浏览器遇到可下载资源时会直接静默下载到指定目录，而不会弹出询问框，这对于自动化至关重要。
2. download.directory_upgrade: True：确保浏览器使用我们提供的目录，而不是用户之前的默认设置。
3. 动态路径self.id()：使用测试用例的ID（通常是类名+方法名）作为子目录名，完美实现了“会话隔离”，不同测试用例的文件不会混在一起。
4. 在setUp中配置：确保每个测试方法执行前，浏览器都带着正确的配置启动。

注意：对于Firefox，配置方式略有不同，需要使用profile.set_preference。如果你需要做跨浏览器测试，最好将浏览器选项的配置逻辑抽象成一个单独的方法，根据self.browser的值来分支处理。

3.2 方案二：使用--downloads-folder命令行参数（pytest）

如果你使用pytest作为测试运行器，SeleniumBase提供了一个非常方便的命令行参数。

操作方法： 在运行pytest命令时直接指定：

pytest my_test_file.py --browser=chrome --downloads-folder=”./my_downloads”

内部机制：当SeleniumBase的pytest插件检测到--downloads-folder参数时，它会在后台自动为你配置所有通过sbfixture启动的浏览器的下载首选项，将其指向你提供的文件夹。你无需在测试代码中写任何关于download.default_directory的配置。

优点：

• 极其简单：无需修改代码，一行命令搞定。
• 全局生效：对该次运行的所有测试用例都有效。
• 易于集成CI：在CI的脚本命令中直接添加此参数即可。

局限性：

• 固定路径：所有测试用例的下载文件都会放在同一个文件夹里，如果多个用例下载同名文件，会发生覆盖。你需要确保用例间没有文件名冲突，或者用例本身包含了清理逻辑。
• 依赖运行器：只在使用pytest且通过SeleniumBase的插件启动浏览器时才有效。如果你直接实例化BaseCase并调用其方法，此参数无效。

3.3 方案三：通过环境变量或配置文件进行外部化配置

这是追求配置灵活性和环境隔离时的最佳实践。将下载路径定义在环境变量或配置文件中，测试脚本运行时去读取。

示例（使用环境变量）：

1. 在CI/CD管道或本地Shell中设置环境变量：

   export SELENIUMBASE_DOWNLOAD_DIR=”/tmp/ci_downloads_${BUILD_ID}”

2. 在测试代码中读取：

   import os from seleniumbase import BaseCase class ConfigDrivenTest(BaseCase): @classmethod def setUpClass(cls): # 从环境变量读取，如果不存在则使用一个默认的fallback路径 cls.download_base = os.getenv(“SELENIUMBASE_DOWNLOAD_DIR”, “./fallback_downloads”) super().setUpClass() def setUp(self): # 为每个测试方法创建子目录 self.test_download_dir = os.path.join(self.download_base, self._testMethodName) os.makedirs(self.test_download_dir, exist_ok=True) chrome_options = self.get_driver_options() prefs = {“download.default_directory”: self.test_download_dir, …} chrome_options.add_experimental_option(“prefs”, prefs) self.browser_options = chrome_options super().setUp()

示例（使用pytest.ini或conftest.py）： 你可以在conftest.py中定义一个pytest fixture来提供下载目录路径，所有测试用例都可以注入这个fixture。

# conftest.py import os import pytest @pytest.fixture(scope=”session”) def download_base_dir(tmp_path_factory): """返回一个会话级别的临时下载基目录""" return tmp_path_factory.mktemp(“downloads”) @pytest.fixture def download_dir(download_base_dir, request): """为每个测试用例返回一个独立的子目录""" test_dir = download_base_dir / request.node.name test_dir.mkdir(exist_ok=True) return str(test_dir) # 转换为字符串路径

然后在测试用例中使用：

# test_file.py def test_with_fixture(sb, download_dir): # sb fixture来自SeleniumBase， download_dir来自我们自定义的fixture chrome_options = sb.get_driver_options() prefs = {“download.default_directory”: download_dir, …} chrome_options.add_experimental_option(“prefs”, prefs) # 如何将options传递给sb？这需要一些技巧，通常需要自定义一个fixture来包装sb # 更简单的方式是，如果使用BaseCase风格，可以在类里通过request fixture获取download_dir

方案选型小结：

• 快速原型或简单项目：使用方案一（代码内配置），直观可控。
• 使用pytest且希望最小化代码改动：优先尝试方案二（命令行参数），最省事。
• 企业级项目、多环境部署、CI/CD集成：强烈推荐方案三（外部化配置），它将配置与代码分离，维护性和灵活性最好。

4. 实战配置详解与避坑指南

光知道方法不够，我们得把每个步骤掰开揉碎，把里面容易踩的坑都标出来。

4.1 Chrome浏览器完整配置清单与参数解读

下面是一个在生产环境中经过验证的、较为完整的Chrome下载配置字典。每个参数都有其作用。

def get_chrome_download_prefs(download_path): “”” 返回针对指定下载路径的完整Chrome偏好设置。 “”” return { “download.default_directory”: download_path, # 核心：设置默认目录 “download.prompt_for_download”: False, # 核心：禁用下载提示框 “download.directory_upgrade”: True, # 始终使用指定目录，不询问 “safebrowsing.enabled”: False, # **重要**：关闭安全浏览。安全浏览会检查文件，可能导致大文件下载延迟或失败。 “profile.default_content_settings.popups”: 0, # 禁止弹出窗口，某些下载由弹出窗口触发 “profile.default_content_settings.geolocation”: 2, # 禁用地理位置，避免无关弹窗 “credentials_enable_service”: False, # 禁用密码保存提示 “password_manager_enabled”: False, # 禁用密码管理器 }

关键参数深度解析：

• safebrowsing.enabled: False：这是个大坑！Chrome的安全浏览功能会对下载的文件进行安全检查，对于自动化测试来说，这常常会导致下载状态迟迟不完成（特别是大文件），或者在某些网络环境下直接失败。在受控的测试环境中，关闭它是安全且推荐的。但请注意：如果你的测试场景需要模拟真实用户环境且安全策略严格，则可能需要将其保持为True，并接受由此带来的潜在延迟。
• profile.default_content_settings.popups: 0：有些网站的下载链接是通过JavaScript在新窗口或新标签页中触发的。禁止弹窗可以确保下载行为在主页面上下文中完成，更易于自动化控制。

4.2 处理文件下载完成等待

配置好目录只是第一步。点击下载链接后，脚本必须等待文件真正下载完成，才能进行后续的读取或断言。SeleniumBase提供了wait_for_downloads()方法，但其原理需要理解。

wait_for_downloads()的工作原理： 该方法会轮询指定的下载目录（默认是Chrome配置的目录），检查是否存在以.crdownload为扩展名的临时文件。Chrome在下载过程中会先创建filename.crdownload，下载完成后才重命名为最终的文件名。该方法等待所有.crdownload文件消失。

使用技巧与陷阱：

self.click(“#download-btn”) # 等待最多30秒，直到下载目录中没有.crdownload文件 self.wait_for_downloads(timeout=30) # 陷阱1：超时时间不足 # 如果文件很大或网速慢，30秒可能不够。需要根据文件大小合理设置timeout，或者使用动态超时。 # 陷阱2：并行下载多个文件 # wait_for_downloads() 会等待**所有**进行中的下载完成。如果你连续触发多个下载，它需要等最后一个完成才行。 # 最佳实践：结合明确的目标文件名进行等待 import time def wait_for_specific_file(directory, filename, timeout=30): “””等待特定文件出现且不再有.crdownload临时文件””” end_time = time.time() + timeout final_path = os.path.join(directory, filename) temp_pattern = f”{filename}.crdownload” while time.time() < end_time: # 检查临时文件是否还存在 temp_files = [f for f in os.listdir(directory) if f.endswith(‘.crdownload’)] if not temp_files and os.path.exists(final_path): return True time.sleep(0.5) return False # 在测试中使用 self.click(“#download-btn”) assert wait_for_specific_file(self.download_dir, “report.pdf”), “文件下载失败或超时”

4.3 无头模式下的特殊考量

在无头模式下运行，所有配置依然有效。但有几个额外要点：

1. 路径必须绝对路径：在无头模式下，使用相对路径（如”./downloads”）更容易出问题。最好使用os.path.abspath()转换为绝对路径。

   download_path = os.path.abspath(“./downloads”)

2. 权限问题：CI服务器上的用户（如jenkins,gitlab-runner）可能对某些目录没有写权限。确保你的下载目录对该用户是可写的。通常使用系统临时目录或CI工作空间目录是安全的选择。

   import tempfile download_path = tempfile.mkdtemp() # 创建一个临时目录，系统会自动管理

3. 内存与资源：无头模式虽然省资源，但大量下载文件仍会占用磁盘空间。必须在测试套件级别（如tearDownClass）或CI作业结束后，有机制清理这些临时下载目录。

4.4 跨浏览器（Chrome/Firefox/Edge）的统一配置

如果你的测试套件需要支持多种浏览器，配置代码需要做一点抽象。

def configure_download_options(driver_options, browser_name, download_path): “”” 根据浏览器类型配置下载选项。 driver_options: 通过 self.get_driver_options() 获取的原始选项对象。 browser_name: 字符串，如 ‘chrome’, ‘firefox’, ‘edge’。 download_path: 字符串，目标下载目录的绝对路径。 “”” if browser_name.lower() == “chrome”: prefs = { “download.default_directory”: download_path, “download.prompt_for_download”: False, “download.directory_upgrade”: True, “safebrowsing.enabled”: False, } driver_options.add_experimental_option(“prefs”, prefs) elif browser_name.lower() == “firefox”: # Firefox通过profile设置 profile = webdriver.FirefoxProfile() profile.set_preference(“browser.download.folderList”, 2) # 2表示使用自定义目录 profile.set_preference(“browser.download.dir”, download_path) profile.set_preference(“browser.download.manager.showWhenStarting”, False) profile.set_preference(“browser.helperApps.neverAsk.saveToDisk”, “application/pdf,application/octet-stream”) # 设置自动保存的MIME类型 # 将profile添加到options中（SeleniumBase可能已封装，具体方式需查文档或适配） # 通常可以通过 driver_options.profile = profile 传递 elif browser_name.lower() == “edge”: # Edge基于Chromium，配置方式与Chrome类似 prefs = {…} # 同Chrome driver_options.add_experimental_option(“prefs”, prefs) else: raise ValueError(f”Unsupported browser: {browser_name}”) return driver_options # 在测试类中使用 class CrossBrowserDownloadTest(BaseCase): def setUp(self): self.download_dir = os.path.abspath(f”./downloads/{self.browser}_{self.id()}”) os.makedirs(self.download_dir, exist_ok=True) options = self.get_driver_options() configured_options = configure_download_options(options, self.browser, self.download_dir) self.browser_options = configured_options super().setUp()

注意：SeleniumBase内部可能已经对browser_options的传递有封装。上述Firefox的示例是一种通用方法，具体集成到SeleniumBase的BaseCase中时，可能需要查看其源码或文档，找到正确设置firefox_profile的方式。一种更SeleniumBase的方式是直接使用其命令行参数--browser-options或--capabilities来传递这些复杂配置。

5. 集成到CI/CD管道的最佳实践

自动化测试最终要融入到持续集成流程中。下载目录的配置在这里需要格外小心。

5.1 在GitLab CI/CD中的配置示例

# .gitlab-ci.yml stages: - test ui-automation: stage: test image: selenium/standalone-chrome:latest # 使用包含浏览器的Docker镜像 variables: # 使用CI项目自带的临时构建目录，确保可写且隔离 SELENIUM_DOWNLOAD_DIR: “${CI_PROJECT_DIR}/.downloads/${CI_JOB_ID}” before_script: - mkdir -p “${SELENLOAD_DIR}” # 创建目录 - pip install -r requirements.txt # 安装依赖，包括seleniumbase script: # 通过环境变量将下载目录传递给测试 - pytest tests/ --browser=chrome --headless --downloads-folder=“${SELENIUM_DOWNLOAD_DIR}” -v after_script: # 可选：将下载的文件作为制品保存，用于调试或后续处理 - if [ -d “${SELENIUM_DOWNLOAD_DIR}” ]; then cp -r “${SELENIUM_DOWNLOAD_DIR}” “./artifacts/”; fi artifacts: when: always paths: - ./artifacts/ expire_in: 1 week # 制品保留一周

关键点：

• CI_PROJECT_DIR和CI_JOB_ID：利用CI环境变量构建唯一、隔离的目录路径。CI_JOB_ID能保证每次流水线运行的下载都是隔离的。
• --headless：在CI中务必使用无头模式。
• 制品（artifacts）：将下载目录归档为制品，如果测试失败，你可以下载这些制品来查看当时下载了什么文件，这对于调试“文件未找到”之类的断言失败非常有帮助。

5.2 在Jenkins Pipeline中的配置示例

pipeline { agent { docker { image ‘selenium/standalone-chrome:latest’ } } environment { // 使用Jenkins的工作空间和构建号创建唯一目录 DOWNLOAD_DIR = “${WORKSPACE}/downloads/${BUILD_NUMBER}” } stages { stage(‘Test’) { steps { sh “mkdir -p ${DOWNLOAD_DIR}” sh “pytest tests/ --browser=chrome --headless --downloads-folder=${DOWNLOAD_DIR} --junitxml=report.xml” } } stage(‘Archive’) { steps { // 将下载的文件和测试报告一起归档 archiveArtifacts artifacts: ‘downloads/**, report.xml’, fingerprint: true } } } post { always { // 清理工作空间，避免磁盘空间累积 cleanWs() } } }

5.3 容器化环境下的路径映射

如果你在Docker容器内运行测试，而浏览器也在容器内，那么你配置的下载目录是容器内的路径。如果你需要从宿主机（比如CI Runner机器）访问这些文件，就需要做卷（volume）映射。

Docker Compose示例：

version: ‘3.8’ services: tests: build: . volumes: # 将宿主机的 ./artifacts/downloads 目录映射到容器内的 /downloads - “./artifacts/downloads:/downloads” environment: - DOWNLOAD_PATH=/downloads command: pytest --downloads-folder=“${DOWNLOAD_PATH}”

在测试代码中，你就可以使用环境变量DOWNLOAD_PATH来设置目录了。这样，文件下载到容器内的/downloads，实际上就保存在了宿主机的./artifacts/downloads下，便于后续处理。

6. 高级技巧与疑难问题排查

即使配置得当，一些古怪的问题还是会出现。这里分享几个我踩过坑后总结的高级技巧和排查清单。

6.1 动态文件名与等待策略

很多时候，下载的文件名是动态的，比如包含时间戳或随机ID（如report_20231027_123456.pdf）。你无法在代码中硬编码文件名。

解决方案：

1. 模式匹配：如果你知道文件名的固定前缀或后缀，可以用glob模块来查找。

   import glob def find_downloaded_file(directory, pattern): “””在目录中查找匹配pattern的第一个文件””” self.wait_for_downloads() # 先等所有下载完成 files = glob.glob(os.path.join(directory, pattern)) return files[0] if files else None file_path = find_downloaded_file(self.download_dir, “report_*.pdf”) self.assertIsNotNone(file_path, “未找到匹配的报告文件”)

2. 目录监控：对于完全不可预测的文件名，可以在触发下载后，记录目录的初始文件列表，然后监控新文件的出现。

   import os import time def wait_for_new_file(directory, existing_files, timeout=30): “””等待目录中出现不在existing_files列表中的新文件””” end_time = time.time() + timeout while time.time() < end_time: current_files = set(os.listdir(directory)) new_files = current_files - existing_files # 过滤掉临时文件 new_files = {f for f in new_files if not f.endswith(‘.crdownload’)} if new_files: # 假设只有一个新文件 return os.path.join(directory, new_files.pop()) time.sleep(0.5) return None # 使用 initial_files = set(os.listdir(self.download_dir)) self.click(“#generate-and-download”) new_file = wait_for_new_file(self.download_dir, initial_files) self.assertIsNotNone(new_file, “未检测到新文件下载”)

6.2 下载对话框的意外弹出及处理

尽管我们设置了“download.prompt_for_download”: False，但某些网站的特殊脚本或浏览器插件仍可能导致下载对话框弹出，从而阻塞自动化流程。

防御性处理：

• 启动浏览器时添加参数：在浏览器选项中添加–disable-download-notification和–disable-gpu（后者有时能减少图形界面相关的问题）。

  chrome_options.add_argument(‘–disable-download-notification’) chrome_options.add_argument(‘–disable-gpu’)

• 使用浏览器监控：这不是一个优雅的方案，但作为最后的手段，可以尝试在触发下载后，用一段脚本检测并关闭可能弹出的原生对话框（例如，在Windows上使用pyautogui模拟键盘回车或ESC）。这非常脆弱且不推荐，它破坏了跨平台性。更好的方法是分析为什么对话框会出现，是不是因为网站使用了非标准的下载方式，或者我们的MIME类型设置（对于Firefox）不完整。

6.3 常见失败场景排查清单

当你的下载测试失败时，可以按照这个清单从上到下排查：

6.4 性能优化：复用浏览器与下载目录

对于大型测试套件，为每个测试方法都启动和关闭浏览器非常耗时。可以尝试复用浏览器实例，但下载目录的隔离就需要更精细的管理。

思路：使用pytest的scope=”session”级别的fixture启动一个浏览器，所有测试共用。但下载目录必须在每个测试方法级别进行“重置”。

# conftest.py import pytest from seleniumbase import BaseCase @pytest.fixture(scope=”session”) def shared_browser(request): “””会话级共享浏览器，只启动一次””” sb = BaseCase(“test_placeholder”) sb.setUp() yield sb sb.tearDown() @pytest.fixture def isolated_download_test(shared_browser, tmp_path, request): “””为每个测试提供隔离的下载环境和浏览器状态””” # 1. 为本次测试创建唯一下载目录 test_dl_dir = tmp_path / “downloads” / request.node.name test_dl_dir.mkdir(parents=True, exist_ok=True) # 2. 动态修改已启动浏览器的下载偏好（这比较棘手） # Chrome DevTools Protocol (CDP) 可能允许运行时修改，但通常更简单的方式是： # 每个测试还是用独立的浏览器实例，或者接受一定程度的目录管理复杂度。 # 更可行的方案是：将会话级浏览器的下载目录设为一个基目录，每个测试在基目录下创建自己的子文件夹。 # 但这要求测试代码能知道自己的子文件夹路径，并在操作前通过CDP命令（如 `Page.setDownloadBehavior`）动态切换。 # 3. 返回一个包含sb实例和其专属目录的对象 class TestContext: sb = shared_browser download_path = str(test_dl_dir) # **关键步骤**：在测试开始前，通过CDP设置本次测试的下载行为 # 注意：这需要Chrome 62+，并且启用自动下载 params = {‘behavior’: ‘allow’, ‘downloadPath’: test_dl_dir} shared_browser.driver.execute_cdp_cmd(‘Page.setDownloadBehavior’, params) yield TestContext() # 4. 测试结束后，可以清理该测试的下载目录 # shutil.rmtree(test_dl_dir) # 可选

这个方案较为复杂，涉及到Chrome DevTools Protocol的高级用法。对于大多数项目，平衡测试隔离性和执行速度，使用scope=”class”（每个测试类一个浏览器）可能是更简单可靠的选择。

7. 总结与个人体会

折腾SeleniumBase的下载配置，从最初的到处碰壁到现在的游刃有余，我感觉最关键的不是记住那几行配置代码，而是理解浏览器自动化下载的整个生命周期和不同环境下的约束。它不是一个孤立的“配置点”，而是涉及浏览器偏好、测试框架生命周期、操作系统权限、CI环境隔离和测试数据管理的一个小系统工程。

我个人最深刻的体会有两点：第一，绝对路径和目录隔离是基石。无论是在本地开发还是在云端执行，使用明确的、唯一的绝对路径能避免一大半的“文件找不到”问题。第二，关闭安全浏览（safebrowsing.enabled）在测试环境中往往是必要的，它能消除一个最大的不确定性因素，让下载行为变得可预测。当然，如果你们的测试要求必须模拟真实用户环境，那就得为这个延迟设计更长的等待和更健壮的断言。

最后，再分享一个小心得：在你主要的下载测试用例里，不妨加一段“环境检查”代码，在setUp开始时打印出本次测试使用的浏览器类型、下载目录完整路径以及关键的配置项。当CI任务失败时，这些日志信息会是你的第一盏指路明灯。自动化测试的稳定性，往往就藏在这些看似微不足道的细节配置里。