Selenium的底层原理

Selenium 底层主要依赖于 WebDriver 协议（即 W3C WebDriver 规范，早期也有 JSON Wire Protocol）来实现对浏览器的远程控制，其核心架构可以分为以下几层：

1. Selenium 客户端（Client Library）

   • 支持多种语言（Java、Python、C#、JavaScript 等）。

   • 提供了一套统一的 API，让测试脚本（如 driver.find_element(...)、driver.click()）可以以语言原生的方式调用。

   • 客户端发送的每一个操作都会被封装成一个 HTTP 请求（JSON 格式），通过 HTTP Connector 发往对应的浏览器驱动。

2. WebDriver 协议（W3C WebDriver / JSON Wire Protocol）

   • 定义了“客户端 → 驱动”之间所有命令的格式和路由，包括元素定位、页面导航、脚本执行等。

   • 每个命令都是一个 HTTP 请求，路径类似 /session/{sessionId}/element/{elementId}/click，请求体里是 JSON 参数。

   • 驱动收到 HTTP 请求后，解析出命令类型和参数，然后执行相应的操作。

3. 浏览器驱动（Browser Driver）

   • 每种浏览器都有专属的驱动程序：ChromeDriver、GeckoDriver（Firefox）、EdgeDriver、IEDriver 等。

   • 驱动本质上是一个 HTTP 服务进程，监听来自客户端的 WebDriver 协议请求。

   • 驱动内部与浏览器进行通信 — 有的通过浏览器提供的 DevTools 协议（如 Chrome DevTools Protocol，CDP），有的通过浏览器自身的自动化接口（如 Firefox 的 Marionette）。

4. 浏览器自动化接口

   • Chrome：ChromeDriver 调用底层的 CDP，实现页面元素查找、事件触发、网络拦截等。

   • Firefox：GeckoDriver 则通过 Marionette 协议，向浏览器内置的自动化模块发送命令。

   • 其他浏览器：各自提供类似接口，或通过插件/扩展形式加载自动化脚本。

5. 执行流程示例

   1. 客户端脚本调用 driver.get("https://example.com")。

   2. 客户端库将该调用转换成一个 HTTP POST 请求：

      POST /session/{sessionId}/url
      { "url": "https://example.com" }
      

   3. 浏览器驱动（如 ChromeDriver）接收请求，解析后通过 CDP 命令告诉 Chrome 打开页面。

   4. Chrome 完成导航后，驱动返回一个 HTTP 响应给客户端，客户端继续后续操作。

6. 并行/分布式执行（Selenium Grid）

   • Selenium Grid 把上述架构扩展为分布式系统：一个 Hub 接收测试请求，分发给不同 Node（各自运行一个或多个浏览器驱动实例）。

   • Hub 与 Node 之间依然通过 WebDriver 协议通信，只是多了注册、心跳、能力匹配等管理逻辑。

7. Selenium RC（历史）

   • Selenium 1.0（RC）阶段，使用了一个名为 “Selenium Core” 的 JavaScript 库注入到浏览器页面里，通过 DOM 操作和 JS 事件模拟实现自动化，受限于同源策略，需要启动一个跨域代理服务器。

   • 后来被 WebDriver 模型取代，因为 WebDriver 不注入脚本，只通过浏览器自身的自动化接口，可靠性和性能更好。

总结： Selenium 底层核心依赖

• 客户端库 → 封装 API & 生成 HTTP/JSON 请求

• WebDriver 协议 → 标准化命令格式（W3C WebDriver / JSON Wire Protocol）

• 浏览器驱动 → HTTP 服务 → 转发到浏览器自动化接口（CDP、Marionette 等）

• 浏览器自动化接口 → 浏览器内部执行对应操作，并回传结果

通过这一“堆栈式”架构，Selenium 才能以语言无关、浏览器无关的方式，提供统一且高效的 Web 自动化能力。