Selenium自动化测试框架核心原理与工程实践：从WebDriver到Page Object

1. 为什么我最终选择了Selenium作为自动化测试的起点

做自动化测试这些年，身边总有人问我：市面上那么多工具，Cypress、Playwright、Appium，为什么你最终扎根在Selenium上？这个问题其实挺有意思的，我得从一次真实经历说起。

三年前我在一家电商公司负责Web端核心下单流程的质量保障。那时候公司正在从传统手工测试向自动化转型，老板给的任务很直接：半年内把回归测试的时间从原来的两天压到半天。当时团队里有人提议直接用Playwright，有人坚持用Cypress，我犹豫了很久，最终还是选了Selenium，并且一直用到了今天。原因很简单：Selenium不是最年轻的工具，但它是最不会被淘汰的工具。

我先说几个Selenium的核心特点，大家感受一下：

• 支持语言最广：Java、Python、C#、Ruby、JavaScript、Kotlin，你团队用什么语言，它基本都能接上，这意味着你不需要为了测试框架去强迫团队学一门新语言。
• 浏览器覆盖全：Chrome、Firefox、Edge、Safari，包括现在很多企业还在用的旧版浏览器，它都有对应的Driver支持，不需要为了自动化去强制升级浏览器。
• 社区沉淀厚：Selenium的WebDriver协议已经成了行业事实标准，很多后来的工具其实都在兼容它的定位方式，学会Selenium，你上手其他工具会快很多。

我团队里当时的情况是：核心业务代码用的是Java，测试人员以前写过Python小脚本，运维那边又是Node.js的底子。如果选了Playwright，基本就锁死在JavaScript生态里了；选了Cypress，对测试人员来说上手曲线虽然友好，但它跑在Node.js环境里，模拟真实用户操作的能力相比Selenium还是差了一些。Selenium允许不同角色用自己最熟悉的语言写同一套自动化用例，这一点在公司团队协作场景下太重要了。

适合参考这篇文章的读者，我觉得主要是这三类：

• 刚刚接触自动化测试，想知道从哪个框架入手比较稳妥的测试新人；
• 团队已有手工测试流程，正准备做自动化转型的测试负责人；
• 接触过Selenium但没系统梳理过框架结构，想从“会写脚本”进阶到“能搭框架”的开发者。

接下来的内容，我会按照我真实搭建这套框架的顺序来写：先说Selenium运行时最核心的原理，再讲怎么搭建一套健壮的框架骨架，然后聚焦Page Object这个最容易做但最容易被做坏的模式，接着把数据驱动和等待策略这两个决定框架是否稳定的环节拆开讲透，最后分享我维护这套框架两年多遇到的高频问题和压箱底的排错技巧。如果你能照着走一遍，至少能为团队省下我当年踩坑所花费的摸索时间。

2. Selenium的运行时原理：先搞清楚它到底是怎么干活的

很多人写Selenium脚本写了一两年，问他“WebDriver到底怎么控制浏览器的”，他可能都说不清楚。这其实很危险，因为你不理解底层机制，遇到超时、元素找不到这类问题时，就只能靠猜，而猜是自动化测试里最昂贵的排错方式。

2.1 WebDriver协议和浏览器驱动的三角关系

Selenium 的本质是一个协议，不是一套魔法。WebDriver协议定义了客户端（你的测试代码）和浏览器之间的通信标准。整个运行过程可以拆成三步：

1. 测试代码通过WebDriver协议发出HTTP请求。你在Java或者Python里调用driver.findElement(By.id("username"))，底层会把这个操作封装成一个HTTP请求，发送到浏览器Driver的某个端口上。
2. 浏览器Driver（如chromedriver、geckodriver）接收请求，把它转译成浏览器真正能理解的原生指令，并调用浏览器内部暴露的自动化接口去执行。
3. 浏览器把执行结果原路返回。找到元素了返回元素标识，没找到就返回异常信息，Selenium再把结果解析给你。

