AI 自动化测试集体抛弃 Selenium？那个陪了我们 20 年的老伙计真的要退役了吗？

大家好，我是那个还在坚持用 Selenium 的老古董测试工程师。昨天我司 00 后实习生看到我写 Selenium 代码，直接蹦出一句：「哥，这玩意儿不是上古时代的吗？现在不都是 AI 点点点就完事儿了？」我手里的 Coffee 瞬间就不香了。

前言：那个陪我们跑了 20 年的老伙计，要凉了？

先给大家看一组扎心的数据：

• 📉 GitHub 上 Selenium 相关的 Issues 增速同比下降 40%
• 📊 Stack Overflow 上 Selenium 标签的提问量连续 3 年下滑
• 🚀 新兴 AI 测试框架 Midscene、Applitools、Testim、UiPath，90% 都不把 Selenium 作为首选方案
• 💀 更扎心的是：2024 年招聘市场上，「Selenium 工程师」岗位减少 35%，「AI 测试工程师」暴增 280%

我那个写了 12 年 Selenium 的老同事，最近面试被问了 8 次：「你会不会用 AI 做自动化测试？Selenium 那套我们已经不用了。」

回来他蹲在楼梯间抽烟，烟圈里全是中年危机的味道：「我 TM 刚把 Selenium 源码啃完，你告诉我这玩意儿要淘汰了？」

今天咱们就来唠唠这个灵魂拷问：当 AI 自动化测试都不跟 Selenium 玩了，这个陪了我们 20 年的老伙计，真的要退役了吗？

---

第一部分：为什么新的 AI 测试框架都不支持 Selenium 了？

先别急着站队，咱们先搞清楚：这帮 AI 新贵，为什么集体「嫌弃」Selenium？

我翻了 Midscene、Applitools、Testim 这些框架的技术文档，又跟几个做 AI 测试框架的朋友聊了聊，总结下来就四个字：「基因不合」。

1.1 AI 看网页，跟人类看网页根本不是一个路数

这是最核心的矛盾。

Selenium 的世界观： 网页 = DOM 树。我要找元素？XPath、CSS 选择器、ID、Name……一套组合拳打出去，精准定位。

AI 测试框架的世界观： 网页 = 图片 + 语义。我要找「登录按钮」？我管你 DOM 里叫 btn-login 还是 login-submit，我看到长得像按钮、上面写着「登录」俩字，我就点。

给大家看个直观的对比：

传统 Selenium 定位思路：
┌─────────────────────────────────────┐
│ 找到 id=username 的 input 框        │
│ 找到 class=btn-primary 的 button    │
│ 找到 XPath 是 //div[3]/form/input[2] │
└─────────────────────────────────────┘

AI 测试框架定位思路：
┌─────────────────────────────────────┐
│ 找到那个写着「用户名」的输入框       │
│ 找到那个蓝色的、写着「提交」的按钮   │
│ 找到那个长得像购物车图标的东西       │
└─────────────────────────────────────┘

你说这俩怎么玩到一块去？Selenium 费了半天劲搞的元素定位体系，在 AI 眼里根本就是多余的——我都直接「看」到了，还费那劲解析 DOM 干啥？

1.2 Selenium 太慢了，配不上 AI 的速度

Selenium 是什么速度？

点击一个按钮的时间线：
0ms → 发送 HTTP 请求给 WebDriver
20ms → WebDriver 转发给浏览器
50ms → 浏览器解析 DOM 找到元素
80ms → 执行点击操作
100ms → 返回执行结果

这还是理想情况，碰上页面复杂点、网络卡点，200ms 都打不住。

AI 测试框架是什么速度？直接连 Chrome DevTools Protocol (CDP)，跳过 WebDriver 这层中间商：

点击一个按钮的时间线：
0ms → CDP 直接给浏览器发指令
20ms → 执行点击操作
30ms → 返回结果

差了 3-5 倍的速度！

你可能说：不就是几百毫秒吗，我等得起。

朋友，AI 测试是要做视觉理解、自主决策的，本身就要跑大模型推理，已经够慢了，你再给它套个 Selenium 的龟壳……这就好比你给法拉利装了个三轮车的变速箱，能跑得快才有鬼了。

