做 Web 自动化这些年Selenium 基本是我最早接触的框架。前几年只要聊自动化大家默认就是去写 WebDriver 脚本但这两年越来越多的人开始吐槽脚本慢、用例脆、前端一改就挂连驱动下载都要小心翼翼配版本。我也被这些问题折磨过很多轮后来陆续上手 Playwright、Puppeteer、Cypress、DrissionPage 这类工具才意识到“低效脚本”很多时候不是写代码的人不行而是 Selenium WebDriver 这套同步命令模型本身把效率和稳定性限制住了。这篇文章就结合我之前写脚本、跑自动化测试、维护回归用例时踩过的坑聊 8 款更省事的 Selenium 替代工具。覆盖 UI 自动化测试、浏览器爬虫脚本、老用例渐进迁移等场景。不管你是测试开发、后端偶尔写爬虫还是前端想给页面做回归应该都能从里面找到适合自己的一款。1. 为什么越来越多人想换掉 Selenium先看清楚瓶颈在哪1.1 WebDriver 的同步命令天生就容易“一问一答”Selenium 的操作模型基于 WebDriver 协议每个 findElement、click、sendKeys 都像一次独立的远程调用。浏览器端执行完一条再等客户端下一条指令中间还有网络转发和驱动进程的损耗。对普通网页来说问题不大但一旦页面是重度 SPA元素加载顺序由接口和数据状态决定这种同步模型就会被放大成大量等待和超时。可以打个比方WebDriver 像你打电话给另一个人让他帮你操作电脑你说一句他做一步还要不断确认“看到按钮了吗”“点击成功了吗”。而现代工具更多是直接坐在电脑前操作或者能订阅浏览器内部的事件流状态一变就知道该干什么。后者显然更省事。Playwright、Puppeteer 这类工具底层转向了 Chrome DevTools Protocol也就是 CDP很多操作并不需要像 WebDriver 那样每个命令都走一遍完整请求链整体体感会轻快不少。1.2 隐式等待解决不了动态页面显式等待又写到手酸Selenium 官方建议不要同时使用隐式等待和显式等待否则超时时间会叠加很容易出现“本来 5 秒能等出来结果硬生生等了 20 秒”的怪现象。可现实里大家图省事要么直接开一个全局隐式等待要么在关键操作前塞time.sleep(2)。前端加载快的时候sleep 纯属浪费时间前端加载慢的时候2 秒又不够用。等得短了报 no such element等得长了整个脚本变成龟速。显式等待能精准一些但每条关键操作都要写WebDriverWait(driver, 10).until(EC.element_to_be_clickable(...))脚本一多代码量蹭蹭涨。我见过一个维护了两年的 UI 回归项目一千多行脚本里至少有三分之一代码和“等待”相关真正在验证业务逻辑的反而不多。这个问题不是靠“更会写 Selenium”能解决的而是框架本身需要提供更聪明的默认策略。现代替代工具基本都内置了动作可用性等待元素不可见就一直等可点击才去点中间不需要开发者自己手写各类 ExpectedConditions。1.3 驱动与浏览器版本绑定连安装这一步都劝退很多人热搜里有“web自动化selenium浏览器驱动怎么判断下载哪个区别”说明大家被这个问题卡过。Chrome 每个大版本更新chromedriver 版本就要跟着换还要搞清楚 driver 和本地 Chrome 版本号第一位要对齐。浏览器自动更新一次第二天 CI 里的用例就可能全部失败报错信息还特别抽象。想当年 Selenium 2/3 时代要额外配 selenium-server到了 4 虽然情况好点但 chromedriver 的下载问题仍然没有消失。替代方案里要么像 Puppeteer 安装时直接下载配套 Chromium要么像 Playwright 提供一个playwright install命令自动装好所有浏览器要么像 DrissionPage 那样直接接管本机已有的 Chrome 调试端口。对只想写业务脚本的人来说省掉驱动配置这一步已经能节约大量无意义时间。1.4 脚本健壮性差前一步挂了后面全线崩盘Selenium 脚本“脆”是出了名的。页面结构一变XPath 失效某个异步接口稍微慢一点下一步点不到弹窗、iframe、新标签页只要切换时机不对马上报错。最让人头疼的是 Selenium 没有默认的失败重试机制用例一旦挂掉就要靠外层框架来做恢复和重跑。不是说 Selenium 完全不能做好只是它提供的是“底层能力”真正要跑得稳还得自己搭建很多基础设施。后来我转到自带超时重试、自动等待、拦截网络请求的工具时最大的感受不是“功能更多”而是“脚本不再那么容易被临时问题打断”。维护成本下降才敢把自动化用例的数量扩起来。2. 8 款更省事的替代工具先按场景把方向定下来2.1 先看总表快速定位你属于哪类使用者很多人看到“8 款工具”就头大觉得又要学一堆新东西。其实不用。工具没有绝对优劣只有适不适合当前场景。下面这张表我按“工具类型、底层思路、主语言、典型场景”做了个归纳你可以先凭直觉找到最接近自己处境的那个。工具底层思路主要语言最擅长场景PlaywrightCDP 自建跨浏览器协议支持 Chromium/Firefox/WebKitPython / Node / Java / .NETUI 自动化测试、跨浏览器回归、爬虫、录制生成脚本Cypress浏览器内运行测试代码配套 Runner 调试JavaScript / TypeScript前端开发本地自测、组件级到端到端回归PuppeteerCDP直接操作 ChromiumNode.jsChrome 批量截图、PDF、采集脚本、轻量任务编排DrissionPage控制本地 Chrome 调试端口页面与数据包双模式PythonPython 生态下的浏览器操作、网页数据采集WebdriverIO兼容 WebDriver 协议也可切 DevTools 模式JavaScript / TypeScript老 Selenium 团队平滑迁移、JS 技术栈的测试项目SeleniumBase对 Selenium 做封装增强底层仍是 WebDriverPython不想抛弃 Selenium 但又想省写法、自带报告的人TestCafe无 WebDriver自带浏览器驱动层JavaScript / TypeScript免配置驱动、远程浏览器、云测试环境Katalon Studio低代码平台内部集成多种自动化方案图形化 Groovy/Java 脚本质量团队低代码搭用例、测试资产管理2.2 主攻 UI 自动化回归Playwright 与 Cypress如果目标是正儿八经的 Web UI 回归测试我最推荐先看 Playwright。它解决了 Selenium 最痛的几个点默认等待、自动重试、多页面上下文、拦截网络请求、录制脚本。你用playwright codegen打开一个站点点几次按钮它能直接生成一份可用的测试脚本自己再改成断言的逻辑就行。初次接手的人可以在十分钟内跑通第一个用例这种正向反馈在 Selenium 时代几乎不可能。Cypress 适合离前端更近的团队。它不是在外面驱动浏览器而是直接跑在浏览器里Runner 界面会记录每一步操作前后的页面快照断言失败时你能像看录像一样看到当时页面长什么样。对前端开发来说写完组件后用 Cypress 补一条冒烟测试非常顺手不需要额外维护 driver 和远程浏览器。不过它的多标签页和跨域支持没有 Playwright 那么开放如果你重度依赖多窗口操作建议提前验证。2.3 主攻浏览器脚本与数据采集Puppeteer 与 DrissionPage如果你的“自动化”主要不是测试而是想写脚本批量处理页面Puppeteer 是 Node 生态里很成熟的选择。Puppeteer 安装时会自动下载 Chromium不需要去配 chromedriver。它的 API 围绕 page 对象展开跳转、点击、截图、导出 PDF、拦截请求写起来比 Selenium 丝滑很多。像是浏览器长期驻留、重复点击、记录状态变化这种“设备老化测试全自动执行脚本”用它控制单个浏览器实例反而更稳不用反复创建新进程。Python 生态下DrissionPage 是这几年口碑上涨很快的库。它不像 Selenium 那样要求先启动一个“受控浏览器”而是直接通过调试端口连接本机已经打开的 Chrome所以很多 Selenium 时代常见的“webdriver 被识别”“driver 版本不匹配”问题都绕开了。对只想做数据采集、页面填报、简单批量操作的人来说DrissionPage 的代码可读性好上手成本比 Playwright Python 还要低一些。2.4 想低代价离开裸 SeleniumSeleniumBase 与 WebdriverIO有人会问我的团队代码全是 Selenium直接换 Playwright 风险太大有没有过渡选项有。SeleniumBase 严格说是 Selenium 的增强封装但它替代了你原来“裸写 WebDriver”的体验。它把常见等待、失败截图、报告生成、录制、Pytest 插件都做成了默认能力。老用例可以一行一行搬过来大部分 findElement 写法都能映射成更简洁的 API。WebdriverIO 是 JavaScript/TypeScript 世界里比较老牌的测试框架。它既支持 WebDriver 协议也能选择 DevTools 协议跑。这个属性让它很适合从 Selenium JS 写法迁移过来的团队。你的既有测试对象、断言风格、Page Object 设计基本能延续但换上了更现代的异步 API 和命令式等待写起来干净不少。如果团队前端基础不错把 WebdriverIO 和 WDIO 的插件体系用起来效果不会比 Cypress 差太多。2.5 不想自己维护一堆脚本TestCafe 与 Katalon StudioTestCafe 最大的卖点是不需要 WebDriver也不需要你手动下载浏览器驱动。它会自己找到本机安装的浏览器并建立连接对远程浏览器、云测试平台的支持也比较友好。如果你只是希望回归用例能稳定跑起来不想每天处理驱动和浏览器版本之间的关系TestCafe 可以当做一个省心选项。Katalon Studio 则更偏平台型工具。它把页面对象、测试用例、测试套件、报告和 CI 集成都做成图形化界面不会编程的人也能录制操作生成用例。当然它商业味道比较重还引入了自己的工程结构和存储格式小团队或个人项目用起来可能觉得笨重。但如果你在给一个不懂代码的质量团队搭自动化体系Katalon 这类低代码工作台确实比教他们写 Selenium 要现实得多。3. 换工具之前先判断这三个问题3.1 你是想解决“测试管理”问题还是“脚本效率”问题很多人动不动就说要换掉 Selenium但聊深了发现团队真正缺的不是工具而是用例组织和结果管理。如果只是觉得脚本乱、等待满天飞那么像 SeleniumBase 这种轻量封装就能解决不少问题不必立刻全盘迁移到新语法。如果问题是“每个前端版本迭代都要花两天修定位器”那从 XPath 依赖里跳出来才是关键这时候选用 Playwright 或 Cypress配合 testid、role 这类更稳定的定位策略效果会明显很多。我自己建议先用两周时间给现有脚本做个体检统计一下因为等待失败的比例、因为定位器变更失败的比例、因为环境或驱动问题失败的比例。哪个占比最高就选针对这个痛点的工具而不是只听说“Playwright 很火”就立刻重写全部用例。3.2 团队技术栈和浏览器矩阵决定了迁移成本如果你所在的团队只会 Python硬要迁移到 Cypress 是给自己找麻烦。Python 技术栈下最平滑的选择是 Playwright Python或者 DrissionPage如果还想沿用 unittest/pytest 的习惯SeleniumBase 也不错。如果团队本来就是 Node 技术栈Cypress 和 WebdriverIO 会容易落地Puppeteer 也能作为轻量脚本补充。还要考虑浏览器覆盖要求。只测试 Chrome 内核几乎上面提到的工具都能胜任。如果正式环境还要覆盖 Firefox、Safari那么优先考虑 Playwright因为它的跨浏览器支持是相对完整的。WebdriverIO 也能接不同的 driver但需要额外配置Cypress 对 Safari 的支持不算好适合纯 Chrome 场景的快速反馈。3.3 旧 Selenium 用例别急着推翻关键是切成小步走我见过程序员打算用一个周末把所有 Selenium 代码改写成 Playwright结果改到一半发现很多用例本身就有问题并不是 Selenium 写不出来而是产品逻辑已经变了。与其花大力气一次性迁移我更推荐“新用例新工具老用例按模块迁移”。比如首页、登录、订单这几条核心链路先用新工具写一版和旧脚本并行跑一个星期对比结果一致性和维护时间。等团队熟悉了新工具再把老脚本里经常失败的模块挑出来迁移。这样每次交付都能验证一版风险会小很多。别被网上那些“三分钟迁移全部用例”的文章骗了真实项目里最大的成本从来不是 API 差异而是业务规则梳理和定位器策略调整。4. 实操对比同样的“登录搜索”不同工具写法差多少4.1 Selenium 传统写法等待写到手酸下面是用 Selenium 完成一个“登录后搜索”的 Python 示例。为了稳定我不得不频繁加显式等待代码里到处是 WebDriverWait。from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC driver webdriver.Chrome() driver.get(https://example.com/login) driver.find_element(By.ID, username).send_keys(tester) driver.find_element(By.ID, password).send_keys(password123) driver.find_element(By.CSS_SELECTOR, button[typesubmit]).click() search WebDriverWait(driver, 10).until( EC.element_to_be_clickable((By.CSS_SELECTOR, .search-box)) ) search.send_keys(selenium) search.send_keys(\n) driver.quit()这段代码能跑但它默认了页面跳转不会超过 10 秒也默认了输入框一定可以立即输入。真实项目里如果登录接口慢一点search按钮还没渲染出来脚本就挂了。Selenium 使用者的日常就是在这些 WebDriverWait 里反复调超时时间。4.2 Playwright把操作可用性判断交给框架同一个场景用 Playwright 写是这样的from playwright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch(headlessFalse) page browser.new_page() page.goto(https://example.com/login) page.fill(#username, tester) page.fill(#password, password123) page.click(button[typesubmit]) # fill 会自动等待元素可见、可用 page.fill(.search-box, playwright) page.keyboard.press(Enter) browser.close()注意我不需要手工写显式等待。Playwright 的fill、click会等待元素被附加到 DOM、可见、不被遮挡、可交互默认超时时间可以全局配置超时后的报错信息还会告诉你具体卡在哪一步。这种默认规则让脚本的耐药性强了很多。4.3 Puppeteer适合 Node 里的批处理任务Puppeteer 写起来和 Playwright 有点相似但语言环境更偏向 Node.jsconst puppeteer require(puppeteer); (async () { const browser await puppeteer.launch({ headless: new }); const page await browser.newPage(); await page.goto(https://example.com/login); await page.type(#username, tester); await page.type(#password, password123); // 点击登录同时等待页面跳转避免丢失导航事件 await Promise.all([ page.waitForNavigation(), page.click(button[typesubmit]) ]); await page.type(.search-box, puppeteer); await page.keyboard.press(Enter); await browser.close(); })();Puppeteer 的 API 比较贴近底层如果你想控制浏览器的每个行为细节它很合适。上面的Promise.all是个经验点点击按钮触发跳转时先注册waitForNavigation()再执行 click能避免导航事件被错过。Selenium 时代很多人就是因为少了这一步时不时会看到点击已经发生但脚本仍在等待下一页元素的诡异问题。4.4 Cypress前端自测的体验确实舒服如果这个登录流程交给前端开发做自测Cypress 的体验会更快乐describe(login flow, () { it(logs in and searches, () { cy.visit(/login); cy.get(#username).type(tester); cy.get(#password).type(password123); cy.get(button[typesubmit]).click(); cy.get(.search-box, { timeout: 10000 }).type(cypress{enter}); cy.url().should(include, /search); }); });Cypress 命令自带重试不需要每行都写等待。它最大的差异是 Runner 界面会在每一步旁边留下页面快照断言失败时你直接点一下命令就能看到当时 DOM 状态排错成本很低。不过需要注意Cypress 对多标签页和跨域页面的访问限制比较多如果你的系统经常弹出新窗口或者跳到另一个域名执行第三方登录要先确认这个工具能不能覆盖。4.5 DrissionPagePython 爬虫脚本的“无驱动”体验最后看看 DrissionPage。它连接本机 Chrome 的调试端口不需要下载 driver也不要求浏览器处于传统“受控模式”。这也是它让很多爬虫和办公自动化脚本维护者眼前一亮的原因。from DrissionPage import ChromiumPage, ChromiumOptions co ChromiumOptions() # 指定本机 Chrome 的用户数据和端口首次需要手动开启调试端口 co.set_local_port(9222) page ChromiumPage(co) page.get(https://example.com/login) page.ele(#username).input(tester) page.ele(#password).input(password123) page.ele(button[typesubmit]).click() page.ele(.search-box).input(drip)DrissionPage 的.ele()返回元素对象.input()会补齐输入细节。它没有 Playwright 那么庞大的跨浏览器野心但如果你只和 Chrome 打交道熟悉之后会觉得 Python 脚本写起来能少很多 Selenium 的仪式感代码。上面的几段代码并不是让你全部学而是提供一个直观感受不同工具不只是语法不同连“需要显式处理等待”这件事都从框架层面被优化