这个“浏览器内部暴露的自动化接口”，在Chrome里叫Chrome DevTools Protocol，在Firefox里用Marionette协议，Selenium的价值就在于它把这层差异全部封装掉了，你不需要为每个浏览器写不同的调用方式。

打个比方，这就好比你去一个多语言国家旅游。Selenium是那本通用翻译手册，你已经写好了一句“我要去餐厅”的通用表达，浏览器Driver则是站在你身边的本地翻译官，它把你的通用表达翻译成当地人听得懂的话。没有这个翻译官，你的话再标准也没人听得懂。

2.2 版本匹配问题：新手遇阻的第一道坎

我见过太多人刚开始装Selenium就卡在版本上，然后跑来问我：“为什么我代码没错，但启动浏览器就报SessionNotCreatedException？”

这个问题十有八九是驱动版本和浏览器版本不匹配。Chrome浏览器每隔几周就会自动更新，但chromedriver不会跟着同步更新，结果就是你电脑上的Chrome是120，chromedriver还停留在115，两边一握手就崩了。

我给你的建议是这样处理：

• 打开浏览器，在地址栏输入chrome://version，找到“Google Chrome”旁边的版本号；
• 去ChromeDriver官方下载页找到对应大版本的驱动（比如120.x对应120大版本）；
• 把下载的chromedriver放到一个固定目录，然后在脚本里显式指定它的路径。

如果你用Java，建议通过WebDriverManager这个库来自动管理驱动版本，它会自动匹配你本机浏览器的版本并下载对应驱动，能省掉很多手工维护的麻烦。Python那边也有类似的webdriver-manager包，本质上都在做同一件事。

这里额外提醒一句：很多被记录为“Selenium不稳定”的问题，根因其实是驱动版本不匹配，不是Selenium本身的锅。我在做技术支持时发现，超过一半的“跑一会儿就崩”其实是内存溢出或驱动与浏览器通信超时，后面会专门说怎么定位。

2.3 Selenium 3和Selenium 4的本质区别

现在Selenium 4已经是非常稳定的版本了，但很多企业项目还停留在3代代码上。我从3代迁移到4代时总结过两者的关键区别：

对比项	Selenium 3	Selenium 4
WebDriver协议	W3C标准化之前的分歧版本	全面支持W3C WebDriver标准
定位策略	只能通过By类型定位元素	新增相对定位器（Relative Locator），支持按位置找元素
窗口管理	只能切换窗口句柄	新增Tab和Window的全新管理API，更直观
执行逻辑	各种Driver类各自为政	引入new SeleniumManager()，部分场景可自动定位驱动

从3迁移到4其实不需要重写代码，大部分旧的findElement和sendKeys调用直接就能兼容运行，但如果你用了DesiredCapabilities这种老配置方式，最好换掉，因为它在4代里已经被标记为不推荐使用，后续版本的维护方向会更倾向于新的Options体系。

我的建议是：新项目直接上Selenium 4，老项目也尽量安排一个迭代带过渡过去。Selenium 4在性能和稳定性上都有明显改善，尤其在后来的Chrome版本对自动化接口经常调整的情况下，4代的兼容性维护做得更及时。

3. 搭框架前的三个关键决策：不是代码怎么写，而是怎么设计

很多教程一上来就教你怎么写第一个Selenium脚本，我反而觉得，在你写第一行代码之前，有三个直接影响后期维护成本的决策，需要先定下来。这三个决策决定了你之后是“半年后项目还能顺利跑下去”，还是“三个月后就想把整个框架推翻重来”。

3.1 语言选型：Java还是Python

这是一个经典的二选一，我给不出绝对答案，但可以讲讲我观察到的规律。

选Java的团队，通常是以下几点中的至少两条成立：部署环境以Linux服务器为主且已有成熟的Java运维体系；测试团队本身大多来自开发背景，写Java没有适应成本；被测系统的技术栈是Java系（比如Spring Cloud微服务），测试代码可以和开发共用一些工具类库。