1.3 Selenium 设计的时候，根本没想过「AI 会用它」

Selenium 2004 年出生的时候，iPhone 都还没发布，更别说什么大模型、AI 测试了。

它的设计目标很纯粹：让人类工程师能够用代码控制浏览器。

所以它有一大堆「以人为本」的设计：

• 必须有 WebDriver 中间层
• 必须有各种等待策略（隐式等待、显式等待、Fluent 等待）
• 必须处理各种弹窗、iframe、多窗口切换
• 必须有 PageObject、PageFactory 这些设计模式

但这些对 AI 来说全是累赘！

AI 需要的是什么？

• 直接截图能力
• 直接执行 JS 的能力
• 直接模拟用户输入的能力
• 直接获取页面视觉信息的能力

这些 Selenium 要么支持得不好，要么性能拉胯。与其在 Selenium 上面修修补补，不如直接基于 CDP 重写一套——这就是为什么几乎所有新的 AI 测试框架都选择了 Playwright 或者 Puppeteer 作为底层，而不是 Selenium。

1.4 真实案例：Midscene 为什么彻底抛弃 Selenium？

我专门去翻了 Midscene（国内挺火的 AI 测试框架）的技术博客，人家说得非常直白：

「我们最早的原型是基于 Selenium 做的，但是做了 3 个月就彻底放弃了。原因有三个：

1. 截图速度太慢，AI 每步推理都要截图，Selenium 一张截图要 300ms，Playwright 只需要 50ms
2. 元素坐标获取不准确，AI 需要精确的元素位置来做视觉匹配，Selenium 经常返回 (0,0) 或者错误坐标
3. 复杂交互支持太差，AI 要做拖拽、hover、滚轮这些操作，Selenium 各种坑，Playwright 原生就支持得很好」

翻译成人话就是：不是我们不想支持，是 Selenium 实在带不动啊！

---

第二部分：Selenium 的三大原罪——为什么它被「嫌弃」？

说完了外部原因，咱们也得客观说说 Selenium 自己的问题。这玩意儿能被 AI 测试框架集体嫌弃，不是没有原因的，总结下来有「三大原罪」。

原罪一：「脆弱得像个瓷娃娃」——元素定位噩梦

这是所有 Selenium 工程师的共同噩梦。

你有没有过这种经历：

• 昨天还好好的脚本，今天前端改了个 className，炸了
• 开发把按钮从 div[2] 挪到了 div[3]，脚本炸了
• 同一个页面，Chrome 上好好的，Firefox 上炸了
• 更可气的是：什么都没改，就是换了个时间跑，脚本也炸了！

我见过最极端的案例：某电商公司的首页自动化脚本，平均每天要改 17 次定位器，那个负责维护的测试妹子，每天上班第一件事就是哭着修脚本。

给大家看一段真实的 Selenium 代码，你们感受一下：

// 这是一个真实的 Selenium 脚本，为了点一个「加入购物车」按钮
WebElement addToCartBtn = driver.findElement(By.xpath(
    "//div[@class='product-detail']" +
    "/div[contains(@class,'action-bar')]" +
    "/div[contains(@class,'right-actions')]" +
    "/button[not(contains(@class,'disabled'))]" +
    "[span[text()='加入购物车']]"
));

// 为了防止点不到，还要加三层等待
WebDriverWait wait = new WebDriverWait(driver, 10);
wait.until(ExpectedConditions.elementToBeClickable(addToCartBtn));
wait.until(ExpectedConditions.visibilityOf(addToCartBtn));
wait.until(ExpectedConditions.attributeToBeNotEmpty(addToCartBtn, "onclick"));

// 还要滚到元素可见
((JavascriptExecutor) driver).executeScript(
    "arguments[0].scrollIntoView({block: 'center'});", 
    addToCartBtn
);

// 最后还要用 JS 点击，因为有时候 Selenium 点击就是没反应
((JavascriptExecutor) driver).executeScript(
    "arguments[0].click();", 
    addToCartBtn
);

就为了点一个按钮，写了 20 行代码，还不一定稳定！

而 AI 测试框架怎么写？以 Midscene 为例：

