Selenide+Selenoid：基于Docker构建稳定、可复现的UI自动化测试环境

1. 项目概述

如果你正在为UI自动化测试的稳定性头疼，特别是那些在本地跑得好好的，一上CI/CD流水线就随机失败的测试用例，那你来对地方了。今天要聊的，就是如何用Selenide和Selenoid这套组合拳，把UI测试稳稳地装进Docker容器里运行。这不仅仅是换个运行环境那么简单，它解决的是测试环境一致性这个老大难问题。想象一下，你再也不用在团队里喊“在我机器上是好的啊”，因为从你的笔记本到公司的Jenkins服务器，再到任何一台新上线的构建机，测试都在完全相同的浏览器环境中执行。Selenide以其简洁的API著称，让写测试代码像写自然语言一样流畅；而Selenoid则是一个基于Docker的Selenium Grid实现，专门用于按需启动和管理浏览器容器。把它们俩集成起来，意味着你可以用最优雅的代码，驱动最隔离、最可控的浏览器实例。无论你是前端开发想验证交互，还是测试工程师要搭建自动化流水线，这套方案都能让你从环境依赖的泥潭中彻底解脱出来，专注于测试逻辑本身。接下来，我会带你从零开始，一步步搭建起这个强大的测试基础设施。

2. 核心架构与工具选型解析

2.1 为什么是Selenide + Selenoid？

在UI自动化领域，选择工具链就像组装一台赛车，每个部件都要各司其职且配合默契。单独使用Selenium WebDriver就像给你一套基础的发动机和底盘，功能强大但需要你事无巨细地组装和调试。而Selenide可以理解为在这套底盘之上，封装了一个智能驾驶舱。它内置了智能等待、简洁的定位器语法、自动截图和日志，把WebDriver那些繁琐的细节都隐藏了起来。你用两三行Selenide代码就能完成原来需要十来行Selenium代码才能搞定的操作，并且稳定性大大提升，因为它帮你处理了大部分异步加载和元素状态判定的问题。

那么，有了好“车”，还需要好的“赛道”和“后勤”。这就是Selenoid出场的原因。传统的Selenium Grid或者直接本地启动浏览器，存在几个致命伤：浏览器版本和驱动难以统一管理；测试残留（如Cookies、缓存）可能影响后续用例；并行执行时资源竞争和隔离性差。Selenoid的核心理念是“一个测试，一个容器”。它利用Docker，为每一个测试会话启动一个全新的、纯净的浏览器容器。测试结束后，容器连同里面所有的临时数据被直接销毁，下一个测试又是一个全新的开始。这种彻底的隔离性，是测试稳定性的基石。

两者的结合，形成了一个完美的闭环：Selenide提供优雅、稳定的测试脚本编写体验，而Selenoid提供纯净、一致、可弹性伸缩的运行时环境。你写的测试用例，从此具备了在任何支持Docker的宿主机上“开箱即用”的能力。

2.2 Docker在此方案中的核心角色

Docker在这里远不止是一个“可选项”，而是整个架构的基石。很多人对Docker的理解还停留在“轻量级虚拟机”，但在这个场景下，它的核心价值是标准化交付物（镜像）和资源隔离。

首先，浏览器环境镜像化。Selenoid官方维护了一系列浏览器镜像（如selenoid/chrome:latest,selenoid/firefox）。这些镜像里不仅包含了特定版本的浏览器（如Chrome 120.0），还预置了匹配版本的WebDriver（如ChromeDriver）以及一个轻量级的VNC服务器（用于实时查看测试过程）。这意味着，你定义的“测试环境”不再是一串需要手动安装的说明书，而是一个不可变的、版本化的镜像文件。今天跑测试用的是selenoid/chrome:120.0，一个月后跑，还是完全一样的120.0版本，没有任何隐性的依赖升级或系统更新带来的破坏。

其次，隔离性与并行化。Docker容器为每个测试提供了独立的文件系统、网络命名空间和进程空间。两个同时运行的测试，即使操作同一个网址，它们的Cookie、LocalStorage也是完全隔离的，绝不会相互干扰。这为实现安全、高效的并行测试（无论是同一个用例的多数据驱动，还是不同用例集的并发执行）提供了底层保障。你只需要在Selenoid配置中指定允许的并发容器数量，它就会自动管理这些容器的生命周期。

