C++ 写 Web 自动化测试？听到这个选题，不少人第一反应是：你是不是拿错键盘了。网上搜自动化测试，十个教程八个在讲 Python，剩下两个在讲 Java。但我在真实项目里确实遇到过这个需求，而且是那种绕不开的情况——整个团队的测试基建、构建流水线、代码资产都是 C++ 的，为了一个 Web 自动化测试引入一套全新语言运行时和依赖链，成本和风险都不小。于是我开始认真研究，C++ 到底能不能干这事，能干到什么程度。
这篇文章就是那段调研和实操的记录。先说结论：C++ 不仅能做 Web 自动化测试，而且只要你理解了 WebDriver 协议的本质，写起来甚至比想象中简单。Selenium 在这里的真正身份，不是一个 C++ 没法用的库，而是一整套围绕 WebDriver 协议的生态工具集。文章会从自动化测试的概念讲起，一路拆到协议级别，再给出一套可复现的 C++ 实现方案，最后是实际用例和排坑经历。无论你是 C++ 后台开发想转测试开发，还是负责人想评估 C++ 测试团队的自动化方案，这篇都能给你一个直接落地的参照。
1. 先搞明白：Web 自动化到底在“自动”什么
1.1 自动化测试不是“自动点鼠标”
一件很反直觉的事：很多人学了 Selenium 的 API，却说不清自动化测试的本质。手工测试的流程很简单——打开浏览器、输入账号密码、点登录、看页面跳转、断言结果。自动化测试要做的，就是把这五个动作全部用代码接管。但难点在于“接管”二字。浏览器是个封闭的图形应用，它不会主动给你提供一套函数接口，你不能像调用 std::vector::push_back 一样直接调页面元素。自动化框架想操作浏览器，必须有一条“正规通道”。
这就像你想控制一台只能插网线的设备，自己却只有 USB 口——技术上行不通。而 WebDriver 协议，就是那条把“网线”转换成“USB”的桥。浏览器厂商（或者第三方驱动实现）在浏览器旁起一个本地服务，把“打开网页”“点击按钮”这些动作做成一个个 HTTP 接口。客户端代码只需要向这个服务发 HTTP 请求，剩下的翻译工作由驱动完成。
1.2 WebDriver 协议才是真正的主角
WebDriver 协议是 W3C 的标准协议，它的通信方式是 HTTP + JSON。浏览器驱动（比如很多人熟知的 ChromeDriver，只是迫于谈及依赖时不得不叫出它的名字）本质是一个本地 HTTP 服务器，默认监听某个端口。自动化脚本发的每一条命令，都是一次标准 HTTP 请求。
以“点击一个按钮”为例，完整的链路是这样的：
- 客户端先发一个 POST 请求，路径是
/session，请求体里带上浏览器参数，驱动收到后启动一个浏览器实例，并返回一个sessionId——可以理解成这次会话的“令牌”。 - 客户端发
POST /session/{sessionId}/element，请求体告诉驱动用什么样的策略去定位元素，比如 CSS 选择器#login-btn。驱动执行后，返回这个元素的唯一引用 ID。 - 客户端再发
POST /session/{sessionId}/element/{elementId}/click，驱动控制浏览器执行点击。
每一条命令都对应一个 HTTP 端点、一个 JSON 请求体、一个 JSON 响应体。这个设计决定了 WebDriver 与语言无关——任何语言，只要会发 HTTP、会解析 JSON，就能驱动浏览器。这也是为什么后文我说 C++ 完全可行。
对不熟悉协议的人来说，Selenium 看起来像一个“可以写.click()的库”。但拆到协议层你会看到，那个库只是把 HTTP 请求封装成了函数调用而已。
1.3 C++ 在这条链路里能站在哪
很多人以为 C++ 没法学 Selenium，是因为没有官方的一等公民客户端。但理解了上面的链路你就会明白：语言本身不是障碍，障碍在于你愿不愿意自己写那层 HTTP 封装。反正我试过之后发现，核心封装代码量不大，几百行就能覆盖高频操作。搞定协议，C++ 的位置就很清楚了——它在“客户端”这一侧，负责发 HTTP 请求、处理 JSON 响应、做断言和报告。
所以本文不打算让你去背某一种语言的 Selenium API，而是带着你从协议出发，在 C++ 环境里把客户端“长出来”。这样即便换浏览器、换驱动、换机器，你的核心代码都不用动。
2. C++ 做 Web 自动化：合理性与方案选型
2.1 为什么非要 C++ 来做
不排除有人是因为好奇才用 C++ 写自动化，但真实项目里选择 C++，理由通常很务实：
- 团队技术栈统一。测试工具链、编译系统、持续集成脚本全是 C++ 体系，为了自动化测试引入 Python 环境意味着多一套维护成本和依赖链。
- 性能敏感场景。比如一次要并发跑几十个浏览器会话，或者测试期间还要同时采集性能数据。C++ 的资源控制能力和并发处理能力在这里有优势。
- 可嵌入已有框架。很多团队有自己的 C++ 测试框架和日志系统，自动化用例如果能直接引用这些基础设施，集成成本最低。
我见过一个场景：测试团队要做一个高频 UI 回归任务，每轮要遍历上千条数据，浏览器会话要反复创建销毁。用脚本语言做也能跑，但调度层和资源回收压力不小，最终他们把 Web 自动化封装成 C++ 组件，直接编排进夜间任务流，稳定性明显好于之前脚本版本的。
2.2 两条可行路线：绑定库 vs 直接协议
C++ 方向接入 Web 自动化，主要有两条路线，我用一张表把核心差异列出来：
| 方案 | 封装程度 | 上手成本 | 可控性 | 维护风险 |
|---|---|---|---|---|
| 社区绑定库 | 高，像用 Python 一样写 | 低，几分钟可用 | 低，内部实现不透明 | 依赖库更新节奏，新特性滞后 |
| 基于 WebDriver 协议自封装 | 中，需自己处理 HTTP/JSON | 中，需要理解协议 | 高，每层都可控 | 自己维护，核心代码稳定 |
绑定库的好处是它已经把“发 HTTP、收 JSON、拆字段”这些事做完了，你可以直接写业务步骤。但我在实际评估中发现，不少 C++ 绑定库有几个共性痛点：跨平台编译配置繁琐，宏和模板复杂，报错信息不直观，而且某些 WebDriver 新端点支持滞后。你想调一个新功能，发现库根本不支持，得等社区更新，这个体验非常痛苦。
所以我的建议是：如果你的需求比较基础，而且团队看重短期效率，可以选绑定库；但如果你想长期稳定、想深度定制，或者想彻底理解 Selenium 的运作方式，那就走协议自封装路线。后文我会按自封装路线展开，因为它的知识点可以完全迁移到任何语言，价值最大。
2.3 需要准备的基础组件清单
走协议路线，你需要的组件比想象中少：
- 一个浏览器实例。Chrome、Firefox 或者 Chromium 系都行。
- 对应的浏览器驱动。必须注意版本匹配关系，驱动版本跟浏览器主版本不匹配时，创建会话会直接失败，这是最常见的坑。
- 一个 HTTP 客户端。任选你项目里已有的，或者用标准库外的轻量实现。只要能发 GET/POST，能带请求头和 body，能把响应体拿到字符串里，就完全够用。
- 一个 JSON 解析器。WebDriver 请求和响应全是 JSON，你需要把它转成能取字段的对象。选一个轻量、头文件化的成熟库就行。
- C++ 标准尽量不低于 C++14，方便用字符串处理和简单数据结构。
准备工作的顺序建议是：先把浏览器驱动下载好，手动启动它，然后在浏览器里输入驱动提供的连接地址，你能看到一个类似 “a maybe not so harmless message” 之类的提示页，说明驱动服务起来了。我用一条命令示意，不同驱动参数大同小异：
# 启动驱动并指定监听端口，默认端口因驱动而异 driver_binary --port=9515启动后，用任意 HTTP 工具向http://127.0.0.1:9515/status发一个 GET 请求，返回 JSON 说明就绪状态。这一步能提前验证网络连通性和驱动可用性，后续所有操作都建立在这个本地服务之上。
3. 手写一个最小可用的 C++ WebDriver 客户端
3.1 从 POST /session 开始：建立浏览器会话
整个自动化流程的第一步永远是创建会话。这一步的 HTTP 请求如下：
POST /session HTTP/1.1 Content-Type: application/json { "capabilities": { "alwaysMatch": { "browserName": "chrome" } } }驱动收到后，如果确认浏览器可用，会启动一个浏览器进程，并返回类似这样的响应：
{ "value": { "sessionId": "a1b2c3d4", "capabilities": { "browserName": "chrome", "browserVersion": "120.0" } } }sessionId必须保存好，后续每个请求的 URL 路径里都要带上它。这就像一个会话令牌，驱动靠它找到对应的浏览器实例。删除会话很简单，发一个DELETE /session/{sessionId}，驱动会关闭浏览器并释放资源。不要小看这个收尾动作，跑自动化任务时开一堆不关闭的浏览器进程，内存迟早被吃光。
3.2 元素定位与操作：搞定 findElement 和 click
拿到会话后，最常用的一步就是定位元素。定位策略五花八门，但强烈建议优先用 CSS 选择器，因为它在 C++ 场景下最不需要额外依赖。XPath 虽然灵活，但是解析和转义坑比较多，能避开就避开。
定位一个元素，发出这样的请求：
POST /session/{sessionId}/element HTTP/1.1 Content-Type: application/json { "using": "css selector", "value": "#login-btn" }响应里会带一个元素引用 ID。注意 W3C 规范里，这个 ID 藏在一个很长的键名之下，比如果你直接用 JSON 解析库取字段，得知道那个键名是什么。各驱动实现基本遵循这个结构，我在这里给你写出来：
{ "value": { "element-6066-11e4-a52e-4f735466cecf": "some-element-id" } }实际编码时，别假设所有驱动返回的键名完全一致，建议先从 value 对象里遍历，取第一个字符串值作为元素 ID。这样可以规避不同实现间的差异。
拿到元素 ID，点击就简单了：
POST /session/{sessionId}/element/{elementId}/click HTTP/1.1如果元素被其他层遮挡、不可见、或者被禁用，驱动会返回一个错误响应。这个错误响应结构是标准化的，错误码和 message 都会写明，方便定位。
3.3 把客户端封装成三个层次
协议理解了，代码组织也有规律。我通常把实现拆成三层，这样后续扩展能力很快：
- 底层是 HTTP 通信层，负责发请求、带 headers、收响应体字符串。
- 中间是 WebDriver 协议层，每个方法对应一个 HTTP 端点，内部拼 URL、发送、解析 JSON。
- 上层是业务封装层，面向用例，提供语义化的操作，比如
LoginPage().InputAccount(...)。
用一个简化骨架说明中间层长什么样：
// session.h - 只关注协议端点，不涉及具体业务 class WebDriverClient { public: WebDriverClient(const std::string& driverUrl); std::string CreateSession(); // POST /session void DeleteSession(const std::string& sid); // DELETE /session/{sid} std::string FindElement(const std::string& sid, const std::string& cssSelector); void Click(const std::string& sid, const std::string& elementId); void SendKeys(const std::string& sid, const std::string& elementId, const std::string& text); std::string GetText(const std::string& sid, const std::string& elementId); void Navigate(const std::string& sid, const std::string& url); private: std::string MakeUrl(const std::string& path) const; std::string driverUrl_; };实现FindElement的过程很有代表性：把 CSS 选择器放进 JSON 请求体，发起 POST，拿响应体之后解析出元素 ID 返回。整段逻辑大概也就十几行。日志一定要记，把每次请求的 URL、请求体、响应体都打出来，后面排查问题会省掉大量时间。
3.4 一个完整的单元函数：搜索关键词
到这里，我们已经具备写一个最小可用用例的条件。举个具体场景：打开某个搜索页面，输入关键词，点搜索按钮，然后读取结果列表第一条文本。核心流程的 C++ 代码大概长这样：
void SearchKeyword(WebDriverClient& client, const std::string& sid) { // 1. 打开搜索页面 client.Navigate(sid, "https://example.com/search"); // 2. 定位输入框，输入关键词 auto input = client.FindElement(sid, "#search-input"); client.SendKeys(sid, input, "C++ WebDriver"); // 3. 点击搜索按钮 auto btn = client.FindElement(sid, "#search-btn"); client.Click(sid, btn); // 4. 读取第一个结果的标题 auto firstResult = client.FindElement(sid, ".result-item:nth-child(1) .title"); std::string title = client.GetText(sid, firstResult); assert(title.find("C++ WebDriver") != std::string::npos); }细心的话会发现，步骤 3 到步骤 4 之间少了一个关键环节：页面加载和渲染需要时间。如果刚点完搜索按钮就立刻去定位结果，极大概率会得到“元素不存在”的错误。这就引出了 Web 自动化里一个永恒的话题：等待策略。
4. 实战：登录场景的自动化用例编写
4.1 用例设计与三要素
从单个函数往上升一级，一个完整用例要具备三个要素：准备（把自己置于可测试的状态）、操作（执行被测试用户路径）、断言（验证结果是否符合预期）。
拿一个登录页面举例。准备阶段是打开登录页面；操作阶段是输入账号、密码，点击登录；断言阶段是等待跳转，然后检查页面里是否出现用户昵称或欢迎语。任何用例缺一条都不完整。很多人写自动化只写了操作，忘了断言，结果脚本跑得飞起，但错了也不知道，这种用例价值极低。
设计阶段就要想好选择器怎么定位稳定。CSS 类名经常变，要优先选带稳定语义的属性，比如id或>bool TestLogin(WebDriverClient& client, const std::string& sid) { // 准备：打开登录页 client.Navigate(sid, "https://example.com/login"); // 操作：填写表单 auto account = client.FindElement(sid, "#account"); client.SendKeys(sid, account, "test_user_001"); auto password = client.FindElement(sid, "#password"); client.SendKeys(sid, password, "test_pw_123456"); auto loginBtn = client.FindElement(sid, "#login-btn"); client.Click(sid, loginBtn); // 断言：等待页面出现用户信息区 for (int i = 0; i < 20; ++i) { try { auto welcome = client.FindElement(sid, "#welcome"); std::string text = client.GetText(sid, welcome); if (text.find("test_user_001") != std::string::npos) { return true; } } catch (const ElementNotFound& e) { // 元素还没出现，继续轮询 } std::this_thread::sleep_for(std::chrono::milliseconds(500)); } return false; }
这里用一个 20 次的轮询，每次间隔 500 毫秒，总共最多等 10 秒。比固定sleep(5)的写法要稳得多。如果页面 2 秒就加载好了，轮询立刻就能往下走；如果 8 秒才加载好，也不会因为固定 5 秒超时白白失败。
4.3 页面等待到底怎么写才对
讲到等待，就把几种方案放在一起对比，方便你对号入座：
- 固定 sleep：最简单，但要么等过久浪费时间，要么等不够白白失败。只适合调试。
- 显式轮询：自己封一个
WaitUntil(condition, timeout)函数，每隔几百毫秒检查一次条件，直到超时。推荐，灵活可控。 - 协议级隐式等待：WebDriver 标准里定义了 implicit wait，即找不到元素时驱动自己重试一段时间。这个很好，但注意它是全局的，设置一次影响后续所有查找，阈值别设太大。
从 C++ 的角度看，我推荐用显式轮询，因为它不依赖驱动实现，逻辑完全掌握在自己手里，超时还能附带自定义报错信息。上面代码的循环体本身就是一个最简版显式轮询。把它抽成模板函数后，任意条件都能复用。
4.4 跑起来之后看什么
用例跑起来时，浏览器会自动弹出、自动输入、自动点击，你只需要在日志里观察过程。我自己踩过的坑是：本地跑得好好的，一到 CI 环境就跑不过。原因多半是 CI 环境没有图形界面，浏览器启动失败。这一步必须用到无头模式。在创建会话的 capabilities 里给浏览器驱动指定--headless参数即可。具体写法取决于浏览器，核心是把参数塞进 capabilities 的goog:chromeOptions一类字段。CI 环境还经常缺少sandbox权限，同样需要调整参数。
无头模式意味着浏览器不显示窗口但照常渲染页面，非常适合跑回归。唯一的缺点是出问题时看不到浏览器现场，所以后文会讲失败截图的重要性。
5. 从单脚本到框架化：C++ 测试基建怎么搭
5.1 会话管理策略
写了两三个用例，你一定发现大家都要做“创建会话、删会话”这件事。会话管理策略有两个流派：每个用例独立会话，和多个用例共享会话。
独立会话的优点是隔离性好，用例 A 改了什么状态不会影响用例 B。缺点是浏览器反复启停，时间开销大。共享会话的优点是快，但用例之间容易互相干扰，前一个用例没退出登录，后一个用例就会被带到奇怪页面。我的经验是：默认按用例独立会话跑，除非是性能敏感的特殊任务，才考虑共享。协议层创建和删除会话成本可控，稳定性越简单越可靠。
5.2 可复用基类与失败截图
框架化第二步是抽基类。会话的创建销毁、日志初始化、失败清理工作全部放进基类，业务用例只关心步骤和断言，结构清晰很多，代码重复也降下来了。这里更关键的是失败截图——用例跑挂了，光靠日志还不够，一张现场截图能省下大量排查时间。WebDriver 协议里获取截图很简单：
GET /session/{sessionId}/screenshot响应 JSON 的value字段是一段 Base64 编码的 PNG 图像。C++ 里装卸 Base64 也很简单，保存成文件后，测试报告里就能附带截图了。我在封装基类时，把“断言失败自动截图”直接写进基类的断言工具里，一步到位。
5.3 接入 CI：Headless 与退出码
单机运行只是第一步，真正价值是在持续集成流水线里每天跑。接入 CI 最朴素的方案是一个脚本：
# 启动浏览器驱动，保存进程号 driver_binary --port=9515 & DRIVER_PID=$! # 保证脚本退出时回收驱动进程 trap "kill $DRIVER_PID" EXIT # 编译并运行测试程序 build/test_runner --headless # 程序返回值非 0 时，CI 直接将构建标记为失败这里有个容易被忽略的项目：测试进程崩溃了、断言失败了、驱动超时了，返回值必须正确传递。C++ 程序通常用return 0表示成功，return 1表示失败。把这个约定固化到 CI 脚本里，流水线才能正确报红。另外，如果测试量很大，建议按模块分片跑，避免单个任务超时。
6. 常见问题与排查技巧速查
协议这块东西，很多坑只有真的踩一遍才会记住。我把见过的高频问题和排查方法整理成速查表：
| 现象 | 根因 | 排查与解决 |
|---|---|---|
| 创建会话直接失败 | 驱动与浏览器版本不匹配 | 确认二者大版本一致，换匹配的驱动版本 |
| 先能用，后来创建会话失败 | 驱动进程残留或端口被占用 | 杀掉残留进程，重启驱动，或换端口启动 |
| 元素找不到 | 页面加载慢、点击后跳转未完成 | 加显式轮询，等元素可点击再操作 |
| 定位到的元素跟预期不符 | 页面有多个相同 CSS 类 | 换更精确的选择器，用层级限定，比如.form .submit |
| 页面元素在 DOM 里但操作失败 | 元素被 iframe 包裹，或处于 Shadow DOM 内 | 先切换到对应 iframe 上下文，再定位元素 |
| 无头环境下跑不过 | 缺少图形环境、缺系统依赖 | 加 headless 参数，开启no-sandbox，确认字体和系统库齐全 |
| 并发跑多个用例时互相干扰 | 会话共享或全局状态冲突 | 拆分成独立会话，给每个进程独立用户目录 |
大多数问题都指向同一个根源：自动化是跟真实浏览器打交道，不确定性比单测高得多。定位问题时要学会分层判断——先看驱动日志，确认请求发出和响应返回是否正常，再判断是选择器问题还是时序问题，不要一上来就改业务代码。
驱动日志是个好东西。启动驱动时加个 verbose 参数，它会把每个 HTTP 请求和响应都打印到终端，包括你不知道有没有发出去的请求、返回了什么样的错误体。排查疑难杂症时，这个日志比任何调试器都直接。
最后再分享一点个人体会。我在写完这个最小 C++ 客户端之后，对自动化测试的理解跟之前完全不同了。以前用现成库写用例，遇到诡异问题就只能上网搜答案；现在能直接看协议、看请求、看响应，大部分问题自己就能定位。所以这个方向不仅适合 C++ 工程师入门测试开发，也适合任何想真正搞懂 Selenium 的人。后续扩展方向也很顺：把这层封装接到已有的 C++ 测试框架里，复用命令行参数解析、报告生成、失败重试机制，你的自动化测试体系就真的长在 C++ 技术栈里了。