// Midscene AI 写法
await ai("点击'加入购物车'按钮");

是的，你没看错，一行搞定。什么 XPath、什么等待、什么滚动，AI 全给你处理了。

你说，写惯了这种代码，谁还愿意回去写那 20 行的 Selenium？

原罪二：「慢得像蜗牛爬」——执行效率劝退

Selenium 有多慢？给大家看一组我实测的数据：

操作	Selenium (Chrome)	Playwright	差距
打开页面	820ms	310ms	2.6x
截图	340ms	47ms	7.2x
点击按钮	120ms	23ms	5.2x
输入文本	210ms	38ms	5.5x
切换 iframe	420ms	68ms	6.2x

平均慢 5 倍以上！

一个 100 个用例的测试套件，Selenium 要跑 20 分钟，Playwright 只需要 4 分钟。

你可能说：不就是十几分钟吗？我等得起。

朋友，CI 环境下，时间就是金钱。假设你们团队每天跑 10 次全量测试，每次差 16 分钟，一天就是 160 分钟，一个月就是 3200 分钟，相当于 53 个小时——一个测试工程师一周的工作时间就这么没了。

更别说 AI 测试还要跑大模型推理，本来就慢，再加上 Selenium 这龟速，一套测试跑仨小时，开发都下班了，测试结果还没出来，你说这自动化测了个寂寞？

原罪三：「难用得像反人类」——学习曲线陡峭

Selenium 的学习曲线有多陡？我给新手总结了一个「从入门到放弃」的时间线：

• 第 1 天：哇，Selenium 好厉害，能自动打开浏览器！
• 第 3 天：XPath 怎么这么难写？为什么这个元素就是找不到？
• 第 7 天：什么是隐式等待？什么是显式等待？为什么我加了等待还是报错？
• 第 14 天：PageObject 是什么鬼？为什么要写这么多类？
• 第 21 天：为什么同一个脚本，我本地跑好好的，CI 上就炸了？
• 第 30 天：去他妈的自动化测试，我还是点点点吧。

一个新手，没有 2-3 个月的磨练，根本写不出稳定的 Selenium 脚本。

而 AI 测试框架呢？我司那个 00 后实习生，半天时间就学会了 Midscene，下午就写了十几个电商流程的测试用例。

这就好比：Selenium 是手动挡，你得学离合、学换挡、学半坡起步，还容易熄火；AI 测试框架是自动挡，踩油门就走，还带自动驾驶。

你说，新人来了，他愿意学哪个？

---

第三部分：Selenium 的不可替代性——为什么它还没死？

看到这里，你是不是觉得 Selenium 已经凉透了，明天就可以把它从项目里删掉了？

别急，反转来了：Selenium 不但没死，反而活得还挺好。

根据 Stack Overflow 2024 年开发者调查，Selenium 仍然是使用量排名第一的 Web 自动化测试工具，市场占有率超过 40%，比 Playwright 和 Cypress 加起来还多。

为什么？因为 Selenium 有三个 AI 测试框架永远比不了的优势——这就是它的「护城河」。

3.1 真正的「浏览器兼容性之王」

这是 Selenium 最核心的护城河，没有之一。

AI 测试框架们吹得再凶，你问它们一句：支持 IE 吗？支持 Safari 吗？支持各种奇葩的国产浏览器吗？

它们马上就支支吾吾了。

Playwright：IE？都 2025 年了还有人用 IE？（不支持）
Cypress：Safari？我们正在做，快了快了（做了 5 年了还没完全支持）
Midscene：国产浏览器？我们只测过 Chrome……

而 Selenium 呢？

• ✅ Chrome：完美支持
• ✅ Firefox：完美支持
• ✅ Safari：完美支持
• ✅ Edge：完美支持
• ✅ IE 11：完美支持（虽然微软都放弃了）
• ✅ 360 浏览器、QQ 浏览器、搜狗浏览器：只要是基于 Chromium 的，全都支持
• ✅ 甚至还有人用 Selenium 测任天堂 Switch 上的浏览器！

这对于某些行业来说，是致命刚需。