选Python的团队，通常是这些情况：测试团队以测试工程师为主，开发经验相对弱一些；脚本追求快速产出，比如日常数据准备、临时爬虫、接口冒烟；被测系统可能偏Django、Flask这些Python技术栈，或者前端是Node系但测试团队不想学JS。

就我个人的实测感受来说：如果你要做的是一个长期维护、多人协作、层级较多的大型Web自动化框架，Java的静态类型检查能帮你挡住很多低级错误（比如把字符串传给了需要整数的方法，编译期就会报错）。如果你只是想快速验证一个流程能不能跑通，Python能让你半个小时就看到效果。

还有一个容易被忽略的点：生态。Java有TestNG和JUnit两大测试框架，TestNG里的@DataProvider做数据驱动特别顺手；Python有pytest，fixture机制灵活得让人上瘾。哪个写起来更顺手，其实决定了你的框架能走多远。

3.2 构建工具和依赖管理

选了Java，通常就是用Maven或Gradle。我两个都用过，个人更推荐Maven，没有特别复杂的原因：Maven的生态兼容性最稳，团队里的同学基本不用额外学习。Gradle构建更快，但它的依赖冲突处理有时候真的很磨人，尤其是当你的自动化框架里引了很多不同来源的jar包时。

无论用哪个，我建议把Selenium相关的依赖统一管理在一个父级POM或版本目录里。比如Java项目里可以定义一个selenium.version变量，所有模块引用同一个版本，后期升级时只需要改一处。

Python那边推荐用requirements.txt配合venv虚拟环境，锁住版本号。别小看这一步——我见过不少项目因为有人直接pip install selenium搞了个最新版，结果其他人的环境还是老版本，整个团队白白浪费一天排查“为什么我本地跑得好好的，你那边一跑就报错”。

3.3 浏览器选型：默认Chrome，但要考虑CI环境

日常开发调试，我默认推荐Chrome，原因就一个字：稳。Chrome的Driver更新最及时，社区问题最多所以解决方案也最多，大部分开源Selenium项目默认都是跑Chrome的。

但在CI流水线上，你需要考虑一个事情：跑测试的机器有没有图形界面。如果你的Jenkins或者GitLab Runner跑在无界面的Linux机器上，Chrome必须开启headless模式。Selenium 4里可以这样配置ChromeOptions：

ChromeOptions options = new ChromeOptions(); options.addArguments("--headless=new"); options.addArguments("--no-sandbox"); options.addArguments("--disable-dev-shm-usage"); WebDriver driver = new ChromeDriver(options);

注意--no-sandbox和--disable-dev-shm-usage这两个参数，在Docker容器里跑自动化时几乎必加。--disable-dev-shm-usage是因为Docker默认的/dev/shm空间太小，Chrome会直接崩，加上这个参数让Chrome改用临时目录会好很多。

还有一个比较伤的坑：在CI环境里使用固定的Chrome版本对应固定的driver版本，否则某天Chrome自动更新了，你的CI流水线就集体变红。我的做法是在CI的镜像构建阶段就固定Chrome版本，不跟随latest标签。

4. Page Object模式：框架的骨架，也是维护成本的分水岭

Page Object模式（简称PO模式）几乎成了Selenium项目的标配，但我在Code Review里见过太多“伪PO模式”——只是把findElement的代码搬了个位置，根本没有做到职责分离。这种框架跑到后期，改一个页面结构，几十个测试类跟着改，维护成本直接爆炸。

4.1 什么是真正的Page Object，什么只是搬代码

真正的Page Object模式，核心职责有两条：

1. 页面结构定位和页面操作逻辑，只存在于Page Object类中；
2. 测试用例里只写业务操作和结果断言，不出现任何By、XPath等定位相关的细节。

