开箱即用无图形界面 Linux 上把 Chrome 自动化测试跑起来干这行久了你会发现真正难搞的往往不是测试用例本身而是“测试跑在哪儿”。很多项目跑在无图形界面的 Linux 服务器上没有显示器、没有桌面环境但你又必须用真实的 Chrome 浏览器做回归测试、页面监控或者数据采集。最开始我也被“没有界面怎么跑 Chrome”这件事卡住过后来把整条链路理清楚才发现无头 Linux Chrome Selenium 这套组合其实非常成熟完全可以在纯命令行的环境里跑出带截图、带日志、能集成 CI 的自动化测试体系。这篇文章我会从方案选型、环境准备、Chrome 安装、ChromeDriver 配置、Selenium 脚本编写一直讲到容器化和 CI 落地全部基于我实际踩过的坑和验证过的命令。适合运维、测试开发、后端工程师也适合刚接触自动化测试但被服务器环境劝退的新手。1. 整体思路与方案选型1.1 为什么要在无图形界面 Linux 上跑 Chrome很多测试场景的终局环境就是一台只有 SSH 的 Linux 服务器。比如Web 项目要跑端到端回归测试但开发机是 Windows测试环境是 Linux定时抓取页面数据、监控页面可用性需要真实浏览器渲染自动化测试要进 Jenkins、GitLab CI 流水线执行环境是 Docker 容器或云主机界面测试用例需要晚上批量执行白天出报告。如果这时候非要在有桌面的机器上跑成本会高很多。而 Chrome 本身提供了 headless 模式不需要物理显示器也能完成页面渲染、点击、截图、生成 PDF 等操作。配合 WebDriver 协议Selenium 可以直接操控真实 Chrome 的内核也就是说你在本地写的测试逻辑在服务器上几乎可以一模一样地运行。1.2 为什么选 Chrome Selenium 而不是其他方案自动化浏览器测试的轮子不少主流的无非是 Selenium、Playwright、Puppeteer以及更老牌的 PhantomJS。我从实际维护成本角度说一下为什么选 ChromeChrome 本来就是用户量最大的浏览器测试结果更贴近真实用户环境DevTools 协议成熟对无头模式、移动端模拟、网络模拟支持好Selenium 生态老牌团队里无论谁接手找资料的难度都低Playwright 也很好但在版本兼容和既有框架改造上Selenium 更省心PhantomJS 基本已经停更不建议新项目碰。当然我这里并不是说所有项目都必须用 Chrome。如果团队已经用了 Puppeteer 而且只写 Node那就继续用。但如果你需要一个“跨语言、跨测试框架都能接”的兜底方案Selenium ChromeDriver 绝对是最稳的组合。1.3 整体架构和组件关系先搞清楚这几个组件的关系后面就不容易晕头转向Chrome浏览器本体负责渲染页面、执行 JSChromeDriver一个独立进程实现了 WebDriver 协议负责把 Selenium 的指令翻译给 ChromeSelenium Client测试脚本里的依赖库比如 Python 的 selenium 包测试脚本你写的测试逻辑通过 Selenium Client 发出控制指令。无图形界面环境下本质上只是少了显示器这一个输出设备Chrome 用 headless 模式渲染时直接把页面画到内存缓冲区里不需要 X Server。所以硬件层面没什么特殊要求内存稍微给足一点就够了。2. 环境准备与基础依赖2.1 确认系统环境和常用命令不管你是 CentOS、Debian 还是 Ubuntu装 Chrome 之前先明确操作系统类型。比如 CentOS 用 rpm 包Ubuntu 用 deb 包搞混了会在依赖解析上浪费很多时间。先跑这几条常用命令把系统信息摸清楚cat /etc/os-release uname -m free -h df -h nproccat /etc/os-release看发行版名称和版本号uname -m看架构一般 x86_64free -h确认内存Chrome 无头模式下单个渲染进程至少 300MB 起步df -h确认磁盘空间Chrome 安装包和解压后的依赖加起来不会超过 500MBnproc看 CPU 核数后续并行跑测试时要用。我见过好几个人栽在第一步拿到一台机器就盲目跑安装命令结果系统版本判断错了rpm 和 deb 混着装最后只能重装系统重来。开始之前花两分钟跑这几条命令比踩坑之后排查效率高得多。2.2 安装基础编译和网络工具服务器一般是最小化安装很多工具缺省。先补上CentOS / RHEL 系yum install -y epel-release yum install -y wget curl unzip git vimUbuntu / Debian 系apt-get update apt-get install -y wget curl unzip git vimunzip很重要ChromeDriver 下载下来就是 zip 压缩包。wget和curl则用来下载安装包和测试网络连通性。如果系统里已经装了这些工具再执行一次也不会造成什么影响。2.3 安装 Chrome 运行所需的动态链接库这是无图形界面环境最容易踩的坑。Chrome 虽然以 headless 模式运行但它仍然依赖很多图形界面的底层动态库比如libX11、libXcomposite、libnss3。缺少这些库时启动 Chrome 就会报 “error while loading shared libraries”。不同发行版依赖库的包名不太一样。CentOS 上我习惯一次性装好以下这些yum install -y \ liberation-fonts \ libX11 \ libX11-devel \ libXcomposite \ libXcursor \ libXdamage \ libXext \ libXfixes \ libXi \ libXrandr \ libXrender \ libXtst \ libxcb \ libxkbcommon \ nss \ alsa-lib \ pango \ atk \ cups-libsUbuntu / Debian 系apt-get install -y \ libxss1 \ libx11-xcb1 \ libxcb-dri3-0 \ libgbm1 \ libnss3 \ libasound2 \ libatk-bridge2.0-0 \ libatspi2.0-0 \ libcups2 \ libdrm2 \ libxkbcommon0 \ libxcomposite1 \ libxdamage1 \ libxfixes3 \ libxrandr2 \ libpango-1.0-0 \ libcairo2 \ fonts-liberation这些依赖我在多个服务器上验证过覆盖面比较全。装完之后可以先用ldd检查 Chrome 主程序的依赖是否满足不过更快的验证方式是直接跑google-chrome --version如果能正常输出版本号就说明基础库没问题了。3. 安装 Chrome 并完成基础验证3.1 通过官方仓库安装Chrome 官方提供了 rpm 和 deb 仓库这样后续升级也比较方便。以 CentOS 为例创建 yum 源文件cat /etc/yum.repos.d/google-chrome.repo EOF [google-chrome] namegoogle-chrome baseurlhttps://dl.google.com/linux/chrome/rpm/stable/$basearch enabled1 gpgcheck1 gpgkeyhttps://dl.google.com/linux/linux_signing_key.pub EOF然后安装yum install -y google-chrome-stableUbuntu 则通过添加 apt 源wget -q -O - https://dl.google.com/linux/linux_signing_key.pub | apt-key add - echo deb [archamd64] http://dl.google.com/linux/chrome/deb/ stable main /etc/apt/sources.list.d/google-chrome.list apt-get update apt-get install -y google-chrome-stable如果网络环境无法访问官方源也可以直接在官网下载安装包。比如 CentOS 上用wget https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm yum localinstall -y google-chrome-stable_current_x86_64.rpmUbuntu 上用wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb apt install -y ./google-chrome-stable_current_amd64.deb需要注意的是这里的 URL 是官方固定路由长期有效。如果用代理环境或者受限网络可能要自己处理下载源的问题这个不属于本文讨论范围但思路就是“先把安装包拿到手”。3.2 验证 Chrome 是否可用装完之后先跑一条命令google-chrome --version如果输出类似Google Chrome 128.0.6613.119说明基础环境正常。接下来试一下 headless 模式能否真正无头渲染。最简单的验证方式是用 Chrome 自带的--dump-dom参数直接抓一个网页的 DOMgoogle-chrome --headless --no-sandbox --disable-gpu --dump-dom https://example.com这条命令会启动 Chrome在无头模式下请求 example.com然后把 HTML 内容打印到终端。如果能看到类似titleExample Domain/title的内容说明 Chrome 已经可以在这台无图形界面服务器上工作了。这里加--no-sandbox是因为如果服务器用 root 账户登录Chrome 沙箱组件无法正常工作会主动拒绝启动。生产环境建议不要用 root 跑测试但很多时候 CI 容器里就是 root所以这个参数要记住。3.3 补充说明Chromium 和 Chrome 的选择既然能用 Chrome 官方版本那 Chromium 社区版还有没有必要我的建议是如果测试环境必须与生产环境浏览器版本保持一致用官方 Chrome如果只是内部工具、爬虫采集用 Chromium 也完全可以。有些发行版自带chromium包安装更简单但 Chromium 的二进制文件不一定同 Chrome 完全一致而且某些复杂页面比如需要播放 DRM 内容的站点呈现效果会有差异。我个人偏向官方 Chrome理由很简单ChromeDriver 的版本匹配最麻烦而官方 Chrome 和 ChromeDriver 的版本节奏是同步规划的踩坑概率低。4. 安装 ChromeDriver 并解决版本匹配4.1 下载 ChromeDriverChromeDriver 是 Selenium 和 Chrome 之间的“翻译官”。ChromeDriver 必须和 Chrome 浏览器版本保持大版本一致。举个例子Chrome 128 就对应 ChromeDriver 128两者差一个大版本经常会报错。获取 ChromeDriver 的方式有几种从 Chrome for Testing 官方渠道下载页面https://googlechromelabs.github.io/chrome-for-testing/JSON 接口会自动列出当前稳定版的下载地址用 WebDriverManager 库自动下载后面会写。在 Linux 上手动下载并安装的步骤是cd /tmp wget https://storage.googleapis.com/chrome-for-testing-public/128.0.6613.119/linux64/chromedriver-linux64.zip unzip chromedriver-linux64.zip mv chromedriver-linux64/chromedriver /usr/local/bin/ chmod x /usr/local/bin/chromedriver chromedriver --version这里要注意URL 中的版本号必须和你安装的 Chrome 版本一致。如果你不确认当前 Chrome 版本可以执行google-chrome --version然后把对应的版本号替换到 URL 里。chmod x这步很关键漏了会出现 “Permission denied” 的诡异报错。4.2 配置 PATH 环境变量/usr/local/bin一般已经在 PATH 里所以把 ChromeDriver 移到那里最简单。如果没有可以手动追加export PATH$PATH:/usr/local/bin echo export PATH$PATH:/usr/local/bin ~/.bashrc配置到位后执行which chromedriver如果能看到路径就说明环境变量没问题。4.3 用 WebDriverManager 自动管理版本手动下载的痛点是每次 Chrome 升级ChromeDriver 都要跟着升级。如果不及时更新测试脚本会突然崩溃而且报错信息往往很隐晦。Python 生态里有一个 WebDriverManager 库可以在脚本启动时自动检测 Chrome 版本并下载对应的 ChromeDriver非常省心。安装pip3 install selenium webdriver-manager脚本里这样写from selenium import webdriver from webdriver_manager.chrome import ChromeDriverManager from selenium.webdriver.chrome.service import Service service Service(ChromeDriverManager().install()) options webdriver.ChromeOptions() options.add_argument(--headlessnew) options.add_argument(--no-sandbox) options.add_argument(--disable-dev-shm-usage) driver webdriver.Chrome(serviceservice, optionsoptions) driver.get(https://example.com) print(driver.title) driver.quit()第一次运行 WebDriverManager 会联网下载匹配的 ChromeDriver后续会自动走本地缓存。这个方案我推荐给所有环境尤其是 CI 里换机器频繁的场景可以少写一堆版本更新脚本。5. 编写并运行第一个 Selenium 自动化脚本5.1 准备 Python 环境如果服务器还没装 Python 3先安装CentOSyum install -y python3 python3-pipUbuntu / Debianapt-get install -y python3 python3-pip然后安装依赖pip3 install selenium如果你打算用测试框架可以再装pytest后面写用例会更舒服pip3 install pytest5.2 一个最小可运行的脚本先写一个最简版本验证整套链路是通的from selenium import webdriver from selenium.webdriver.chrome.options import Options options Options() options.add_argument(--headlessnew) options.add_argument(--no-sandbox) options.add_argument(--disable-dev-shm-usage) options.add_argument(--disable-gpu) options.add_argument(--window-size1920,1080) driver webdriver.Chrome(optionsoptions) try: driver.get(https://example.com) print(页面标题, driver.title) print(当前URL, driver.current_url) driver.save_screenshot(/tmp/example_home.png) print(截图已保存) finally: driver.quit()这段脚本做了这么几件事创建ChromeOptions追加 headless 相关参数启动 Chrome访问 example.com输出页面标题保存一张全屏截图到/tmp最终通过finally关闭浏览器防止僵尸进程。跑一下python3 test_simple.py如果输出标题和截图路径说明无图形界面环境下的 Chrome 自动化测试已经跑通了。5.3 参数解析这些参数你不能随便省很多人从网上复制一堆参数但不知道为什么要加。这里给我常用的组合做一个逐个说明--headlessnew启用新版无头模式。Chrome 109 之后推荐使用new支持更多真实浏览器行为--no-sandbox解决 root 用户或容器内沙箱初始化失败的问题--disable-dev-shm-usage解决/dev/shm空间不足导致的 Chrome 崩溃。Docker 容器默认共享内存只有 64MB不加这个参数复杂页面大概率会白屏或闪退--disable-gpu无头模式下 GPU 加速没意义而且部分服务器环境没有 GPU 驱动不加会告警--window-size1920,1080指定视口大小。不指定的话有些响应式页面布局会异常截图内容也会很怪--ignore-certificate-errors如果测试环境用的是自签名 HTTPS 证书这个参数可以避免证书校验失败--langzh-CN保证浏览器环境是中文很多前端框架会读取navigator.language做语言切换。组合使用时建议固定一套模板不要每个脚本各写各的不然排查问题时分不清是参数差异还是代码问题。5.4 进阶没有 X Server 时如何跑“非 headless”脚本假设你的测试脚本里已经硬编码了一些依赖图形界面的操作又不想每个都改可以用Xvfb虚拟出一块“屏幕”。安装CentOSyum install -y XvfbUbuntu / Debianapt-get install -y xvfb然后通过xvfb-run包装命令xvfb-run --server-args-screen 0 1920x1080x24 python3 test_ui.py这样做的好处是脚本里可以继续用普通模式启动 Chrome不需要改 Selenium 参数。缺点是会多一个 Xvfb 进程内存占用比纯 headless 高。我一般只在老脚本迁移阶段用新写的代码一律走 headless 模式。6. 常见问题与排查技巧实录6.1 Chrome 启动直接报错最常见的几类报错和解决思路我整理成了一张表报错信息原因解决办法error while loading shared libraries: libnss3.so缺依赖库对照第 2.3 节补齐基础库Running as root without --no-sandbox is not supportedroot 用户在无沙箱时启动加--no-sandboxDevToolsActivePort file doesnt existChrome 启动失败或崩溃加--disable-dev-shm-usage确认内存充足SessionNotCreatedException: This version of ChromeDriver only supports Chrome version xxxChromeDriver 和 Chrome 版本不匹配升级 ChromeDriver 或回退 Chrome 版本Failed to move to new namespace容器内沙箱权限受限加--no-sandbox或调整容器安全配置Timed out receiving message from renderer页面加载超时或资源不足增加page_load_timeout检查网络和内存遇到问题时第一步不是改代码而是先拿最简方式复现比如google-chrome --headless --no-sandbox --disable-gpu --dump-dom https://example.com如果这一步都失败说明问题在 Chrome 本身如果成功问题多半在 Selenium 参数或者脚本逻辑上。这种排查顺序能帮你快速缩小范围。6.2 Chrome 页面白屏或进程被 “杀死”这类问题的幕后黑手通常是 Docker 容器默认的/dev/shm太小。Chrome 渲染页面时会把共享内存映射到/dev/shm默认 64MB 很容易被用完然后渲染进程直接崩溃。解决办法有两种启动容器时加内存参数docker run --shm-size2g ...或者给 Chrome 加参数options.add_argument(--disable-dev-shm-usage)第一种方案更彻底第二种方案更省事。我在 CI 里一般两个都做双保险。6.3 ChromeDriver 版本匹配的坑Chrome 是自动更新的但 ChromeDriver 不会。你昨天跑得好好的脚本今天突然报版本不匹配十有八九是 Chrome 在后台更新了。检查方法是google-chrome --version chromedriver --version对比两个版本号大版本必须一致。如果发现 Chrome 已经升到 129 而 ChromeDriver 还停留在 128要么把 Chrome 降回来要么让 WebDriverManager 重新下载一遍。这里我强烈建议如果是长期跑的服务器关闭 Chrome 的自动更新。在 yum 配置里修改版本锁vim /etc/yum.conf # 添加 excludegoogle-chrome-stable或者直接用yum versionlock google-chrome-stable。测试环境的稳定性比版本新鲜度重要得多。6.4 并行跑多个用例时的资源管理无头 Chrome 并不是特别吃 CPU但每个浏览器实例都会开多个进程内存占用很可观。并行跑用例时我一般按照“每个 Chrome 实例分配 500MB 1GB 内存”的预估来规划机器的并发数。举个例子4 核 8G 的服务器跑 4 个并行任务没问题但如果同时开 20 个 Chrome 实例内存可能直接被打满然后所有测试一起崩。遇到这种情况可以通过设置max_instances或使用pytest-xdist来控制并发数量pip3 install pytest-xdist pytest -n 4-n 4表示同时跑 4 个进程单位是进程而不是浏览器实例具体还需要你结合自己的用例时长做调整。6.5 截图、日志和调试技巧无图形界面环境下肉眼看不到浏览器调试主要靠截图和日志。截图driver.save_screenshot()在失败时保存现场页面源码driver.page_source可用来分析页面是否渲染完整浏览器日志通过ChromeDriver日志和driver.get_log(browser)拿到浏览器控制台输出ChromeDriver 自身日志启动时加service_log_pathservice Service(/usr/local/bin/chromedriver, service_args[--verbose, --log-path/tmp/chromedriver.log])这些手段组合起来即使没有显示器也能把问题定位到“是页面渲染失败”还是“元素定位错误”再对症下药。7. 容器化与 CI 落地7.1 写一个可复用的 Dockerfile把环境固化下来是所有团队成员避免“在我电脑上能跑”魔咒的最优解。下面是一个生产可用的 Dockerfile 示例FROM python:3.11-slim # 安装 Chrome 所需依赖 RUN apt-get update apt-get install -y \ wget \ gnupg \ unzip \ curl \ fonts-liberation \ libnspr4 \ libnss3 \ libxss1 \ libappindicator3-1 \ libasound2 \ libatk-bridge2.0-0 \ libgbm1 \ libxcomposite1 \ libxdamage1 \ libxrandr2 \ xvfb \ --no-install-recommends # 安装 Chrome RUN wget -q -O /tmp/chrome.deb https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb \ apt-get install -y /tmp/chrome.deb \ rm /tmp/chrome.deb # 安装 Python 测试依赖 COPY requirements.txt /tmp/requirements.txt RUN pip install -r /tmp/requirements.txt WORKDIR /app ENV LANGC.UTF-8 \ PYTHONUNBUFFERED1这个镜像把 Chrome、依赖库、Python 测试环境一次性打包CI 里每次跑测试都从干净环境起不会因为服务器上残留的旧版本导致“偶现失败”。7.2 Jenkins 或 GitLab CI 中如何接入不管你在用哪个 CI 平台核心就是“拉代码、起容器、跑测试、收集报告”。以 GitLab CI 为例test: stage: test image: my-chrome-test-image:latest script: - pytest -n 4 --htmlreport.html artifacts: paths: - report.html - screenshot/ when: alwayswhen: always很关键它保证就算测试失败截图和报告也会作为构建产物保存下来否则失败时你什么都看不到只能翻日志。容器内跑 Chrome需要特别注意两件事一是容器默认用户是 root必须加--no-sandbox二是容器默认共享内存太小需要增加--shm-size或者给 Chrome 加--disable-dev-shm-usage。上面 Dockerfile 和 CI 配置配合起来基本不会再遇到这两个问题。7.3 定时任务与监控除了 CI 里触发很多自动化测试还需要定时执行。最简单的落地方式是 crontab30 2 * * * cd /opt/autotest python3 -m pytest /var/log/autotest.log 21如果想更优雅一点可以用 Jenkins 的定时构建、GitLab CI 的 schedule 功能或者接一个监控平台的 webhook。页面监控类的任务我会把失败截图和错误日志直接推送到企业微信或钉钉机器人一句话总结就是当用例失败时第一时间让相关负责人看到。7.4 日志保留与告警策略无头环境下最容易出现的问题就是“测试挂了但你不知道”。所以我的建议是每次执行都要把报告和截图保留到固定目录保留最近 7 天或 30 天的结果超过时间的自动清理连续失败或者失败率超过阈值时触发告警通知。现在很多团队会把自动化测试结果接入 Allure、Jenkins Report 或自建 Dashboard数据可视化之后出问题的定位速度会快很多。最后再分享一个我自己的经验无图形界面 Linux 上跑 Chrome 自动化最难熬的不是装环境而是参数组合没吃透时出现的各种诡异崩溃。如果你在测试过程中遇到 Chrome 闪退、页面空白、driver 版本对不上不要急着怀疑代码先把 Chrome 单独跑起来再用最简单的 Selenium 脚本跑通最后逐步加参数。这种“从最简环境开始验证”的排错思路能帮你节省大量时间。