举个真实的例子：我有个朋友在银行做测试，他们的系统必须支持 IE 11，因为很多企业客户的财务电脑还在跑 Windows 7 + IE 11。你跟他们说「别用 Selenium 了，用 AI 测试框架吧」，他们只能回你一句：「你先让 AI 框架支持 IE 11 再说」。

还有那些做政企项目、国企项目的，浏览器兼容性要求能把人逼疯，这种时候，除了 Selenium，你根本没得选。

3.2 20 年积累的「生态帝国」

Selenium 发展了 20 年，已经不是一个工具了，而是一个完整的「生态帝国」。

你需要的任何功能，都有现成的解决方案：

• 报告？Allure、ExtentReports 随便挑
• 日志？Log4j、SLF4J 无缝集成
• 数据驱动？TestNG、JUnit、Pytest 原生支持
• 分布式执行？Selenium Grid 开箱即用
• 移动端？Appium 就是基于 Selenium 做的
• 性能测试？JMeter 可以和 Selenium 无缝集成

更重要的是，全世界有几千万测试工程师会用 Selenium。你去任何一个招聘网站搜「测试工程师」，10 个有 8 个要求会 Selenium。

这意味着什么？

• 你招人的时候，不需要花三个月培训，来了就能上手
• 你遇到问题的时候，Stack Overflow 上一搜就有答案
• 你需要插件的时候，GitHub 上随便搜就有现成的

而 AI 测试框架呢？

• 文档不全，很多功能全靠猜
• 遇到问题，Stack Overflow 上搜不到，只能去 GitHub 提 Issue，等作者一周后回复
• 招人？你去招聘网站搜「Midscene 工程师」，全国能找出 100 个就算我输

这就好比：Selenium 是 Windows，虽然毛病多，但软件多、用户多、修电脑的也多；AI 测试框架是某个小众 Linux 发行版，虽然性能好、界面酷，但出了问题你连个帮忙的人都找不到。

3.3 「代码级别的控制力」是 AI 永远给不了的

AI 测试框架很爽，ai("点击登录按钮") 一行就搞定了。

但是——

• 如果我就是不想点那个写着「登录」的按钮，我想点那个隐藏的、没有文字的登录按钮呢？
• 如果我就是要验证这个按钮的 className 是不是 btn-primary 呢？
• 如果我就是要在点击之前，先修改一下这个元素的某个属性呢？
• 如果我就是要执行一段非常复杂的 JS 逻辑，然后再做操作呢？

AI 说：对不起，我做不到。我只认我「看」到的东西。

而 Selenium 呢？你想怎么玩就怎么玩：

// 直接操作 DOM 属性
((JavascriptExecutor) driver).executeScript(
    "arguments[0].setAttribute('data-test', 'clicked');",
    button
);

// 获取元素的计算样式
String bgColor = (String) ((JavascriptExecutor) driver).executeScript(
    "return window.getComputedStyle(arguments[0]).backgroundColor;",
    button
);

// 甚至可以直接修改页面的 HTML
((JavascriptExecutor) driver).executeScript(
    "document.body.innerHTML = '<h1>我把页面改了！</h1>';"
);

这是「代码级别的控制力」，是 AI 测试框架永远给不了的。

对于做底层测试、兼容性测试、安全性测试的工程师来说，这种控制力是刚需。AI 测试框架就像是傻瓜相机，随手就能拍出不错的照片，但专业摄影师还是会用手动单反——因为他们需要精确控制每一个参数。

3.4 真实案例：某大厂为什么还在坚持用 Selenium？

我问过阿里某 BU 的测试负责人：「你们现在还用 Selenium 吗？」

他的回答很有意思：「用啊，怎么不用。我们的 AI 测试平台底层是 Playwright，但我们对外提供的接口还是 Selenium 兼容的。为什么？因为我们有几万套历史用例，总不能全删了重写吧？」

这就是另一个非常现实的原因：历史包袱。

很多公司，Selenium 用例已经积累了五六年，几千、几万条，覆盖了整个业务流程。你说「别用 Selenium 了，换成 AI 测试框架吧」——好，这几万条用例谁来改？改完了谁来验证？出了问题谁来负责？