最后，与CI/CD的无缝集成。现代CI/CD工具（如Jenkins, GitLab CI, GitHub Actions）对Docker都有原生支持。你可以轻易地在Pipeline中定义一个步骤：“启动Selenoid服务 -> 运行Selenide测试套件 -> 生成报告”。整个测试环境作为代码（Infrastructure as Code）的一部分，和你的应用代码一起被版本管理，实现了真正的持续测试。

注意：虽然Docker带来了环境一致性，但也要注意宿主机内核与Docker的兼容性。特别是在Windows和macOS上使用Docker Desktop时，需要确保已启用虚拟化（如Hyper-V或WSL2后端）。如果遇到“virtualization support not detected”这类错误，通常需要进入BIOS中开启CPU的虚拟化技术（如Intel VT-x或AMD-V）。

3. 环境搭建与Selenoid部署

3.1 Docker与Docker Compose安装要点

工欲善其事，必先利其器。部署Selenoid的前提是有一个可用的Docker环境。虽然“docker安装”是个高频搜索词，但不同操作系统下的细节陷阱不少。

对于Linux（如Ubuntu/CentOS），建议使用官方仓库安装，避免使用年代久远的系统自带版本。在Ubuntu上，关键步骤是添加Docker的官方GPG密钥和稳定的软件源，安装docker-ce和docker-compose-plugin（现在Docker Compose已作为插件集成）。安装后，务必将当前用户加入docker用户组（sudo usermod -aG docker $USER），然后需要重新登录，这样才能不加sudo直接运行docker命令，这对后续的自动化脚本至关重要。

对于Windows/macOS，推荐使用Docker Desktop。它提供了一个集成的图形界面和命令行环境。安装时，Windows用户需注意：如果系统提示“WSL2 installation is incomplete”，则需要先安装WSL2内核更新包。我更推荐在Windows上配置Docker Desktop使用WSL2后端，而不是传统的Hyper-V，因为WSL2在文件I/O性能和资源占用上更有优势，而且能更好地与Windows文件系统互通。安装完成后，在设置（Settings）的“Resources” -> “WSL Integration”中，为你常用的Linux发行版（如Ubuntu）启用集成。

验证安装是否成功，打开终端（在Windows上可以是PowerShell或WSL终端），运行：

docker --version docker-compose --version docker run hello-world

如果能看到版本信息和一个“Hello from Docker!”的提示，说明基础环境就绪。

3.2 部署Selenoid的两种姿势

Selenoid的部署非常灵活，你可以根据团队规模和技术偏好选择。

姿势一：使用Docker CLI快速启动（适合尝鲜与简单场景）

这是最简单的方式。首先，你需要一个配置文件来告诉Selenoid可以使用哪些浏览器镜像。创建一个名为browsers.json的文件：

{ "chrome": { "default": "latest", "versions": { "latest": { "image": "selenoid/chrome:latest", "port": "4444", "path": "/" } } }, "firefox": { "default": "latest", "versions": { "latest": { "image": "selenoid/firefox:latest", "port": "4444", "path": "/wd/hub" } } } }

这个文件定义了两种浏览器，它们的默认版本和对应的Docker镜像。然后，使用一条命令启动Selenoid：

docker run -d --name selenoid \ -p 4444:4444 \ -v /var/run/docker.sock:/var/run/docker.sock \ -v `pwd`/browsers.json:/etc/selenoid/browsers.json \ aerokube/selenoid:latest-release

这条命令做了几件事：-d表示后台运行；-p 4444:4444将容器内的Selenium服务器端口映射到宿主机；最关键的是-v /var/run/docker.sock:/var/run/docker.sock，这赋予了Selenoid容器在宿主机上启动和管理其他Docker容器（即浏览器容器）的能力；最后一个-v将我们刚创建的配置文件挂载到容器内。

启动后，访问http://localhost:4444/status，你应该能看到一个简单的JSON响应，显示Selenoid正在运行，并且加载了你的浏览器配置。

姿势二：使用Docker Compose编排（推荐用于生产与团队协作）

对于正式项目，我强烈推荐使用Docker Compose。它用一个声明式的YAML文件描述整个服务栈，包括Selenoid、Selenoid UI（一个Web管理界面）以及它们之间的网络关系，易于版本控制和一键启停。

创建一个docker-compose.yml文件：