举个例子，假设登录页面有一个用户名输入框。错误示范是把定位写死在测试用例里：

// 错误示范：定位信息散落在测试用例里 driver.findElement(By.id("username")).sendKeys("testuser"); driver.findElement(By.id("password")).sendKeys("123456"); driver.findElement(By.id("loginBtn")).click();

正确做法是先在Page Object里封装一个登录方法：

public class LoginPage { private WebDriver driver; private By usernameInput = By.id("username"); private By passwordInput = By.id("password"); private By loginButton = By.id("loginBtn"); public LoginPage(WebDriver driver) { this.driver = driver; } public void login(String username, String password) { driver.findElement(usernameInput).sendKeys(username); driver.findElement(passwordInput).sendKeys(password); driver.findElement(loginButton).click(); } }

然后测试用例变成这样：

public class LoginTest { WebDriver driver; @Test public void testLoginSuccess() { LoginPage loginPage = new LoginPage(driver); loginPage.login("testuser", "123456"); // 然后才是真正的业务断言 } }

这样做的好处一目了然：如果前端改了用户名输入框的id，你只需要改LoginPage里的这一个定位符，所有测试用例自动跟着修复，而不是去几百个测试方法里做全局替换。

4.2 Page Object粒度如何把控：页面粒度还是流程粒度

这里有个实践中的争议：一个Page Object到底对应一个页面，还是对应一个业务流程？

我最初也是按“一页面一类”做的，后来发现有些场景并不适用。以一个购物结算流程为例，它包含确认收货地址、选择支付方式、提交订单这三个操作界面。按页面粒度拆分，我要建三个Page Object类，但实际用例从来不会单独操作其中一个页面，它们总是连在一起跑的。这种情况下按流程粒度封装反而更合理。

我现在的做法是两条腿走路：表单型页面（登录、注册、填写资料）按页面粒度拆；流程型页面（结算、下单、审核流）按业务流程拆。前者的元素复用率高，按页面拆最划算；后者的业务连贯性强，按流程拆能减少用例代码量，也不容易因为页面间的状态跳转把用例搞碎。

它的判断标准很简单：如果你的Page Object类里，超过一半的方法在测试用例里从未被单独调用过，那说明这个类的粒度拆分不合理，它应该按实际使用场景合并或重划。

4.3 元素定位方式的优先级排序

PO模式里最核心的工作之一就是选好元素定位方式。我做代码审查时经常看到有人用一长串XPath从根节点一路找下来，看得人头大。这里给大家一个我自己总结的优先级顺序：

1. ID：页面里ID理论上唯一，定位最快，最优先用。
2. Name：表单元素基本都有name属性，可以用来配合表单交互。
3. Class（尽量配合其他条件）：单个class可能指向多个元素，一般不单独用。
4. CSS Selector：速度仅次于ID，语法简洁，适合结构清晰的元素。
5. Link Text / Partial Link Text：只适合精确匹配超链接文本，使用场景窄。
6. XPath（最后考虑）：灵活但慢，且DOM结构变了极容易失效。如果不得不用XPath，也尽量用相对路径，不要写包含绝对层级的长路径。

我举个例子说明为什么XPath要尽量少用。假设当前页面的一个按钮，在某个开发重构后从div/form/div[1]/button变成了div/form/div[2]/button，你的绝对路径XPath直接失效。但如果你用By.cssSelector("form.submit-form button[type='submit']")，哪怕外面的div层级变了，只要表单的class和按钮类型没变，照样能定位到。

元素定位这件事，我的原则是：定位符要像一把钥匙，既要能打开当前这扇门，也要在门框轻微变形后还能打开。追求绝对的稳定不现实，但至少在页面改动后你能以最小的代价修好它。

5. 数据驱动和等待策略：决定框架能否长期稳定的两个细节

很多人搭建框架时能顺利写Page Object，也能跑通几个用例，但一旦用例规模上到几百条，问题就开始暴露。最典型的现象有两个：一是数据写死在脚本里，用例一多根本维护不过来；二是测试不稳定，今天能跑过明天就挂了。这两个问题的答案，分别落在数据驱动和等待策略上。

5.1 数据驱动不只是“把数据放文件里”

数据驱动的核心思想是：把测试数据和测试逻辑分离。我在框架里一般会引入一个test-data目录，按业务模块存放数据文件，可以是JSON、YAML，也可以用Excel。

以TestNG为例，数据驱动最经典的地方就是@DataProvider。我们可以在一个数据类中维护一组用户数据：

@DataProvider(name = "loginData") public Object[][] loginData() { return new Object[][] { {"testuser_001", "Passw0rd123", "登录成功"}, {"testuser_002", "wrongpassword", "密码错误"}, {"", "123456", "用户名不能为空"} }; } @Test(dataProvider = "loginData") public void testLogin(String username, String password, String expectedMsg) { // 使用Page Object执行登录，并检查提示信息 }

这样写的好处是显而易见的：写测试用例的人不再需要关心页面元素，只需维护数据表格；一条数据就是一个测试场景，加到几百条也不怕；将来如果接口自动化也基于这套数据格式，可以复用同一个数据层。

我还见过更进一步的方案：用YAML文件描述测试数据和对应的期望结果，配合Jackson或fastjson反序列化成对象。这套方案后期维护体验最好，但前期编码量稍大，适合用例规模已经上来的团队。

数据驱动有一点需要特别注意：测试数据和测试逻辑分离后，数据的质量就变成了用例稳定的核心。我见过有团队把登录账号、收货地址、商品ID全部放在同一个数据文件里，结果线上环境商品下架导致用例大面积失败。我的建议是每个数据文件只覆盖一个业务主题，并且明确标注它依赖的数据是否需要在环境中提前准备。

5.2 显式等待才是Web自动化的“稳定器”

Selenium默认的查找元素方式是“找到就返回，找不到就立即报错”。可网页元素很多时候不是立即渲染出来的，而是通过Ajax异步加载进来的。如果你不做任何等待处理，用例自然就时好时坏。

Selenium提供了三种等待方式：

• 强制等待（Thread.sleep）：不推荐，固定等几秒，环境一慢就挂，环境一快又白白浪费时间；
• 隐式等待（driver.manage().timeouts().implicitlyWait）：设置全局等待时间，但它是“轮询时先等再找”，和显式等待混用时会有冲突，建议不要和显式等待混用；
• 显式等待（WebDriverWait）：针对特定元素、特定条件设置等待时间和轮询间隔，这是实际项目中最推荐的方式。

我在框架中一般把显式等待封装成一个工具方法，让调用方只需要传入定位符，而不需要关心等待逻辑：

public WebElement waitForElement(By locator, int timeoutInSeconds) { WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(timeoutInSeconds)); return wait.until(ExpectedConditions.visibilityOfElementLocated(locator)); }

如果你用Selenium 4，建议这样写：

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10)); wait.until(ExpectedConditions.elementToBeClickable(By.id("submit")));

