第1章 认识Selenium

第1章 · 认识Selenium

本章要回答的三个问题：Selenium 凭什么在自动化测试领域站稳二十年？它到底擅长做什么、又有哪些事它天生做不好？当 Playwright、Cypress 这些新引擎轮番登场时，你该拿什么标准给自己的项目做选型？这三问层层递进——不知道它从哪来，就理解不了它的设计取舍；说不清边界，就会把它用在自己不该出现的地方；没有选型框架，工具演进只会让你反复推倒重来。

为什么会有这一章

几乎所有自动化项目翻车，都能追溯到立项第一周犯的认知错误。有人把 Selenium 当成"点一遍就自动化的录制器"，结果脚本第一轮迭代就散架；有人拿它去测纯接口逻辑，绕着浏览器跑了几百条用例，维护成本高到没人接手；还有团队听了一场新工具的分享就仓促换栈，三个月后发现生态、招聘、存量脚本全是沉没成本。

这些弯路的共同根源，是没有先弄清楚三个因果：Selenium 因什么而生、因什么而强、又因什么而受限。它诞生于 2004 年一个需要反复手工验证报价系统的团队，核心诉求是"让浏览器替人做重复验证"；它强大在跨浏览器、跨语言的生态与 W3C 标准；它受限在一切基于 UI 的测试共有的痼疾——慢、脆、依赖环境。把这三个因果想透，后面七章的每一个技术决策都有了对答案的基准线。

读完能解决什么

对照开篇三问，读完本章你应当能拿出三样东西。第一，一份能讲给团队听的技术脉络：从 Selenium Core 的 JavaScript 注入，到 WebDriver 的原生驱动，再到 W3C 标准，你会明白"它为什么是这个架构"。第二，一张边界清单：什么场景该上 Selenium（回归、跨浏览器、端到端旅程），什么场景该绕开它（单元逻辑、纯接口、视觉像素级比对），边界清单能挡住大多数错误的立项。第三，一份选型对比表：四个主流引擎在架构、语言支持、并发模型、生态成熟度上的差异，以及"什么团队在什么阶段选什么"的判断依据。

各节怎么分工

三节的关系是一条"总—分—横"的线：1.1 立起纵向的历史坐标，1.2 在这个坐标上圈出能力边界，1.3 再横向放到整个工具生态里比对。读完它们，你对 Selenium 的认知将从"一个自动化库"升级为"质量工程基础设施的一个选型项"。

这张简图是本章的问答骨架：历史脉络给出判断依据，边界清单反过来修正你对历史的理解，最终汇成一份能落笔的选型决策记录——第 8 章做技术演进复盘时，还会回来核对这份记录。

常见疑问

问：直接从第 2 章开始动手不行吗，为什么先读认知章？ 可以，但通常会在第 3 章撞墙回来补课——不理解协议与边界的工程师，会把所有失败都归因于"脚本写错了"，然后在正确的代码里反复找错。先立坐标再动手，是这本教程的顺序赌注。

问：团队已经在用别的引擎，这一章对我还有用吗？ 本章的三问框架（历史、边界、选型）对任何引擎都成立；读完你至少能回答"我们现在的选型对不对"，也可能发现该给 Selenium 留一个回归守护的生态位。

问：选型结论会随时间失效吗？ 表格里的具体版本数字会过时，但选型的三根锚——存量资产、团队语言、浏览器覆盖——是慢变量。本章教的是用锚思考，而不是背结论。

先决条件

读这一章不需要写过自动化脚本，但需要三样底子：用过浏览器开发者工具查看页面元素（哪怕只是右键检查过按钮）；了解 HTTP 请求响应的基本模型；对"单元测试、集成测试、端到端测试"的分层有粗略印象。三节均不涉及代码实操，环境搭建留到第 2 章末尾再动手。

往下走到哪

本章结束时，你手里应有一份自己项目的场景清单——哪些用例值得自动化、用什么工具做。第 2 章就顺着这份清单进入内部：把 Selenium 的三层架构、WebDriver 协议一次点击的完整链路拆开看，然后亲手搭好环境跑通第一条脚本。认知从"选型"落到"能跑"，是从这一章到下一章的接力棒。