version: '3' services: selenoid: image: aerokube/selenoid:latest-release container_name: selenoid network_mode: bridge ports: - "4444:4444" volumes: - "./browsers.json:/etc/selenoid/browsers.json" - "/var/run/docker.sock:/var/run/docker.sock" - "./video:/opt/selenoid/video" # 可选：挂载视频录制目录 environment: - OVERRIDE_VIDEO_OUTPUT_DIR=/opt/selenoid/video command: ["-conf", "/etc/selenoid/browsers.json", "-video-output-dir", "/opt/selenoid/video", "-limit", "10"] selenoid-ui: image: aerokube/selenoid-ui:latest container_name: selenoid-ui network_mode: bridge links: - selenoid ports: - "8080:8080" command: ["--selenoid-uri", "http://selenoid:4444"]

在这个配置里，我们定义了两个服务。selenoid服务与之前CLI启动类似，但通过command参数指定了配置文件和容器并发数限制（-limit 10）。selenoid-ui服务是Selenoid的Web管理界面，通过--selenoid-uri参数连接到Selenoid服务。links指令确保在UI容器内，可以用主机名selenoid访问到Selenoid服务。

在包含docker-compose.yml和browsers.json的目录下，运行：

docker-compose up -d

访问http://localhost:8080，你就能看到一个漂亮的Web界面，可以实时查看会话状态、浏览器使用情况，甚至手动启动浏览器会话和查看VNC实时画面。

实操心得：在团队服务器上部署时，我习惯将browsers.json、docker-compose.yml以及用于挂载的目录（如./video）放在一个统一的版本控制仓库里。这样，任何环境变更（比如升级Chrome版本）都通过修改配置文件并提交代码来完成，然后通过CI/CD流水线自动部署，实现了测试基础设施的代码化管理。

4. Selenide项目配置与核心集成

4.1 初始化Selenide项目与依赖配置

现在，我们来搭建测试脚本这一边。假设你使用Maven管理Java项目（Gradle的配置逻辑类似）。在你的pom.xml中，需要引入Selenide的核心依赖。我建议使用最新的稳定版本，并搭配TestNG或JUnit作为测试运行框架。

<dependencies> <!-- Selenide 核心依赖 --> <dependency> <groupId>com.codeborne</groupId> <artifactId>selenide</artifactId> <version>7.0.4</version> <!-- 请检查最新版本 --> <scope>test</scope> </dependency> <!-- 测试框架，以TestNG为例 --> <dependency> <groupId>org.testng</groupId> <artifactId>testng</artifactId> <version>7.8.0</version> <scope>test</scope> </dependency> <!-- 日志框架，方便排查问题 --> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-simple</artifactId> <version>2.0.9</version> <scope>test</scope> </dependency> </dependencies>

引入依赖后，最关键的一步是配置Selenide，让它知道远程的WebDriver服务器（也就是我们刚启动的Selenoid）在哪里。这通常在测试基类（BaseTest）的@BeforeSuite或@BeforeClass方法中完成，也可以通过系统属性在运行时传入。我更喜欢使用系统属性，因为它更灵活，可以方便地在IDE、Maven命令行和CI服务器上切换配置。

核心配置代码如下：