和3代最大的区别是等待条件必须用Duration指定，不能直接传一个裸的int，这个改动在升级时特别容易忽略，编译不过跑起来才发现。

还有两个细节，我踩过坑之后特别想分享给你们的：

第一，等待条件要按场景选。元素存在（presenceOfElementLocated）不等于元素可见（visibilityOfElementLocated），可见不等于可点击（elementToBeClickable）。如果你要点击一个按钮，却只等它出现在DOM里，很可能出现“元素存在但被遮住”的异常。很多时间，元素已经在DOM中，但因为弹窗遮罩还没消失，点击会被拦截。这时候应该优先等elementToBeClickable。

第二，不要从第一条用例开始就把全局等待时间调得很大。我见过有人把implicitlyWait设成30秒，然后所有用例都变慢了几倍。更合理的做法是：把默认轮询间隔控制在500毫秒，超时时间按具体场景从3秒到15秒不等，个别组件（比如图表渲染）再单独加长。

5.3 我用过的等待策略配置参考

下面是我在真实项目中维护的一套等待参考配置，供大家套用：

场景	等待条件	超时时间	备注
登录后跳转	等待某个业务首页元素可见	10秒	比5秒更稳，避免偶发慢网络
弹窗出现	等待弹窗容器元素可见	5秒	弹窗一般由JS同步生成，不需要太长
表格数据刷新	等待某行数据文本出现	15秒	表格常由接口异步加载，且数据量大
文件上传后处理	等待处理完成提示文本	30秒	上传和解析可能涉及后端复杂逻辑
图表Canvas渲染	等待页面某静态文案可见	20秒	Canvas内元素无法直接定位，只能外围等待