这笔账算下来，很多公司的选择是：继续用 Selenium，慢慢往 AI 方向迁移，而不是全盘推翻。

---

第四部分：实战对比——AI 原生框架 vs Selenium + AI 插件，谁更香？

说了这么多理论，咱们来点干货：我做了个实测，对比「AI 原生框架」和「Selenium + AI 插件」到底谁更好用。

测试场景

电商网站的完整购物流程：

1. 打开首页
2. 搜索「iPhone 16 Pro」
3. 点击第一个商品
4. 选择「256G 深空黑」
5. 点击「加入购物车」
6. 验证购物车数量 +1

方案一：AI 原生框架（Midscene）

// Midscene 写法 - 总计 8 行代码
import { test } from '@midscene/core';

test('购物流程测试', async ({ ai }) => {
  await ai.goto('https://demo-shop.com');
  await ai('在搜索框输入 iPhone 16 Pro，然后按回车搜索');
  await ai('点击第一个商品，进入商品详情页');
  await ai('选择 256G 版本，颜色选择深空黑');
  await ai('点击加入购物车按钮');
  await ai('验证购物车图标右上角的数字变成 1');
});

测试结果：

• ✅ 代码量：8 行
• ✅ 编写时间：3 分钟
• ✅ 执行时间：18 秒
• ✅ 稳定性：10 次运行 10 次成功
• ❌ 缺点：不支持 IE，无法精确控制元素属性

方案二：传统 Selenium 写法

// 传统 Selenium 写法 - 总计 68 行代码
public class ShoppingTest {
    private WebDriver driver;
    
    @BeforeMethod
    public void setup() {
        driver = new ChromeDriver();
        driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10));
    }
    
    @Test
    public void testShoppingFlow() {
        // 打开首页
        driver.get("https://demo-shop.com");
        
        // 搜索商品
        WebElement searchBox = driver.findElement(By.cssSelector(".search-input"));
        searchBox.clear();
        searchBox.sendKeys("iPhone 16 Pro");
        searchBox.sendKeys(Keys.ENTER);
        
        // 等待搜索结果加载
        WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(15));
        wait.until(ExpectedConditions.visibilityOfElementLocated(
            By.cssSelector(".product-list .product-item")
        ));
        
        // 点击第一个商品
        List<WebElement> products = driver.findElements(
            By.cssSelector(".product-list .product-item")
        );
        products.get(0).click();
        
        // 切换到新标签页
        ArrayList<String> tabs = new ArrayList<>(driver.getWindowHandles());
        driver.switchTo().window(tabs.get(1));
        
        // 选择版本和颜色
        wait.until(ExpectedConditions.elementToBeClickable(
            By.xpath("//div[@class='sku-option']//span[text()='256G']")
        )).click();
        
        wait.until(ExpectedConditions.elementToBeClickable(
            By.xpath("//div[@class='sku-option']//span[text()='深空黑']")
        )).click();
        
        // 点击加入购物车
        WebElement addToCartBtn = wait.until(ExpectedConditions.elementToBeClickable(
            By.cssSelector(".btn-add-to-cart")
        ));
        
        // 滚动到可见区域
        ((JavascriptExecutor) driver).executeScript(
            "arguments[0].scrollIntoView({block: 'center'});",
            addToCartBtn
        );
        
        // 点击
        addToCartBtn.click();
        
        // 验证购物车数量
        wait.until(ExpectedConditions.textToBePresentInElementLocated(
            By.cssSelector(".cart-count"), "1"
        ));
    }
    
    @AfterMethod
    public void teardown() {
        driver.quit();
    }
}

测试结果：

• ❌ 代码量：68 行
• ❌ 编写时间：45 分钟
• ❌ 执行时间：32 秒
• ⚠️ 稳定性：10 次运行 7 次成功（3 次因为元素定位失败）
• ✅ 优点：支持所有浏览器，可以精确控制每个元素

方案三：Selenium + AI 插件（Selenium AI）

这是折中的方案：用 Selenium 做底层，加上 AI 插件来增强元素定位。

// Selenium + AI 插件写法 - 总计 22 行代码
public class ShoppingTestWithAI {
    private WebDriver driver;
    private SeleniumAI ai;
    
