在 GitHub Actions 上运行 SeleniumBase 浏览器自动化测试CI 工作流从搭建到实战【免费下载链接】SeleniumBaseAPIs for browser automation, testing, and bypassing bot-detection. Includes CDP Mode: A stealthy configuration for chromium that passes every bot detection test.项目地址: https://gitcode.com/GitHub_Trending/se/SeleniumBaseSeleniumBase 是一套面向浏览器自动化、测试与反爬检测的 Python 框架其测试层基于 pytest 运行并通过 Selenium 驱动真实浏览器。本文将基于仓库中的官方集成文档integrations/github/workflows/ReadMe.md结合仓库内真实存在的 GitHub Actions 工作流文件完整讲解如何在 GitHub Actions 上创建、运行与观察 SeleniumBase 浏览器测试。读完本文你将能够从零搭建一套提交即测试的 CI 流水线理解多 Python 版本矩阵、无头/虚拟显示运行、会话复用等关键参数并掌握上传构建产物与 Slack 通知等进阶玩法。一、为什么要在 GitHub Actions 上跑浏览器测试浏览器自动化测试与普通单元测试不同它需要真实的浏览器环境、浏览器驱动如 chromedriver并且测试耗时更长。手动在本地维护一套浏览器测试环境成本高、不可重复而 GitHub Actions 提供了开箱即用的 Ubuntu / macOS / Windows 运行器可以在每次代码提交push或合并请求pull request时自动拉取代码、安装依赖、启动浏览器并执行测试。仓库的 integrations/github/workflows/ReadMe.md 正是官方给出的这套集成方案的入门指南它告诉你如何以最快的四个步骤把一个 SeleniumBase 测试套件跑进 GitHub Actions。需要特别说明的是GitHub Actions 的虚拟环境自带 Chrome 等浏览器而 SeleniumBase 提供的seleniumbase install chromedriver命令可以自动下载与浏览器版本匹配的驱动这正是 CI 中能稳定运行的前提下文工作流源码中会看到这一步。二、四步搭建官方文档给出的最小路径官方文档的核心是一套四步走流程面向 GitHub Actions 界面的操作完整步骤如下。Step 0在 GitHub 上 fork 一份 SeleniumBase 仓库在 GitHub 上创建 SeleniumBase 的 fork作为自己的起点。文档特别提示你最终会使用自己的仓库。fork 的意义在于SeleniumBase 的默认分支上已经带有一份完整的 CI 工作流脚本即仓库根目录下的 .github/workflows/python-package.ymlfork 之后这份脚本会自动出现在你的仓库中无需从零编写。Step 1从 GitHub Actions 标签页选择 Python package 工作流进入你仓库的Actions标签页GitHub 会基于仓库语言推荐一组现成的工作流模板从中选择Python package模板。该模板会自动生成一份.github/workflows/目录下的 YAML 工作流文件它是后续步骤的基础骨架。Step 2添加你的工作流.yml脚本在.github/workflows/目录下编辑 YAML 脚本。文档明确说明如果使用的是 SeleniumBase 的 fork.github/workflows/python-package.yml这份脚本已经存在可以直接作为参照和起点。仓库中这份真实脚本正是开箱即用的范本我们将在第三节逐段拆解它。Step 3将变更提交到 GitHub把.github/workflows/*.yml以及需要 CI 验证的测试代码一起 commit 并 push。工作流文件只有被推送到远端分支后GitHub Actions 才会真正调度执行。Step 4测试自动运行至此你的测试会在以下两个时机自动触发每次 pull request合并请求每次向master分支的 commit推送。在 Actions 页面可以看到每个构建的入口可以点击进入每个 build 查看详细信息可以查看每个命令执行的具体步骤如安装依赖、安装 chromedriver、运行 pytest 等会注意到Chrome、Firefox 等浏览器在构建过程中被自动安装供测试使用。文档最后点明了这套技术栈的运作方式SeleniumBase 使用 pytest 运行测试同时使用 Selenium 与浏览器交互。 这意味着你在 CI 里看到的测试命令本质上是 pytest 命令而浏览器驱动与交互能力全部由 SeleniumBase 封装提供。三、拆解仓库自带的 CI 工作流python-package.yml上文 Step 2 提到的现成脚本就是仓库根目录下的 .github/workflows/python-package.yml。这份文件是理解整套集成方案的钥匙下面逐段剖析。3.1 触发条件与多版本矩阵name: Tests on: pull_request: branches: push: branches: - master workflow_dispatch: branches:on.push.branches限定为master只在 master 分支的推送时触发与官方文档 Step 4 的描述完全一致pull_request未限定分支任何合并请求都会触发workflow_dispatch允许在 Actions 页面手动触发一次构建方便调试。jobs: build: env: PY_COLORS: 1 runs-on: ubuntu-latest strategy: fail-fast: false max-parallel: 6 matrix: python-version: [3.10, 3.11, 3.12, 3.13, 3.14, 3.15]这里定义了一个包含 6 个 Python 版本的矩阵3.10 至 3.15。值得注意的细节fail-fast: false即使某个 Python 版本的任务失败也不会取消其他版本的任务从而一次性暴露所有版本上的问题max-parallel: 6最多 6 个任务并行执行PY_COLORS: 1启用 Python 彩色输出便于在 Actions 日志中阅读。3.2 依赖安装三步曲steps: - uses: actions/checkoutv7 - name: Set up Python ${{ matrix.python-version }} uses: actions/setup-pythonv7 with: python-version: ${{ matrix.python-version }} allow-prereleases: true - name: Install dependencies run: | python -m pip install --upgrade pip wheel setuptools pip install -r requirements.txt - name: Install SeleniumBase run: | pip install .actions/checkoutv7拉取仓库代码actions/setup-pythonv7安装矩阵指定的 Python 版本allow-prereleases: true表明也接受预发布版本先安装requirements.txt仓库根目录的 requirements.txt 声明了运行依赖再执行pip install .把当前目录的 SeleniumBase 以可编辑/本地包方式安装对应 setup.py / pyproject.toml。3.3 冒烟检查命令行接口与驱动- name: Check the console scripts interface run: | seleniumbase sbase - name: Install chromedriver run: | seleniumbase install chromedriver - name: Make sure pytest is working run: | pytest --help echo def test_1(): pass nothing.py pytest nothing.py - name: Make sure nosetests is working run: | echo def test_2(): pass nothing2.py nosetests nothing2.py这一步集中体现了 SeleniumBase 的自带驾驶舱设计seleniumbase与sbase是 SeleniumBase 提供的两个等价控制台命令入口实现位于 seleniumbase/console_scripts/执行一次即可验证安装是否成功seleniumbase install chromedriver是 CI 中最关键的一步它自动下载与当前环境匹配的 chromedriver。在 GitHub Actions 的 Ubuntu 运行器上这一步解决了有 Chrome 无驱动的经典问题用两个极简的临时测试文件快速验证 pytest 与 nosetests 两条测试运行链路可用注意到仓库的 pytest.ini 配置了python_files test_*.py *_test.py *_tests.py *_suite.py等发现规则因此nothing.py这类临时文件不会被误收集。3.4 正式测试pytest 与 behave 双线并行工作流的后半段是一组真实的测试运行步骤直接对应仓库examples/目录下的示例- name: Run pytest examples/unit_tests/verify_framework.py --browserchrome --headless run: | pytest examples/unit_tests/verify_framework.py --browserchrome --headless -v -s --junit-xmljunit/test-results.xml - name: Run pytest examples/boilerplate_test.py --browserchrome --headless run: | pytest examples/boilerplates/boilerplate_test.py --browserchrome --headless -v -s --junit-xmljunit/test-results.xml - name: Run pytest examples/test_demo_site.py --browserchrome --xvfb run: | pytest examples/test_demo_site.py --browserchrome --xvfb -v -s --junit-xmljunit/test-results.xml - name: Run pytest examples/iframe_tests.py --browserchrome --xvfb --rs --crumbs run: | pytest examples/iframe_tests.py --browserchrome --xvfb --rs --crumbs -v -s --junit-xmljunit/test-results.xml ... - name: Run behave examples/behave_bdd/features/calculator.feature -D rs -D crumbs -D xvfb run: | behave examples/behave_bdd/features/calculator.feature -D rs -D crumbs -D xvfb -T -k这些命令行参数全部由 SeleniumBase 的 pytest 插件seleniumbase/plugins/pytest_plugin.py解析含义如下参数含义说明--browserchrome指定浏览器在 CI 的 Ubuntu 运行器上使用 Chrome--headless无头模式不启动可见的浏览器窗口适合没有显示器的 CI 环境--xvfb虚拟显示通过 Xvfb 提供虚拟 X 显示服务器让浏览器以为自己有屏幕比--headless更接近真实环境插件中--xvfb与--headless的说明位于 pytest_plugin.py 附近--rs复用会话即--reuse-session多个测试复用同一个浏览器会话显著加快套件执行速度--crumbs清理 Cookie配合--rs使用复用会话的同时在每个测试之间删除所有 Cookie避免状态串扰插件中的定义见 pytest_plugin.py-v -spytest 标准参数详细输出 不捕获 stdout--junit-xmlJUnit 报告输出机器可读的测试结果便于 GitHub Actions 呈现测试摘要-T -kbehave 参数behave 的标签/顺序相关选项被 CI 覆盖的测试文件也很有代表性examples/unit_tests/verify_framework.py框架自检测试用pytester内联生成用例验证 BaseCase 的断言、跳转、输入、点击等基础能力以及 dashboard 等扩展功能examples/boilerplates/boilerplate_test.py页面对象Page Object模式的样板测试examples/test_demo_site.py、examples/test_mfa_login.py、examples/test_window_switching.py、examples/iframe_tests.py、examples/my_first_test.py、examples/test_inspect_html.py覆盖多因素登录、窗口切换、iframe、HTML 检查等典型浏览器测试场景behave 侧则运行 examples/behave_bdd/features/calculator.feature 与 examples/behave_bdd/features/realworld.feature并通过-D rs -D crumbs -D xvfb传入与 pytest 侧等价的--rs --crumbs --xvfb行为参数。从这份清单可以归纳出一条实战经验同一套浏览器测试既可以用 pytest 风格写也可以用 behaveBDD风格写CI 中二者并行验证覆盖框架自身两种主流用法。四、跨平台覆盖Nightly 工作流除了针对每次提交的 .github/workflows/python-package.yml仓库还提供了三个基于schedule定时触发的夜间测试工作流用于覆盖不同操作系统.github/workflows/python-nightly-ubuntu.yml每天 01:30UTC在ubuntu-latest上运行.github/workflows/python-nightly-mac.yml每天 01:40UTC在macos-latest上运行.github/workflows/python-nightly-windows.yml每天 01:50UTC在windows-latest上运行。三个文件都保留了workflow_dispatch触发方式意味着除了定时也可以在 Actions 页面手动触发。它们与主工作流的差异点很能说明跨平台细节# windows nightly 中的两个特殊步骤 - name: Get chrome-headless-shell run: | sbase get chsWindows 任务额外执行sbase get chs拉取chrome-headless-shellchs这对应 examples/unit_tests/verify_framework.py 顶部的逻辑在 Windows 平台上框架默认使用--chschrome-headless-shell代替--headless。这个细节提醒我们跨平台 CI 中浏览器的无头方案并不总是一致SeleniumBase 已经内置了平台适配。此外三个 nightly 工作流末尾都有一行- name: Verify seleniumbase install from PyPI run: | pip install seleniumbase -U --no-deps --force-reinstall --no-cache-dir这是对发布流程的验证确认 SeleniumBase 能从 PyPI 正确安装从而保证 CI 所用代码与对外发布版本的一致性。仓库中还有一个与 CI 相关的 .github/workflows/pages.yml用于把文档构建并部署到 GitHub Pages仅当github.repository seleniumbase/SeleniumBase时执行与浏览器测试本身无直接关系此处不作展开。五、进阶集成一上传构建产物Artifacts官方配套文档 integrations/github/workflows/extras.md 提供了两类进阶集成第一类是上传 Artifacts。典型场景是SeleniumBase 的 Presenter 功能examples/presenter/可以生成 HTML 演示文稿测试结束后希望把这个 HTML 作为构建产物供人下载查看。示例- uses: actions/upload-artifactv6 with: name: Click to download the presentation path: saved_presentations/my_presentation.html要点name是产物名称会显示在构建页面的 Artifacts 区域path是产物在运行器上的路径可以指向单个文件或目录产物默认在构建保留期后过期可在仓库设置中调整保留天数。同理上一节中--junit-xmljunit/test-results.xml生成的 JUnit 报告也可以用upload-artifact上传方便在 Actions 页面直接下载查看测试结果。六、进阶集成二Slack 通知第二类进阶集成是通过 rtCamp/action-slack-notify 把构建结果推送到 Slack。官方文档给出的用法如下- name: Slack notification uses: rtCamp/action-slack-notifymaster env: SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK }} SLACK_CHANNEL: general SLACK_ICON_EMOJI: rocket SLACK_USERNAME: SeleniumBase SLACK_MESSAGE: Actions workflow completed successful! :tada: https://github.com/${{ github.repository }}/actions/runs/${{ github.run_id }}配置步骤与关键点创建 Slack 集成 Webhook在 Slack 应用管理里生成一个 incoming webhook把 Webhook 值存入仓库 Secret在仓库 Settings → Secrets and variables → Actions 中新建名为SLACK_WEBHOOK的 secret。Secret 以${{ secrets.SLACK_WEBHOOK }}形式引用GitHub 会确保其值不出现在日志中SLACK_CHANNEL可选默认使用 Webhook 绑定的频道未指定时发送到默认频道示例中SLACK_MESSAGE使用github.repository与github.run_id这两个上下文变量拼出指向本次工作流运行的链接这样团队成员收到通知后可以一键跳到构建页面查看例如由 Presenter 功能生成的Artifacts。七、实战要点与常见坑结合上文对工作流与源码的分析在 GitHub Actions 上运行 SeleniumBase 测试时有几点值得注意无头与虚拟显示的选择--headless快且简单--xvfb为浏览器提供完整 X 虚拟显示对依赖真实渲染行为如某些反检测、canvas、复杂 CSS的测试更友好。官方工作流里两种方式都在用建议按测试类型混合配置。SeleniumBase 的 pytest 插件对二者都有完整支持见 seleniumbase/plugins/pytest_plugin.py。驱动管理务必在测试前执行seleniumbase install chromedriver跨平台时留意 Windows 上--chschrome-headless-shell的差异。会话复用要搭配--crumbs--rs大幅提速但会让 Cookie 在用例间残留官方在 iframe 测试中同时使用--rs --crumbs即复用会话 用例间清 Cookie这是可复制的稳妥组合。不要忘记workflow_dispatch给工作流加上workflow_dispatch触发条件就可以在 Actions 页面手动重跑调试 CI 时非常方便官方四个测试工作流都保留了它。矩阵的取舍fail-fast: false能一次看清所有 Python 版本的结果如果只想快速验证可以只保留 LTS 版本把完整矩阵留给 nightly 任务。八、总结通过官方文档的四步流程再加上仓库中 .github/workflows/python-package.yml 这份真实工作流的逐段拆解你已经掌握了一套完整的 SeleniumBase GitHub Actions 集成方案从 fork、选择模板、提交 YAML 到自动触发从多 Python 版本矩阵、chromedriver 安装、pytest/behave 双线执行到--headless/--xvfb/--rs/--crumbs这些 SeleniumBase 特有参数的语义与搭配再到上传 Artifacts 与 Slack 通知两类进阶玩法。剩下要做的就是复制这套模式到自己的测试仓库让每一次提交都由浏览器自动化测试把关。【免费下载链接】SeleniumBaseAPIs for browser automation, testing, and bypassing bot-detection. Includes CDP Mode: A stealthy configuration for chromium that passes every bot detection test.项目地址: https://gitcode.com/GitHub_Trending/se/SeleniumBase创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考