这套配置不是标准答案，但可以作为一个起点，你们在实际项目里根据自己的页面响应情况调整即可。等待时间并非越长越好，只要满足95%以上的稳定率就够了。

6. 框架跑起来之后的那些“坑”：高频问题与排查链路

当框架的核心结构搭好之后，真正的挑战才刚开始。我在这套框架维护过程中，遇到过很多此前完全没预料到的问题，比如偶尔下滑或卡死、元素定位偶发失效、容器内Chrome崩溃等，尤其在一段时间后，这些问题的排查经验成了最有价值的沉淀。为了方便你快速查阅，我把最常见的几类问题和排查链路做了个梳理。

6.1 “偶发找不到元素”到底是怎么回事

现象：一条用例第一次跑通过，第二次就报NoSuchElementException，重跑又通过了。这种问题在自动化项目里最常见，也是最让人头疼的。

我的排查顺序是这样的：

1. 先用显式等待替代你现有的定位逻辑，看还会不会报错。如果不再报，说明是加载时序问题，不是定位符错误。
2. 打开浏览器DevTools里的网络面板，看这个元素的请求返回时间和页面渲染时序，确认到底是JS异步渲染还是接口数据未返回。
3. 在报错的位置加一步截图保存，把失败现场留档。Selenium自带getScreenshotAs方法，用例失败后自动截图是必备功能。
4. 如果重跑就能过，大概率还是等待条件选错了，去检查你等的是“元素存在”还是“元素可交互”。

我见过的最奇怪一次情况是：某个元素在页面上的可见性依赖于一个CSS旋转动画，动画结束前元素在渲染树里已经存在，但你点击时浏览器默认阻止了对动画中元素的点击。最后我把等待条件换成了elementToBeClickable，问题就再也没出现过。

6.2 用例串号：几个用例互相影响怎么查

有些框架跑久了会出现一个现象：单个用例单独跑全通过，全部跑在一起就有几个失败。这往往是“测试数据串了”。

举例来说，你的测试登录用例在方法里没有清理浏览器的localStorage，下一个用例用同样会话打开了需要不同登录态的页面，结果就乱了。

我的处理策略是这样的：

• 在@BeforeMethod里对所有用例做一次新的session创建，不要复用driver实例；
• 每个用例结束后的@AfterMethod中，对本地存储、Cookie进行清理，或直接恢复初始状态；
• 如果业务确实依赖“上一个用例产生的状态”，那就明确用数据文件做衔接，不要偷偷依赖对象内部状态传递。

这里我特别想强调：用例之间的隔离性比用例数量更重要。在自动化测试里，一条不隔离的用例就像一颗定时炸弹，它平时静静躺着，但会在某个深夜的定时任务里突然引发十几个连锁失败，你查起来还找不到原因。

6.3 跑着跑着浏览器内存涨到失控

长时间跑大批量用例时，Chrome的内存占用会越来越大，最后直接崩溃或变得奇慢无比。这个问题不只是Chrome的锅，Selenium代码如果没有正确关闭一些资源，同样会加速这个问题的到来。