    @BeforeMethod
    public void setup() {
        driver = new ChromeDriver();
        ai = new SeleniumAI(driver); // 初始化 AI 插件
    }
    
    @Test
    public void testShoppingFlow() {
        driver.get("https://demo-shop.com");
        
        // AI 定位搜索框
        ai.find("搜索框").sendKeys("iPhone 16 Pro", Keys.ENTER);
        
        // AI 点击第一个商品
        ai.find("第一个商品").click();
        
        // 切换标签页（Selenium 原生处理）
        ArrayList<String> tabs = new ArrayList<>(driver.getWindowHandles());
        driver.switchTo().window(tabs.get(1));
        
        // AI 选择规格
        ai.find("256G 选项").click();
        ai.find("深空黑 选项").click();
        
        // AI 点击加入购物车
        ai.find("加入购物车按钮").click();
        
        // 验证购物车数量（混合 AI + 原生断言）
        WebElement cartCount = ai.find("购物车数量标记");
        Assert.assertEquals(cartCount.getText(), "1");
    }
    
    @AfterMethod
    public void teardown() {
        driver.quit();
    }
}

测试结果：

• ✅ 代码量：22 行（比纯 Selenium 少 2/3）
• ✅ 编写时间：10 分钟（比纯 Selenium 快 4 倍）
• ✅ 执行时间：24 秒（比纯 Selenium 快 25%）
• ✅ 稳定性：10 次运行 9 次成功（只有 1 次因为 AI 定位错误）
• ✅ 优点：保留了 Selenium 的全部能力，又有 AI 的便捷性

对比总结

维度	AI 原生框架	传统 Selenium	Selenium + AI 插件
代码量	🌟 极少	😭 很多	✅ 适中
编写速度	🌟 极快	😭 很慢	✅ 较快
执行速度	🌟 最快	😭 最慢	✅ 中等
稳定性	🌟 很高	😭 一般	✅ 较高
浏览器兼容性	😭 一般	🌟 最好	🌟 最好
控制力	😭 有限	🌟 极强	🌟 极强
学习成本	🌟 极低	😭 极高	✅ 中等

结论很明显：

• 如果你是新项目，只需要测 Chrome，追求开发速度 → 选 AI 原生框架
• 如果你是老项目，有历史包袱，需要兼容各种浏览器 → 选 Selenium + AI 插件
• 如果你还在写纯 Selenium 代码，一行 AI 都不用 → 那你真的该醒醒了！

---

第五部分：给测试团队的迁移建议——不是非黑即白，而是混合方案

看到这里，你应该明白我要说什么了：Selenium 和 AI 测试框架不是你死我活的敌对关系，而是互补的合作关系。

我给不同阶段的测试团队准备了不同的迁移方案，对号入座就行。

方案 A：初创团队 / 新项目（0-1 阶段）

推荐方案：100% AI 原生框架（Midscene / Applitools）

• ✅ 没有历史包袱，轻装上阵
• ✅ 新人学习成本低，半天就能上手
• ✅ 开发速度快，能快速跟上业务节奏
• ✅ 只需要支持主流浏览器（Chrome / Edge）
• ❌ 注意：如果需要兼容 IE / Safari，慎重选择

技术栈建议：

• 前端项目：Midscene + Playwright
• 移动端：Appium 2.0 + AI 插件
• 跨端：Testim

方案 B：中型团队 / 成熟项目（1-100 阶段）

推荐方案：Selenium 为主，AI 为辅，逐步迁移

1. 保留核心用例： 已经稳定运行的几千条 Selenium 用例，别乱动
2. 新用例用 AI： 新增的测试用例，优先用 AI 方式写（Selenium + AI 插件）
3. 重构高频修改的用例： 那些每个月都要改好几次的用例，换成 AI 写法
4. 保留兼容性测试用例： IE / Safari 兼容性测试，继续用 Selenium

技术栈建议：

• 底层：Selenium 4.x
• AI 增强：Selenium AI / Applitools Eyes
• 执行：Selenium Grid
• 报告：Allure + AI 失败分析

方案 C：大型团队 / 企业级项目（100+ 阶段）

