被 Selenium 的等待、驱动和诡异异常折腾到怀疑人生之后我花了两周时间把自己经手的几个自动化脚本项目的技术选型整体过了一遍。这篇关于 Selenium 替代工具的文章就是这次选型和迁移过程的完整记录。文章不为评价谁好谁坏更像一份实测笔记——8 款工具我都跑了实际项目有些已经迁移完成有些试完发现不适合整个过程踩了不少坑也总结出比较清楚的选型思路。如果你平时会用 Selenium 写 UI 自动化测试或采集脚本最近正觉得它越来越笨重那这篇文章主要是写给你看的。先说结论如果只让我推荐一款在大多数常规 Web 自动化场景里我的首选是 Playwright。但最合适这件事永远取决于你的项目类型、语言栈和现有基建。所以下面我会按为什么想换、换之前想什么、每款工具适合谁、迁移怎么落地的顺序来写尽量给出能直接照着做的东西而不是罗列一堆宣传语。1. Selenium 用久了最让人崩溃的几个场景在聊工具之前得先把 Selenium 真正让人难受的地方说清楚。我不是为了追新才换工具而是下面这几个场景实在出现太频繁频繁到已经严重影响脚本开发和维护效率。1.1 等待策略靠 time.sleep 续命的脚本Selenium 官方推荐用 WebDriverWait 配合 expected_conditions 做显式等待这听起来很标准但落到真实页面上完全不是那么回事。元素出现要等接口返回按钮可点要等某个遮罩层消失弹窗要等动画跑完这种动态中的动态很难用现成的条件函数描述清楚。于是大多数脚本最后都会演变成这种写法time.sleep(3) driver.find_element(By.ID, submit).click() time.sleep(2) # ...这类脚本在你自己的电脑上跑得顺顺的丢到 CI 或客户现场就开始随机失败。把 sleep 调大脚本跑一次要十几分钟调小又陷入偶发失败—手动重跑—再失败的循环。Selenium 对元素可操作这件事缺乏完整定义等于把等待策略的工程问题全部甩给了开发者这是低效感的最大来源。1.2 驱动版本地狱Chrome 一更新脚本就翻车用 Selenium 的人几乎都经历过浏览器驱动版本不匹配的报错。Chrome 自动更新到新版chromedriver 没跟上session not createdFirefox 升级geckodriver 又出问题。个人电脑上还好脚本一旦进了 CI驱动管理就变成正经工程问题你得在构建环境里安装与浏览器版本精确匹配的驱动还要在每次浏览器升级后跟着更新。很多团队为了省事直接把浏览器自动更新锁死但这又会带来安全补丁滞后的问题。这批替代工具里绝大多数已经把浏览器版本管理内置了一条命令完成浏览器下载和配套驱动安装单这一项就省掉巨大的维护成本。1.3 异常排查的黑暗时刻Selenium 跑挂之后你看到的通常是在某个定位器上找不到元素这类信息但页面当时究竟渲染到什么程度、哪个异步请求没返回、有没有弹层挡住了点击一概不知。排查流程就变成了重跑一遍、加截图、加日志、看 DOM运气好一次定位运气不好反复折腾好几个小时。更别提 StaleElementReferenceException、ElementClickInterceptedException 这些异常。字面意思都懂实际成因却千奇百怪有时候只是页面上多了一个悬浮 banner就足以让原本稳定的脚本全线飘红。工具本身不能提供足够丰富的现场上下文调试效率就永远上不去。1.4 页面结构一变定位代码全废用 Selenium 写脚本核心动作永远是 find_element 加 XPath 或 CSS。问题是现在前端组件化程度高、迭代频率快稍微重构一下 DOM 结构精心维护的定位器就会断掉一多半。如果工具不能提供更贴近用户视角的定位方式或者不具备快速生成和更新定位器的能力长期维护就是一场消耗战。这四点叠在一起让我逐渐意识到麻烦的根源不一定是我写的代码质量差而是 Selenium 把太多底层细节暴露给了使用方。带着这个判断我开始认真对比替代方案。2. 换工具之前先回答这四个问题很多人一进社区就问哪个工具能完全替代 Selenium这个问法本身就容易翻车。替代不是目的让脚本更省事才是目的。在动手安装任何新工具前我建议先把下面四个问题想清楚。2.1 用途功能测试还是数据采集这两个方向对工具的诉求差别非常大。功能测试看重用例组织、断言能力、失败重试、报告生成数据采集更看重页面渲染完整性、网络请求控制、会话保持、并发效率。Playwright 在两个方向上都比较全能Cypress 则几乎专为测试而生Puppeteer 更多出现在采集和浏览器自动化任务里。连用途都没想清楚选型一定会纠结。2.2 语言栈与团队维护成本Selenium 最宝贵的遗产之一是多语言支持Java、Python、C#、Ruby、JavaScript 都有官方绑定。但替代工具里有相当一部分以 JavaScript/TypeScript 为第一公民例如 Cypress、Puppeteer、Nightwatch.js 只在 Node 生态里运转。Python 团队想迁移最顺的是 Playwright 的 Python 版本其次是 Helium 这类基于 Selenium 的轻量封装。选型之前一定要确认这个仓库除了你之外还有谁会维护新同事的学习成本是否可控我见过不少团队因为某款工具看起来很酷就迁移过去结果大家都不会写最后代码质量比原来还差。2.3 是否已有 WebDriver 生态资产如果公司已经搭好了 Selenium Grid、云测平台或者有一套成熟的 WebDriver 基础设施完全不考虑兼容性会很可惜。WebdriverIO 走的正是保留 WebDriver 协议优化使用体验的路线迁移成本相对低。而 Playwright 基于 CDP 和自己的协议体系与传统的 WebDriver 设施无法直接打通需要单独规划执行环境。这个点很容易被忽略却往往决定迁移的实际工作量。2.4 运行环境与浏览器范围脚本要跑在无头服务器上吗要不要同时覆盖 Chrome、Firefox、Safari 的 WebKit 内核有没有 Docker 化部署的需求这些答案直接影响工具选型。例如你需要 WebKit 支持Playwright 的支持度就明显比 Puppeteer 好如果你只面对 Chromium 系Puppeteer 的体量和上手难度反而更低。先把真实运行环境记录下来再对照工具的兼容矩阵能少走很多弯路。3. Playwright我的主力推荐少写一半代码如果只选一款 Selenium 替代工具我会选 Playwright。它对开发体验的改善不是某一两个点而是系统性解决了我前面提到的等待、驱动、调试等问题。3.1 自动等待与可操作性检查去 time.sleep 化Playwright 对每个交互动作内置了一套可操作性检查。它会自动等待元素满足这些条件已附加到 DOM、可见、稳定、能接收事件、未被其他元素遮挡。也就是说你直接写 page.click框架会先把要素等齐再执行点击。常规的等待代码基本可以删掉。用 Selenium 写一个稳定点击往往要这样wait WebDriverWait(driver, 10) wait.until(EC.element_to_be_clickable((By.ID, submit))) driver.find_element(By.ID, submit).click()而 Playwright 里就是这样page.click(#submit)我用一个三十多步操作的真实流程做过对比用 Playwright 重写之后代码量减少了大概一半稳定性反而更高。不是说我从此完全不需要处理等待了而是 90% 的常规等待被框架消化掉了代码读起来像业务描述不再是一堆防御性逻辑。3.2 API 设计iframe、多标签页和下载不再是难题Selenium 切 iframe 要 switch_to.frame()切完还得记得切回去多标签页要维护 window_handles 集合下载文件得额外配浏览器偏好。Playwright 把这些交互做成了符合直觉的 APIiframe 用 frame_locator 直接定位多标签页通过独立的 page 对象天然隔离下载操作放进 expect_download() 上下文里就能捕获。iframe 是我以前最头疼的场景很多页面的核心交互都嵌在第三方 iframe 里switch 来 switch 去的逻辑很容易把人绕晕。换工具之后这类问题几乎不再出现代码可读性也上了一个台阶。3.3 浏览器上下文多账号场景的独立小房间Playwright 的 browser context 相当于完全隔离的浏览器会话每个 context 有独立的 Cookie、LocalStorage、缓存和 User-Agent。理解成一个账号一个独立的小房间就可以。以前用 Selenium 验证不同权限账号的页面表现只能退出再登录或者开多个浏览器实例处理 profile 冲突。现在创建多个 context每个 context 登录一个账号脚本可以并行操作互不干扰。做数据采集时的多账号轮换同样方便很多。3.4 网络拦截与 Mock把不稳定因素从脚本里隔离出去page.route() 可以拦截页面发出的请求自定义返回值、模拟延迟、直接中止某个资源加载。这个能力让脚本稳定性提高了一大截。以前页面里有个第三方统计接口超时整个用例跟着失败现在直接把这类与业务断言无关的请求 mock 掉让脚本只关心目标功能。调试接口异常场景也很顺手。想验证接口返回 500 时页面有没有正确展示错误提示不需要真的把后端搞挂route 一个 mock 响应就行。3.5 录制生成代码五分钟拿到可运行脚本playwright codegen命令会启动一个带记录功能的浏览器你在页面上正常操作工具就同步生成对应的 Python 或 JavaScript 代码。对快速熟悉一个陌生项目或者临时写一个一次性采集脚本来说这个功能效率极高先生成骨架再手工补上断言和边界处理就行。Playwright 当然也不是没有缺点。它跟传统 Selenium Grid 不兼容团队需要花时间重搭执行环境默认的自动等待在某些动画特别多的页面上会稍微多等一会儿。但对我来说整体收益远大于这些成本。4. Puppeteer轻量采集路线上的老朋友如果你是 Node.js 开发者主要任务是数据采集或页面截图、PDF 生成Puppeteer 可能比 Playwright 更轻、更直接。4.1 Chrome/Chromium 优先的定位适合谁Puppeteer 出自 Google Chrome 团队主打 Chromium 系浏览器的深度自动化。它不强调跨浏览器而是把 Chromium 的能力挖掘得很透。如果你的目标网站只在 Chromium 下验证过又希望库本身足够轻量Puppeteer 很合适。它的安装过程会自动下载配套的 Chromium 版本省掉了手动管理驱动的步骤。4.2 page.evaluate直接在页面上下文里取数据采集场景里最常用的是 page.evaluate()。它把一段 JavaScript 函数送到页面环境里执行然后返回结果。提取文章标题、正文、发布时间这类操作不用像 Selenium 那样反复 find_element 再取文本直接在页面里写 DOM 遍历就好const data await page.evaluate(() { return { title: document.querySelector(h1)?.innerText, content: document.querySelector(.article-body)?.innerText }; });配合 page.waitForSelector、page.waitForResponse 这些方法处理 SPA 动态加载内容比 Selenium 顺手很多。页面截图、生成 PDF、收集性能日志也都是 Puppeteer 的强项页面巡检、报告生成这类自动化任务几乎就是为它设计的。4.3 踩过的坑进程不退出和内存缓慢增长Puppeteer 最常见的坑有两个。第一个是忘记在任务结束调用 browser.close()导致 Node 进程一直不退出CI 任务卡死。第二个是长时间跑采集任务时内存缓慢爬升尤其是反复创建新页面却不关闭的场景。后来我养成了用完即关的习惯并且把长时间任务拆成批次定期重启进程释放内存。如果你担心项目以后可能要跑 Firefox 或 WebKit建议直接选 Playwright不要从 Puppeteer 起步。两者的 API 风格很接近先写 Puppeteer 再迁 Playwright 的成本不算高但绕一圈没必要。5. Cypress前端项目测试的另一种思路Cypress 和前几款工具不是一个路子。它不是从外部用脚本驱动浏览器而是在浏览器里运行测试。这个架构差异让它直接绕开了 Selenium 时代不少顽固问题。5.1 自动重试与用例隔离跑测试不容易碰运气Cypress 的每个用例默认从干净的浏览器状态开始前一个用例留下的 Cookie、缓存不会污染后一个用例。它的命令系统还内置自动重试机制cy.get() 找到一个元素后如果紧接着要点击Cypress 会反复检查元素状态直到它真的可操作。写过 Selenium 测试的人都懂一旦用例之间共享登录态跑的顺序一变结果就不可预测。Cypress 这种隔离模型让用例干净很多也更方便定位问题出在哪一步。5.2 时间旅行调试沿步骤回放页面状态Cypress 的 Test Runner 会保存用例执行过程中每一步的页面快照。调试时把鼠标悬停在某条命令上就能看到当时页面的真实状态。这个体验非常接近时间旅行比反复看截图和日志高效太多。我把测试从 Selenium 迁移到 Cypress 之后定位用例失败原因的速度明显变快。它的网络控制也做得不错cy.intercept() 可以对接口做 mock 或断言测试能直接跑在可控数据上不用依赖后端环境稳定。这特别对前端团队的胃口。5.3 为什么别拿它做采集Cypress 的边界也很明显它主要面向测试自己的应用对打开外部网站、跨域操作这类采集动作限制很严格。如果你是想找 Selenium 的替代品去抓别人的站点Cypress 基本不可行。可行的分工是前端项目自测用 Cypress浏览器自动化采集用 Playwright 或 Puppeteer各有各的阵地。6. 小而省的三款TestCafe、Taiko、Helium不是所有项目都需要迁移到 Playwright 这种全家桶级别的工具。如果你的核心痛点是Selenium 太啰嗦但现有基建还用得好好的下面三款提供了更轻的解法。6.1 TestCafe无驱动架构带来的省事体验TestCafe 来自 DevExpress最大的卖点是不需要 WebDriver也不需要额外装浏览器驱动。它通过在浏览器里注入脚本的方式执行测试配合内置的 Test Runner、自动等待和选择器开箱即用程度很高。多浏览器并发也省心一条配置就能同时跑 Chrome、Firefox 和 Edge。不过要坦诚提醒一句TestCafe 这几年的社区活跃度明显不如 Playwright 和 Cypress更新节奏放慢了。如果项目很在意长期维护方的活跃度选它之前要评估风险但如果你只是想把现有回归用例稳定跑起来它的完成度依然够用。6.2 Taiko让选择器变成看得见的东西Taiko 是 ThoughtWorks 出品的 Node 自动化库主打可访问性优先和接近自然语言的 API。它不需要你写一长串 CSS/XPath可以直接按按钮文字、输入框标签、元素相对位置来操作比如await goto(https://example.com); await write(hello, into(textBox({placeholder: 请输入}))); await click(登录);Taiko 内置了等待机制没有为元素出现而写一大堆显式等待的困扰。页面结构调整后只要用户能看到的文字没变很多脚本仍然能跑。这对受够了脆 XPath 的人来说是很大的解脱。6.3 Helium给 Selenium 套一个懒人壳Helium 在 Python 生态里比较特殊它名义上是 Selenium 的替代品实际是把 Selenium 包装成了更高级的 API。代码长这样start_chrome() click(登录) write(username, into用户名)Helium 底层自动处理元素定位、等待和浏览器启动日常脚本确实能写得简短很多。对已经在 Python 里沉淀了大量 Selenium 代码的团队Helium 可以在不推翻执行环境的情况下先把编写体验提上来。但它的封装也有天花板——一旦需要做底层原生的精细控制你最终还是得回到 Selenium 对象上去。我更愿意把它定位成从 Selenium 到现代工具之间的 Selenium用腻了？8款替代工具实测与选型指南，Playwright是首选
被 Selenium 的等待、驱动和诡异异常折腾到怀疑人生之后我花了两周时间把自己经手的几个自动化脚本项目的技术选型整体过了一遍。这篇关于 Selenium 替代工具的文章就是这次选型和迁移过程的完整记录。文章不为评价谁好谁坏更像一份实测笔记——8 款工具我都跑了实际项目有些已经迁移完成有些试完发现不适合整个过程踩了不少坑也总结出比较清楚的选型思路。如果你平时会用 Selenium 写 UI 自动化测试或采集脚本最近正觉得它越来越笨重那这篇文章主要是写给你看的。先说结论如果只让我推荐一款在大多数常规 Web 自动化场景里我的首选是 Playwright。但最合适这件事永远取决于你的项目类型、语言栈和现有基建。所以下面我会按为什么想换、换之前想什么、每款工具适合谁、迁移怎么落地的顺序来写尽量给出能直接照着做的东西而不是罗列一堆宣传语。1. Selenium 用久了最让人崩溃的几个场景在聊工具之前得先把 Selenium 真正让人难受的地方说清楚。我不是为了追新才换工具而是下面这几个场景实在出现太频繁频繁到已经严重影响脚本开发和维护效率。1.1 等待策略靠 time.sleep 续命的脚本Selenium 官方推荐用 WebDriverWait 配合 expected_conditions 做显式等待这听起来很标准但落到真实页面上完全不是那么回事。元素出现要等接口返回按钮可点要等某个遮罩层消失弹窗要等动画跑完这种动态中的动态很难用现成的条件函数描述清楚。于是大多数脚本最后都会演变成这种写法time.sleep(3) driver.find_element(By.ID, submit).click() time.sleep(2) # ...这类脚本在你自己的电脑上跑得顺顺的丢到 CI 或客户现场就开始随机失败。把 sleep 调大脚本跑一次要十几分钟调小又陷入偶发失败—手动重跑—再失败的循环。Selenium 对元素可操作这件事缺乏完整定义等于把等待策略的工程问题全部甩给了开发者这是低效感的最大来源。1.2 驱动版本地狱Chrome 一更新脚本就翻车用 Selenium 的人几乎都经历过浏览器驱动版本不匹配的报错。Chrome 自动更新到新版chromedriver 没跟上session not createdFirefox 升级geckodriver 又出问题。个人电脑上还好脚本一旦进了 CI驱动管理就变成正经工程问题你得在构建环境里安装与浏览器版本精确匹配的驱动还要在每次浏览器升级后跟着更新。很多团队为了省事直接把浏览器自动更新锁死但这又会带来安全补丁滞后的问题。这批替代工具里绝大多数已经把浏览器版本管理内置了一条命令完成浏览器下载和配套驱动安装单这一项就省掉巨大的维护成本。1.3 异常排查的黑暗时刻Selenium 跑挂之后你看到的通常是在某个定位器上找不到元素这类信息但页面当时究竟渲染到什么程度、哪个异步请求没返回、有没有弹层挡住了点击一概不知。排查流程就变成了重跑一遍、加截图、加日志、看 DOM运气好一次定位运气不好反复折腾好几个小时。更别提 StaleElementReferenceException、ElementClickInterceptedException 这些异常。字面意思都懂实际成因却千奇百怪有时候只是页面上多了一个悬浮 banner就足以让原本稳定的脚本全线飘红。工具本身不能提供足够丰富的现场上下文调试效率就永远上不去。1.4 页面结构一变定位代码全废用 Selenium 写脚本核心动作永远是 find_element 加 XPath 或 CSS。问题是现在前端组件化程度高、迭代频率快稍微重构一下 DOM 结构精心维护的定位器就会断掉一多半。如果工具不能提供更贴近用户视角的定位方式或者不具备快速生成和更新定位器的能力长期维护就是一场消耗战。这四点叠在一起让我逐渐意识到麻烦的根源不一定是我写的代码质量差而是 Selenium 把太多底层细节暴露给了使用方。带着这个判断我开始认真对比替代方案。2. 换工具之前先回答这四个问题很多人一进社区就问哪个工具能完全替代 Selenium这个问法本身就容易翻车。替代不是目的让脚本更省事才是目的。在动手安装任何新工具前我建议先把下面四个问题想清楚。2.1 用途功能测试还是数据采集这两个方向对工具的诉求差别非常大。功能测试看重用例组织、断言能力、失败重试、报告生成数据采集更看重页面渲染完整性、网络请求控制、会话保持、并发效率。Playwright 在两个方向上都比较全能Cypress 则几乎专为测试而生Puppeteer 更多出现在采集和浏览器自动化任务里。连用途都没想清楚选型一定会纠结。2.2 语言栈与团队维护成本Selenium 最宝贵的遗产之一是多语言支持Java、Python、C#、Ruby、JavaScript 都有官方绑定。但替代工具里有相当一部分以 JavaScript/TypeScript 为第一公民例如 Cypress、Puppeteer、Nightwatch.js 只在 Node 生态里运转。Python 团队想迁移最顺的是 Playwright 的 Python 版本其次是 Helium 这类基于 Selenium 的轻量封装。选型之前一定要确认这个仓库除了你之外还有谁会维护新同事的学习成本是否可控我见过不少团队因为某款工具看起来很酷就迁移过去结果大家都不会写最后代码质量比原来还差。2.3 是否已有 WebDriver 生态资产如果公司已经搭好了 Selenium Grid、云测平台或者有一套成熟的 WebDriver 基础设施完全不考虑兼容性会很可惜。WebdriverIO 走的正是保留 WebDriver 协议优化使用体验的路线迁移成本相对低。而 Playwright 基于 CDP 和自己的协议体系与传统的 WebDriver 设施无法直接打通需要单独规划执行环境。这个点很容易被忽略却往往决定迁移的实际工作量。2.4 运行环境与浏览器范围脚本要跑在无头服务器上吗要不要同时覆盖 Chrome、Firefox、Safari 的 WebKit 内核有没有 Docker 化部署的需求这些答案直接影响工具选型。例如你需要 WebKit 支持Playwright 的支持度就明显比 Puppeteer 好如果你只面对 Chromium 系Puppeteer 的体量和上手难度反而更低。先把真实运行环境记录下来再对照工具的兼容矩阵能少走很多弯路。3. Playwright我的主力推荐少写一半代码如果只选一款 Selenium 替代工具我会选 Playwright。它对开发体验的改善不是某一两个点而是系统性解决了我前面提到的等待、驱动、调试等问题。3.1 自动等待与可操作性检查去 time.sleep 化Playwright 对每个交互动作内置了一套可操作性检查。它会自动等待元素满足这些条件已附加到 DOM、可见、稳定、能接收事件、未被其他元素遮挡。也就是说你直接写 page.click框架会先把要素等齐再执行点击。常规的等待代码基本可以删掉。用 Selenium 写一个稳定点击往往要这样wait WebDriverWait(driver, 10) wait.until(EC.element_to_be_clickable((By.ID, submit))) driver.find_element(By.ID, submit).click()而 Playwright 里就是这样page.click(#submit)我用一个三十多步操作的真实流程做过对比用 Playwright 重写之后代码量减少了大概一半稳定性反而更高。不是说我从此完全不需要处理等待了而是 90% 的常规等待被框架消化掉了代码读起来像业务描述不再是一堆防御性逻辑。3.2 API 设计iframe、多标签页和下载不再是难题Selenium 切 iframe 要 switch_to.frame()切完还得记得切回去多标签页要维护 window_handles 集合下载文件得额外配浏览器偏好。Playwright 把这些交互做成了符合直觉的 APIiframe 用 frame_locator 直接定位多标签页通过独立的 page 对象天然隔离下载操作放进 expect_download() 上下文里就能捕获。iframe 是我以前最头疼的场景很多页面的核心交互都嵌在第三方 iframe 里switch 来 switch 去的逻辑很容易把人绕晕。换工具之后这类问题几乎不再出现代码可读性也上了一个台阶。3.3 浏览器上下文多账号场景的独立小房间Playwright 的 browser context 相当于完全隔离的浏览器会话每个 context 有独立的 Cookie、LocalStorage、缓存和 User-Agent。理解成一个账号一个独立的小房间就可以。以前用 Selenium 验证不同权限账号的页面表现只能退出再登录或者开多个浏览器实例处理 profile 冲突。现在创建多个 context每个 context 登录一个账号脚本可以并行操作互不干扰。做数据采集时的多账号轮换同样方便很多。3.4 网络拦截与 Mock把不稳定因素从脚本里隔离出去page.route() 可以拦截页面发出的请求自定义返回值、模拟延迟、直接中止某个资源加载。这个能力让脚本稳定性提高了一大截。以前页面里有个第三方统计接口超时整个用例跟着失败现在直接把这类与业务断言无关的请求 mock 掉让脚本只关心目标功能。调试接口异常场景也很顺手。想验证接口返回 500 时页面有没有正确展示错误提示不需要真的把后端搞挂route 一个 mock 响应就行。3.5 录制生成代码五分钟拿到可运行脚本playwright codegen命令会启动一个带记录功能的浏览器你在页面上正常操作工具就同步生成对应的 Python 或 JavaScript 代码。对快速熟悉一个陌生项目或者临时写一个一次性采集脚本来说这个功能效率极高先生成骨架再手工补上断言和边界处理就行。Playwright 当然也不是没有缺点。它跟传统 Selenium Grid 不兼容团队需要花时间重搭执行环境默认的自动等待在某些动画特别多的页面上会稍微多等一会儿。但对我来说整体收益远大于这些成本。4. Puppeteer轻量采集路线上的老朋友如果你是 Node.js 开发者主要任务是数据采集或页面截图、PDF 生成Puppeteer 可能比 Playwright 更轻、更直接。4.1 Chrome/Chromium 优先的定位适合谁Puppeteer 出自 Google Chrome 团队主打 Chromium 系浏览器的深度自动化。它不强调跨浏览器而是把 Chromium 的能力挖掘得很透。如果你的目标网站只在 Chromium 下验证过又希望库本身足够轻量Puppeteer 很合适。它的安装过程会自动下载配套的 Chromium 版本省掉了手动管理驱动的步骤。4.2 page.evaluate直接在页面上下文里取数据采集场景里最常用的是 page.evaluate()。它把一段 JavaScript 函数送到页面环境里执行然后返回结果。提取文章标题、正文、发布时间这类操作不用像 Selenium 那样反复 find_element 再取文本直接在页面里写 DOM 遍历就好const data await page.evaluate(() { return { title: document.querySelector(h1)?.innerText, content: document.querySelector(.article-body)?.innerText }; });配合 page.waitForSelector、page.waitForResponse 这些方法处理 SPA 动态加载内容比 Selenium 顺手很多。页面截图、生成 PDF、收集性能日志也都是 Puppeteer 的强项页面巡检、报告生成这类自动化任务几乎就是为它设计的。4.3 踩过的坑进程不退出和内存缓慢增长Puppeteer 最常见的坑有两个。第一个是忘记在任务结束调用 browser.close()导致 Node 进程一直不退出CI 任务卡死。第二个是长时间跑采集任务时内存缓慢爬升尤其是反复创建新页面却不关闭的场景。后来我养成了用完即关的习惯并且把长时间任务拆成批次定期重启进程释放内存。如果你担心项目以后可能要跑 Firefox 或 WebKit建议直接选 Playwright不要从 Puppeteer 起步。两者的 API 风格很接近先写 Puppeteer 再迁 Playwright 的成本不算高但绕一圈没必要。5. Cypress前端项目测试的另一种思路Cypress 和前几款工具不是一个路子。它不是从外部用脚本驱动浏览器而是在浏览器里运行测试。这个架构差异让它直接绕开了 Selenium 时代不少顽固问题。5.1 自动重试与用例隔离跑测试不容易碰运气Cypress 的每个用例默认从干净的浏览器状态开始前一个用例留下的 Cookie、缓存不会污染后一个用例。它的命令系统还内置自动重试机制cy.get() 找到一个元素后如果紧接着要点击Cypress 会反复检查元素状态直到它真的可操作。写过 Selenium 测试的人都懂一旦用例之间共享登录态跑的顺序一变结果就不可预测。Cypress 这种隔离模型让用例干净很多也更方便定位问题出在哪一步。5.2 时间旅行调试沿步骤回放页面状态Cypress 的 Test Runner 会保存用例执行过程中每一步的页面快照。调试时把鼠标悬停在某条命令上就能看到当时页面的真实状态。这个体验非常接近时间旅行比反复看截图和日志高效太多。我把测试从 Selenium 迁移到 Cypress 之后定位用例失败原因的速度明显变快。它的网络控制也做得不错cy.intercept() 可以对接口做 mock 或断言测试能直接跑在可控数据上不用依赖后端环境稳定。这特别对前端团队的胃口。5.3 为什么别拿它做采集Cypress 的边界也很明显它主要面向测试自己的应用对打开外部网站、跨域操作这类采集动作限制很严格。如果你是想找 Selenium 的替代品去抓别人的站点Cypress 基本不可行。可行的分工是前端项目自测用 Cypress浏览器自动化采集用 Playwright 或 Puppeteer各有各的阵地。6. 小而省的三款TestCafe、Taiko、Helium不是所有项目都需要迁移到 Playwright 这种全家桶级别的工具。如果你的核心痛点是Selenium 太啰嗦但现有基建还用得好好的下面三款提供了更轻的解法。6.1 TestCafe无驱动架构带来的省事体验TestCafe 来自 DevExpress最大的卖点是不需要 WebDriver也不需要额外装浏览器驱动。它通过在浏览器里注入脚本的方式执行测试配合内置的 Test Runner、自动等待和选择器开箱即用程度很高。多浏览器并发也省心一条配置就能同时跑 Chrome、Firefox 和 Edge。不过要坦诚提醒一句TestCafe 这几年的社区活跃度明显不如 Playwright 和 Cypress更新节奏放慢了。如果项目很在意长期维护方的活跃度选它之前要评估风险但如果你只是想把现有回归用例稳定跑起来它的完成度依然够用。6.2 Taiko让选择器变成看得见的东西Taiko 是 ThoughtWorks 出品的 Node 自动化库主打可访问性优先和接近自然语言的 API。它不需要你写一长串 CSS/XPath可以直接按按钮文字、输入框标签、元素相对位置来操作比如await goto(https://example.com); await write(hello, into(textBox({placeholder: 请输入}))); await click(登录);Taiko 内置了等待机制没有为元素出现而写一大堆显式等待的困扰。页面结构调整后只要用户能看到的文字没变很多脚本仍然能跑。这对受够了脆 XPath 的人来说是很大的解脱。6.3 Helium给 Selenium 套一个懒人壳Helium 在 Python 生态里比较特殊它名义上是 Selenium 的替代品实际是把 Selenium 包装成了更高级的 API。代码长这样start_chrome() click(登录) write(username, into用户名)Helium 底层自动处理元素定位、等待和浏览器启动日常脚本确实能写得简短很多。对已经在 Python 里沉淀了大量 Selenium 代码的团队Helium 可以在不推翻执行环境的情况下先把编写体验提上来。但它的封装也有天花板——一旦需要做底层原生的精细控制你最终还是得回到 Selenium 对象上去。我更愿意把它定位成从 Selenium 到现代工具之间的