我在代码里习惯把每个用例的WebDriver都放进@AfterMethod的driver.quit()里，而不是driver.close()。区别在于：close()只关闭当前窗口，标签页或弹窗可能还在；quit()才是真正杀死整个浏览器进程。用quit()才能保证浏览器不会残留一堆僵尸进程，最终拖垮机器。

另外，在CI容器里我还建议定期执行两步“内存清理”：一是重启Runner，二是清理/tmp下的Chrome临时文件。这两步很简单，但能避免很多无故失败。

6.4 错误信息读不懂？先看异常类型的“前缀”

Selenium的异常体系其实很有规律，我总结了几个高频异常和常见原因，放在表里供参考：

异常类型	常见原因	处理思路
NoSuchElementException	元素未加载完或定位符错误	先换显式等待，再核对定位符
ElementNotInteractableException	元素不可见/不可点击/被遮挡	等待可点击状态，检查弹窗遮罩
StaleElementReferenceException	元素所在DOM已刷新，旧引用失效	重新定位，尽量在同一操作内完成查找与交互
SessionNotFoundException	浏览器进程退出或Driver连接中断	重启Driver，检查quit()是否过早执行
WebDriverException	各类底层通信问题，通常伴随版本问题	先核对Driver和浏览器版本是否匹配
TimeoutException	显式等待超时条件未满足	分析页面加载时序，调整等待条件或时间

有个技巧特别实用：把每一次失败都做成结构化的日志。我不建议只在命令行打印一堆堆栈，最好把异常类型、定位符、操作描述、页面标题、当前URL、截图路径统一记录到一份HTML报告中。这样排错时不用去复现，直接看报告就能定位问题。

6.5 测试数据环境问题：蓝色代码被环境坑的经历

我遇到过整整两周测试框架在本地跑得好好的，一到CI就大片失败的情况。查来查去，最后发现是CI环境里的测试数据库被另一个团队的自动化任务清掉了几条关键数据。

这就是数据和环境依赖的坑：只要用例依赖的数据不够稳定，框架做得多健壮都白搭。后来我从两个方向解决了：

• 把测试数据准备脚本化，在每个测试套件执行前自动执行，保证环境数据的一致性；
• 对线上环境的查询类请求一律用Mock或固定的测试桩，不让外部环境影响框架稳定性。

这算是我近年来踩过最贵的坑之一了。如果你也发现自己的框架有时好有时坏，而且坏的用例序列还没规律，优先去查环境变量和前置数据，别一上来就怀疑代码逻辑。

7. 我在这套框架上的最终体会：平衡比炫技重要

坦白讲，Selenium自动化测试框架发展到今天，已经很难说有什么“独家神技”了，它更多是一个工程权衡的结果。我在多次项目重构中体会最深的一点是：好的框架一定是在稳定性、可维护性和落地成本三者之间找到平衡，而不是堆砌多少新特性。

现在的自动化测试领域涌现了越来越多的新工具，但Selenium作为市场上历史最长、资料最全的框架，仍然是一块非常稳固的基石。它最大的价值在于它足够“成熟”，成熟到很多前人已经踩过的坑，你都能在社区里找到答案。对新人来说，它是最不让人困惑的起点；对老手来说，它又是能承载复杂体系的老伙伴。

如果让我给正在搭建框架的你三条建议，我会不加修饰地讲：

• 先把等待策略做对，再谈用例数量。十个不稳定的用例，不如三个跑一年都不挂的用例有价值。
• Page Object的粒度按照实际业务流程来定，不要为了模式而模式。
• 数据准备和环境隔离是框架能不能上CI的前提，这件事如果没做好，后面全是无用功。

Selenium这条路，不陡峭，但很长。希望我这篇文字能帮你省掉一些原本要亲自绕的弯路，让脚手架早一点立起来，让用例的失败信息早一点变得清爽好查。