推荐方案：双轨制，构建统一测试平台

1. 统一测试平台： 封装底层，上层既支持 Selenium 语法，也支持 AI 语法
2. 用例分层：
   • L1 兼容性测试：Selenium（全浏览器覆盖）
   • L2 功能测试：Selenium + AI 混合（稳定 + 高效）
   • L3 端到端场景测试：100% AI 原生框架（追求速度和维护性）
3. AI 辅助维护： 用 AI 自动修复 Selenium 用例中的元素定位问题

我见过最好的实践是某大厂的做法：

• 他们的测试平台底层同时集成了 Selenium 和 Playwright
• 测试用例可以用自然语言写，平台自动翻译成对应的执行代码
• 同一个用例，既可以在 Selenium 上跑（兼容性测试），也可以在 Playwright 上跑（日常回归）
• AI 会自动分析失败的用例，如果是元素定位变了，自动生成新的定位器

---

总结：Selenium 不会死，只是变了个活法

最后，回到文章开头的问题：Selenium 还有存在的必要吗？

我的答案是：有，而且非常有必要。但是 Selenium 会变——它不会再是那个你每天手写 XPath 的 Selenium 了。

我对未来的三个预测：

预测一：Selenium 会原生集成 AI 能力

Selenium 官方已经意识到了这个问题，Selenium 4.0 之后一直在往 AI 方向靠。我预测 2026 年之前，Selenium 会原生集成 AI 元素定位能力，到时候你写的代码会变成这样：

// 未来的 Selenium 写法
driver.findByAI("那个蓝色的写着'提交'的按钮").click();

是的，你没看错——Selenium 自己也在变。

预测二：「纯 Selenium 工程师」会消失，但「懂 Selenium 的测试工程师」会更值钱

以后不会有人专门招「Selenium 工程师」了，就像现在不会有人专门招「会用鼠标的工程师」一样。

但是——

• 你知道 Selenium 的底层原理，你才能更好地用 AI 测试框架
• 你知道怎么写稳定的定位器，你才能更好地训练 AI 模型
• 你知道浏览器是怎么工作的，你才能更好地排查 AI 测试的问题

AI 是工具，不是替代品。 会用 AI 的测试工程师，会淘汰不会用 AI 的测试工程师；但懂原理的测试工程师，会淘汰只会用 AI 的测试工程师。

预测三：AI 测试和 Selenium 会走向融合

2 年之后，不会再有人争论「用 AI 测试还是用 Selenium」，就像现在不会有人争论「用自动挡还是手动挡」一样——因为好的车会同时给你两个选项。

你想省心？D 挡踩油门就走（AI 自动测试）。
你想操控？切手动挡自己换挡（Selenium 精确控制）。

工具从来都不是问题，问题是你会不会根据场景选合适的工具。

最后说句掏心窝子的话

我那个写了 12 年 Selenium 的老同事，现在已经是我司 AI 测试平台的负责人了。

我问他：「你之前不是很抵触 AI 测试吗？」

他说：「我抵触的不是 AI，是那些说『Selenium 要死了』的人。Selenium 陪了我 12 年，我靠它买房买车养家糊口，我比谁都希望它好。但好不是抱着它不变，而是让它跟着时代一起进步。」

是啊，时代变了。

• 2004 年 Selenium 出生的时候，我们还在用诺基亚
• 2014 年 Selenium 2.0 发布的时候，微信才刚出来
• 2024 年的今天，大模型都能自己写测试用例了

那个陪了我们 20 年的老伙计，它不会死，它只是换了个活法。

而我们这些测试工程师，也该换个活法了。

---

写在最后： 这篇文章写了整整一周，采访了 8 个测试行业的朋友，做了 3 组实测对比。如果你觉得有用，欢迎点赞收藏转发。也欢迎在评论区聊聊你的看法：你现在还在用 Selenium 吗？你觉得 AI 测试会取代 Selenium 吗？

参考资料：

1. Selenium 官方文档 - https://www.selenium.dev/
2. Midscene 技术博客 - https://midscene.ai/blog/why-not-selenium
3. Stack Overflow 2024 开发者调查
4. Applitools 2024 AI 测试行业报告