import com.codeborne.selenide.Configuration; import org.testng.annotations.BeforeSuite; public class BaseTest { @BeforeSuite public void setupSelenoid() { // 1. 设置远程WebDriver地址，指向Selenoid Configuration.remote = "http://localhost:4444/wd/hub"; // 如果Selenoid部署在其他机器，替换为对应的IP或主机名 // 2. 设置浏览器类型，必须与browsers.json中定义的key匹配 Configuration.browser = "chrome"; // 也可以设置为 "firefox", "edge" 等 // 3. 设置浏览器版本，'latest' 或具体版本号如 '120.0' Configuration.browserVersion = "latest"; // 4. 启用VNC，允许在Selenoid UI中实时观看测试过程 Configuration.browserCapabilities.setCapability("enableVNC", true); // 5. 启用视频录制，测试失败时自动保存视频（需Selenoid配置支持） Configuration.browserCapabilities.setCapability("enableVideo", true); // 6. 设置测试名称，便于在Selenoid UI中识别会话 Configuration.browserCapabilities.setCapability("name", "My Awesome Test Suite"); // 7. Selenoid专用：告诉Selenoid使用我们提供的Capabilities创建容器 Configuration.browserCapabilities.setCapability("selenoid:options", Map.<String, Object>of( "enableVNC", true, "enableVideo", true, "videoName", "my_test.mp4", "videoScreenSize", "1920x1080" )); // 8. 调整Selenide超时设置，适应远程执行可能存在的网络延迟 Configuration.timeout = 10000; // 元素查找超时（毫秒） Configuration.pageLoadTimeout = 30000; // 页面加载超时 } }

这段配置是连接Selenide与Selenoid的桥梁。Configuration.remote是核心，指向Selenoid的WebDriver接口。enableVNC和enableVideo这两个能力（Capability）是Selenoid的特色功能，强烈建议开启，它们对于调试和记录测试过程是无价之宝。

4.2 编写你的第一个容器化UI测试用例

配置好之后，编写测试用例的体验和本地运行Selenide几乎一模一样。Selenide的流畅API设计得以充分体现。

下面是一个访问搜索网站并执行搜索的简单测试示例：

import com.codeborne.selenide.Condition; import com.codeborne.selenide.Selenide; import org.testng.annotations.Test; import static com.codeborne.selenide.Selenide.*; public class SearchTest extends BaseTest { @Test public void userCanSearchWithSelenoid() { // 打开网页 - 注意：这里用的是相对路径，Selenide会基于Configuration.baseUrl拼接 // 为了清晰，我们直接用绝对URL open("https://www.bing.com"); // 使用Selenide简洁的定位器语法找到搜索框并输入 // `$` 方法相当于 `find`，支持CSS选择器 $("#sb_form_q").setValue("Selenoid Docker").pressEnter(); // 断言搜索结果页面包含预期文本 // `should` 方法内置了智能等待，无需编写显式的Thread.sleep或WebDriverWait $("#b_results").shouldHave(Condition.text("Selenoid")); // 我们还可以利用Selenoid的能力，给测试打个标签，方便在UI界面筛选 // 这个信息会通过`name` capability传递，并显示在Selenoid UI中 Selenide.sessionStorage().setItem("testTag", "integration"); } }

运行这个测试。当你执行时，观察终端和Selenoid UI (http://localhost:8080)。你会看到Selenoid UI的“Sessions”页面上出现了一个新的会话，浏览器类型、版本、测试名称（namecapability）一目了然。如果测试失败，你可以点击会话的“VNC”按钮，直接看到浏览器挂掉时的最后画面；如果配置了视频录制，还可以下载完整的测试过程录像。这种可观测性，是传统本地运行模式难以比拟的。

注意事项：第一次运行可能会稍慢，因为Selenoid需要从Docker Hub拉取浏览器镜像（如selenoid/chrome:latest）。拉取完成后，镜像会缓存在本地，后续启动就非常快了。你可以通过docker images命令查看已拉取的镜像。如果遇到网络问题拉取镜像慢，可以考虑配置Docker镜像加速器，或者将常用镜像提前导入到私有镜像仓库。

5. 高级配置与生产级优化

5.1 多浏览器与版本矩阵测试

在实际项目中，我们通常需要覆盖多个浏览器（Chrome, Firefox, Edge）及其不同版本。Selenoid + Selenide 可以很优雅地实现这一点。关键在于browsers.json配置文件和测试运行时的参数化。

首先，扩展你的browsers.json，定义多个版本：

{ "chrome": { "default": "120.0", "versions": { "120.0": { "image": "selenoid/chrome:120.0", "port": "4444", "path": "/" }, "119.0": { "image": "selenoid/chrome:119.0", "port": "4444", "path": "/" } } }, "firefox": { "default": "latest", "versions": { "latest": { "image": "selenoid/firefox:latest", "port": "4444", "path": "/wd/hub" } } }, "opera": { "default": "latest", "versions": { "latest": { "image": "selenoid/opera:latest", "port": "4444", "path": "/" } } } }

然后，在你的测试框架中，使用数据提供者（DataProvider）来参数化测试。以TestNG为例：

import org.testng.annotations.DataProvider; import org.testng.annotations.Test; public class CrossBrowserTest extends BaseTest { @DataProvider(name = "browserProvider") public Object[][] provideBrowsers() { return new Object[][]{ {"chrome", "120.0"}, {"chrome", "119.0"}, {"firefox", "latest"} }; } @Test(dataProvider = "browserProvider") public void testOnMultipleBrowsers(String browser, String version) { // 动态覆盖全局配置 Configuration.browser = browser; Configuration.browserVersion = version; // 可以在测试名中体现当前运行的浏览器，方便报告查看 Configuration.browserCapabilities.setCapability("name", "CrossBrowserTest - " + browser + " " + version); // 以下是实际的测试步骤 open("https://example.com"); // ... 你的测试断言 } }

当你运行这个参数化测试时，TestNG会依次用不同的(browser, version)组合来执行测试方法。Selenoid会根据每次请求的browserName和version能力，从browsers.json中找到对应的镜像，启动一个全新的容器来执行该次测试。这样，你就能用一套代码，轻松完成跨浏览器兼容性测试。

5.2 性能调优与资源管理

当测试套件规模变大，并行执行成为必然。Selenoid的-limit参数控制了最大并发容器数。你需要根据宿主机（运行Docker的机器）的资源配置这个值。

一个简单的估算方法是：每个浏览器容器（以Chrome为例）在运行时可能需要300-500MB内存。如果你的宿主机有8GB内存，扣除系统和其他服务，假设预留6GB给Selenoid，那么理论上可以支持6000MB / 400MB ≈ 15个并发容器。但实际中，我建议设置得保守一些，比如-limit 10，为系统留出缓冲空间，避免内存耗尽导致容器被Docker守护进程强制杀死（OOM Killer）。

你可以在docker-compose.yml中为Selenoid服务添加资源限制，更精细地控制：

services: selenoid: ... deploy: # 注意：`deploy` 仅在Docker Swarm模式下生效，单机Compose可使用`resources` resources: limits: cpus: '2' # 限制使用2个CPU核心 memory: 4G # 限制使用4GB内存

对于单机Docker Compose，可以使用resources字段：

services: selenoid: ... mem_limit: 4g cpus: 2.0

此外，Selenoid默认会在测试结束后立即删除容器。对于调试来说，你可能希望保留失败测试的容器。可以通过在browsers.json的某个浏览器版本配置中添加"env": ["SE_SCREEN_WIDTH=1920", "SE_SCREEN_HEIGHT=1080"]来设置容器内的屏幕分辨率，或者通过Selenoid的启动参数-session-attempt-timeout来调整会话创建的超时时间。

视频录制优化：启用enableVideo非常有用，但视频文件可能很大。Selenoid支持在测试通过后自动删除视频，只保留失败测试的视频。这需要在Selenoid启动命令中添加-video-output-dir指定目录，并通过能力指定"videoName": "test.mp4"。你还可以通过"videoScreenSize": "1280x720"来降低录制分辨率以节省空间和编码时间。

5.3 与CI/CD流水线集成

将这套方案集成到CI/CD中是实现价值最大化的关键。以GitHub Actions为例，一个典型的.github/workflows/ui-tests.yml工作流文件可能长这样：

name: UI Tests with Selenoid on: [push, pull_request] jobs: test: runs-on: ubuntu-latest services: # 启动Selenoid服务 selenoid: image: aerokube/selenoid:latest-release options: >- --privileged -v /var/run/docker.sock:/var/run/docker.sock -v ${{ github.workspace }}/browsers.json:/etc/selenoid/browsers.json ports: - 4444:4444 steps: - uses: actions/checkout@v3 - name: Set up JDK uses: actions/setup-java@v3 with: java-version: '11' distribution: 'temurin' - name: Cache Maven dependencies uses: actions/cache@v3 with: path: ~/.m2 key: ${{ runner.os }}-m2-${{ hashFiles('**/pom.xml') }} restore-keys: ${{ runner.os }}-m2 - name: Run UI Tests run: mvn clean verify env: # 通过环境变量传递Selenoid地址，测试代码中读取 SELENOID_REMOTE_URL: http://localhost:4444/wd/hub # 或者使用Maven系统属性 # MAVEN_OPTS: -Dremote.webdriver.url=http://localhost:4444/wd/hub continue-on-error: true # 即使测试失败，也继续执行后续步骤（如下载视频） - name: Download test artifacts (videos, logs) if: always() # 无论测试成功失败都执行 run: | mkdir -p test-artifacts # 这里假设Selenoid视频挂载到了宿主机某个目录，实际情况可能需要从Selenoid容器内复制 # 更常见的做法是使用Selenoid的“挂载卷”将视频输出到工作区，或使用S3等存储后端 docker cp selenoid:/opt/selenoid/video ./test-artifacts/ 2>/dev/null || true - uses: actions/upload-artifact@v3 if: always() with: name: ui-test-artifacts path: test-artifacts/

这个工作流定义了：在代码推送或PR时触发；启动一个Selenoid服务容器；配置Java环境；运行Maven测试（会触发Selenide测试）；最后，无论测试成功与否，都尝试下载测试过程中录制的视频作为产物，供后续分析。这样，每次代码变更都能自动得到一份跨浏览器环境的UI测试报告。

6. 常见问题排查与调试技巧实录

6.1 连接与会话创建失败

这是集成初期最常见的问题。当你运行测试，但Selenoid UI里没有出现新会话，或者测试报错org.openqa.selenium.WebDriverException: Unable to create new remote session。

排查思路：

1. 检查Selenoid服务状态：首先访问http://selenoid-host:4444/status。如果返回一个包含浏览器列表的JSON，说明Selenoid主服务正常。如果无法访问，检查Docker容器是否在运行：docker ps | grep selenoid。
2. 检查浏览器镜像：Selenoid的日志会详细记录它尝试启动容器的过程。通过docker logs -f selenoid查看实时日志。常见的错误是“No such image: selenoid/chrome:120.0”。这说明你的browsers.json中指定的镜像在本地不存在。你需要确保该镜像已被拉取，或者版本号书写正确。可以使用docker pull selenoid/chrome:120.0手动拉取。
3. 检查Docker Socket挂载：这是权限问题的重灾区。Selenoid容器需要访问宿主机的Docker守护进程（通过/var/run/docker.sock）来启动浏览器容器。确保运行Selenoid的命令或Compose文件中包含了正确的卷挂载：-v /var/run/docker.sock:/var/run/docker.sock。在Linux上，还要确保运行Docker命令的用户有权限读写这个socket文件。
4. 检查网络连接：确保你的测试代码（运行在CI Runner或你的本地IDE）能够通过网络访问到Selenoid服务的4444端口。如果Selenoid运行在远程服务器或Docker虚拟网络内，可能需要配置防火墙或网络规则。
5. 核对Capabilities：在Selenoid UI中手动启动一个会话（Manual Run），查看它生成的Capabilities JSON。与你测试代码中通过Selenide设置的能力进行对比。特别注意browserName和version必须与browsers.json中的定义完全匹配（大小写敏感）。

6.2 测试执行缓慢或超时

测试在容器中运行比本地慢，或者经常遇到TimeoutException。

优化策略：

1. 镜像预热：第一次拉取和启动镜像总是最慢的。可以在CI流水线开始，或服务器启动后，预先拉取所有需要用到的浏览器镜像：docker pull selenoid/chrome:latest && docker pull selenoid/firefox:latest。
2. 调整超时时间：远程执行必然有网络开销。适当增加Selenide的全局超时设置。将Configuration.timeout从默认的4000毫秒增加到10000毫秒。同时，也要调整页面加载超时Configuration.pageLoadTimeout。
3. 使用“会话重用”模式（高级）：Selenoid支持一种实验性的“会话重用”模式，它不会在测试结束后立即销毁容器，而是保留一段时间供可能的下一个测试使用。这可以显著减少频繁创建容器的开销。但这会破坏测试的隔离性，需谨慎评估。可以通过在browsers.json中添加"sessionTimeout": "5m"来配置。
4. 检查宿主机资源：使用docker stats命令监控容器运行时的CPU和内存使用情况。如果宿主机资源（特别是内存）不足，Docker会进行内存交换（Swap），导致性能急剧下降。确保为宿主机分配了足够资源，并合理设置Selenoid的-limit参数。
5. 视频录制开销：视频录制会消耗额外的CPU和磁盘I/O。如果测试非常密集且不需要每次录制视频，可以考虑仅对失败测试录制视频。这可以通过在测试监听器（Test Listener）中动态设置enableVideo能力来实现，或者在Selenoid端配置视频仅对失败会话保存。

6.3 VNC无法连接或黑屏

在Selenoid UI中点击VNC按钮，无法连接或看到黑屏。

诊断步骤：

1. 确认VNC已启用：检查测试代码中是否设置了enableVNC: true能力。没有这个能力，Selenoid不会在浏览器容器中启动VNC服务器。
2. 检查端口映射：Selenoid UI通过内部网络连接到Selenoid，然后Selenoid再连接到浏览器容器的VNC端口（通常是5900）。如果Selenoid UI和Selenoid不在同一个Docker网络，或者网络配置有误，连接会失败。在Docker Compose中，确保它们使用相同的网络（如network_mode: bridge）并通过links或网络别名正确连接。
3. 浏览器镜像问题：并非所有Selenoid浏览器镜像都默认包含VNC。确保你使用的镜像标签是支持VNC的。通常，selenoid/chrome和selenoid/firefox的默认标签都包含。如果你使用了其他来源的基础镜像，可能需要自行安装tigervnc或novnc组件。
4. 防火墙/安全组：如果Selenoid部署在云服务器上，确保安全组规则允许VNC端口的入站流量（虽然VNC流量通常被Selenoid UI代理，不直接暴露）。

6.4 日志收集与分析

有效的日志是排查问题的生命线。Selenoid生态提供了多层日志：

一个实用的技巧是，在CI流水线中，将所有这些日志（包括Selenoid日志、浏览器容器日志和测试框架日志）收集起来，打包成制品，与测试视频一起存档。当测试失败时，你可以有一个完整的上下文来复现问题。

我个人习惯在测试基类的@AfterMethod（每个测试方法之后）中，如果测试失败，就用Selenide的Screenshots.takeScreenShot()方法截取当前页面，并用PageSource()方法获取页面HTML源码，一并保存到报告目录。结合Selenoid的视频，几乎可以百分之百还原失败现场。

7. 扩展与替代方案探讨

7.1 使用Selenoid UI进行监控与手动测试

Selenoid UI (aerokube/selenoid-ui) 不仅仅是一个监控面板。它的“Capabilities”标签页是一个强大的工具，可以为你生成不同编程语言（Java, Python, C#等）初始化WebDriver会话的代码片段。当你需要快速验证某个浏览器版本或某个能力组合时，可以直接在UI界面上选择浏览器、版本、VNC、视频等选项，然后点击“Create Session”。它会启动一个浏览器容器，并停留在那里60分钟（可配置），你可以手动操作浏览器，进行探索性测试或调试。这对于测试同学快速验证页面在不同浏览器下的渲染效果，或者开发同学调试一个只在特定环境下出现的问题，非常方便。

7.2 从Selenoid扩展到Ggr（负载均衡集群）

当你的测试量非常大，单台机器的资源无法满足并发需求时，就需要考虑分布式执行。Aerokube生态提供了Ggr（Go Grid Router）。你可以将多台安装了Selenoid的机器组成一个集群，然后在前面部署一个Ggr作为负载均衡器和统一入口。测试脚本只需要将Configuration.remote指向Ggr的地址，Ggr会自动将请求路由到集群中空闲的Selenoid节点上。

这种架构的部署稍微复杂一些，需要额外部署Ggr、Ggr UI以及一个用于同步配置的Quota服务。但它带来了水平扩展的能力，你可以通过增加Selenoid节点来线性提升测试并发能力。这对于大型互联网公司每天运行数万次UI测试的场景是必要的。

7.3 与Kubernetes的集成

如果你的基础设施已经容器化并运行在Kubernetes上，那么Selenoid也可以部署在K8s集群中。Aerokube提供了官方的Helm Chart，可以方便地在K8s中部署Selenoid。在K8s中，浏览器容器作为Job或Pod运行，资源调度和生命周期管理由Kubernetes负责，弹性伸缩能力更强。不过，这需要你具备一定的Kubernetes运维知识。一个折中的方案是，在K8s集群外单独维护一个Selenoid Docker主机用于UI测试，也是一种常见的混合架构。

7.4 与其他测试框架的搭配

虽然本文以Selenide（Java）为例，但Selenoid是一个标准的Selenium Grid实现，它兼容任何支持Selenium WebDriver协议的客户端。这意味着你可以用Python的selenium库、JavaScript的WebdriverIO、C#的Selenium.WebDriver等来编写测试，并同样指向Selenoid的远程地址。方案的核心价值——基于Docker的隔离浏览器环境——是语言无关的。选择Selenide，更多的是看中了它在Java生态中提供的语法糖和稳定性增强，你可以根据团队的技术栈灵活选择客户端。