最近在团队里做 Web 自动化框架升级几乎每场技术评审都会有人问一句Selenium 用了这么多年生态也成熟为什么要换这个问题回答多了我反倒觉得背后还有一层更值得聊的东西。答案不只是“Playwright 更新、API 更顺手”这么简单而是整个 Web 自动化的玩法正在变。过去我们追求的是“能跑、能回归”现在 AI 时代要的是“能感知、能决策、能稳定重放”。从这个角度看Selenium 的底层架构已经开始拖后腿而 Playwright 的设计起点就站在了不同的高度上。这篇文章不是劝你无脑推翻旧框架而是想结合我自己踩过的一堆坑把两个框架的核心差异、迁移过程、以及“AI 时代”这个标签到底意味着什么掰开揉碎讲清楚。适合正在用 Selenium 写测试但天天修脚本的人也适合打算给 AI Agent 接浏览器能力、但又不知道怎么选底座的工程师。1. 为什么大家一边骂 Selenium 一边还在用1.1 Selenium 当年的历史贡献与“垄断地位”现在很多人新人入行直接接触 Playwright可能会觉得 Selenium 又老又慢。但客观说Selenium 是 Web 自动化界的开山鼻祖它的历史贡献不应该被抹掉。早期的 Web 自动化是一片蛮荒每个浏览器都有自己的私有方案。后来 Selenium 借助 WebDriver 协议把“跨浏览器驱动”做成了 W3C 标准浏览器厂商愿意配合社区积累了大量文档和封装几乎所有测试团队都是从 Selenium 起步的。我当年接触自动化的第一周就是在某公司内部看一份几百页的 Selenium 用例文档那时候觉得这工具简直神器能模拟登录、下单、验证结果比手工点点点强太多了。这种历史积累带来的惯性是很强的。很多公司内部测试基架、CI 脚本、招聘 JD 里都写着“熟悉 Selenium”每年稳定维护着几千条用例。你说换就换不现实。哪怕用起来再别扭多数人也会选择忍受因为“能用”比“好用”妥协起来成本低。1.2 我在实际项目里撞上的那几堵墙说点具体的。我之前在某团队维护过一套电商订单流程的回归用例总量不大两百多条但跑完一轮要将近两个小时。问题不是用例多而是动不动就挂。最典型的是等待问题。Selenium 的经典写法是隐式等待加显式等待混着用隐性等待设置个 10 秒然后 WebDriverWait 里再来一个 expected_conditions。这套东西在静态页面还行但一到现在这种前后端分离、按钮是异步渲染、接口响应忽快忽慢的页面就非常痛苦。有一次一个“下一步”按钮点击后要等 3 到 5 秒才变成可点状态测试环境不稳定的时候还会拖到 8 秒。我为了让它稳定不得不在代码里塞了time.sleep(5)自己都知道这是罪恶写法但当时除了加等待想不出更省力的办法。第二个痛点是版本匹配。Selenium 本身只是个库真正干活的是 ChromeDriver / GeckoDriver浏览器一升级driver 版本对不上测试就没法跑。记得有一次 Chrome 大版本更新第二天早上 CI 全线红灯排查了半天才发现是驱动和浏览器版本不兼容。这种问题不涉及你的代码逻辑完全是环境维护成本但就莫名其妙吃掉你一上午。第三个痛点是多页签和 iframe。WebDriver 处理多窗口要切 window_handles切来切去经常拿到过期的句柄iframe 先切进去用完还得切回来一不留神作用域就乱了。我在处理一次第三方支付跳转的时候光是在两个窗口之间传参数就调了一整天最后还在某个人多的交流群里求助得到的建议是“别用 Selenium 了”。当时觉得是玩笑后来发现人家是认真的。这些坑不是不能填但填的代价非常大。你每修一个环境问题就少一块时间去看真正的业务逻辑测试。久而久之自动化团队变成了“专门修自动化”的团队这跟当初想做自动化的初衷完全背道而驰。2. Playwright 的核心优势为什么说它是 AI 时代的答案2.1 架构升级从 WebDriver 协议到 CDP要理解 Playwright 为什么强得先看底层。Selenium 走的是 WebDriver 协议本质上是 HTTP 请求从测试脚本发出命令经过中间层翻译再交给浏览器执行。而 Playwright 走的是 CDPChrome DevTools Protocol与浏览器内核直接通过 WebSocket 通信可以拿到页面的 DOM 细节、网络请求、控制台日志、性能数据等内部状态。用一个生活类比来说Selenium 像你打电话给一个远程操作员说“帮我点一下那个按钮”操作员再动手你和页面之间隔着一层翻译能听到的信息只有操作员告诉你的那点结果。而 Playwright 像你直接坐在浏览器旁边能看到页面每一个元素的细微变化能听到所有网络请求的来龙去脉甚至能在页面渲染之前就注入脚本。这个架构差异带来的能力是代际级别的。CDP 让 Playwright 天然支持网络拦截、路由 mock、请求改写、动态脚本注入这些能力对做复杂场景测试非常关键。更关键的是当你想把 AI 接进自动化流程时模型做决策需要的信息维度越多越好——网络这次请求为什么 404控制台里有没有报错这个按钮是不是被某个元素挡住了这些信息 WebDriver 协议根本拿不到而 CDP 本身就是浏览器的“原生活体数据源”。2.2 auto-wait把等待这件烦心事自动化Playwright 给人最直观的冲击就是不需要写等待。这不是魔法而是它的核心机制auto-wait。每个操作在执行前Playwright 会自动检查元素的可见性、稳定性、可操作性满足条件才执行不满足就继续等待直到超时。比如你要点击一个按钮它会等按钮出现在 DOM 里、稳定位置不再跳动、不再被遮罩层挡住然后才真正点下去。所以你在 Playwright 里基本不会写time.sleep()也不会天天为“等多久”这件事纠结。我迁移完第一周的感受就是以前每天三分之一的代码在写等待现在这些代码全部删光脚本反而更少报“元素找不到”。这里面有一个反直觉的点Playwright 脚本看起来更快其实并不是因为点击“反应更快”而是因为前置状态检查做得更细减少了失败后的重试和等待。快是稳出来的不是真正省掉了渲染时间。另外 Playwright 还内置了等待断言的封装比如等待某个 URL、等待某个元素包含指定文本直接用expect就可以。这种 API 设计对一个想减少心智负担的测试工程师来说体验是质的飞跃。2.3 多页签、多上下文、移动端模拟除了等待机制Playwright 在页面模型上也是碾压级的。Selenium 里切窗口让人抓狂但 Playwright 里每个 Page 对象是独立存在的天然支持多页签不需要切来切去。比如打开一个页面点一个链接弹出新 tab你直接拿到 popup 事件在新 Page 对象上操作就行干净利落。更强大的是 BrowserContext浏览器上下文每个 context 互相隔离相当于一个全新的浏览器实例配置。我在做多账号并发回归时直接开五个 context每个 context 一套登录态互不干扰并发稳定。这在 Selenium 里要么用多个 WebDriver 实例要么自己管理 cookie麻烦得很。移动端模拟也很顺手。直接设置 viewport、device_scale_factor、is_mobile就能模拟 iPhone 或者 Android 设备上的浏览器表现。我在做某些 App 里的 H5 页面验证时就用这个能力去模拟手机支付页面的布局和点击区域省了一台真机。这些能力单拎出来任何一个都足够成为换框架的理由。组合在一起就不是“替代 Selenium”的问题了而是“Web 自动化应该有的底座长什么样”的问题。3. 从 Selenium 迁移到 Playwright 的实操过程3.1 安装与初始化先说安装这点就会被 Selenium 用户羡慕。Selenium 需要额外下载浏览器驱动还得保证版本匹配而 Playwright 一条命令同时装库和浏览器内核pip install playwright playwright install chromium如果用 Node 环境也可以直接初始化npm init playwright装完之后内建了一个叫 codegen 的录制工具playwright codegen https://example.com它会打开一个浏览器窗口你手动在页面上操作它同步生成代码。这不是花架子我在迁移老用例时经常先用 codegen 把流程跑一遍再把生成的脚本改造成最终用例比从零看源码效率高很多。这里要说一个细节playwright install默认装的是 Chromium、Firefox 和 WebKit如果你只需要跑某一个内核可以只装对应的省磁盘空间。另外它装的浏览器是独立版本不占用你系统日常用的 Chrome也正因如此它不会碰到“Chrome 升级导致驱动失效”的老问题。3.2 写一个基础自动化脚本下面用一个登录后跳转 dashboard 的简单流程展示 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.get_by_label(用户名).fill(test_user) page.get_by_label(密码).fill(pass123) page.get_by_role(button, name登录).click() page.wait_for_url(**/dashboard) print(登录成功当前地址:, page.url) browser.close()注意几个点没有find_element_by_id这种老式写法用的是语义化定位器get_by_label和get_by_role没有显式WebDriverWaitclick 之后页面跳转直接wait_for_url兜底。整体读起来像伪代码容易维护。如果你需要并发跑多个场景可以用 async API 或者直接多开 context。实际生产中我最常用的是browser.new_context()来做会话隔离每个 context 自带独立的 cookie、localStorage互不串数据。3.3 迁移时最容易踩的三个坑从 Selenium 迁过来不是改几行 API 就行思维模式要转变。我最开始迁移的时候踩了三个坑这里写出来希望你能绕开。第一个坑还在用显式等待的老思路。很多 Selenium 老手迁移后第一反应是“这里没有 wait会不会不稳”然后会习惯性把time.sleep()也写进 Playwright 代码里。这种做法大错特错不仅慢还会掩盖真实的状态。Playwright 的理念是“信任 auto-wait”真正需要等待的是业务条件而不是元素本身比如等一个页面 URL 变成目标地址。判断条件用expectfrom playwright.sync_api import expect expect(page.locator(.result)).to_have_text(操作成功)第二个坑还在用 XPath 一把梭。Selenium 里大家习惯了//*[idxxx]/div[1]/a这种“硬核”定位但 Playwright 更建议从用户角度去找元素。get_by_role、get_by_label、get_by_placeholder这类语义化定位器不仅抗前端结构调整而且可读性更好。前端改个 class 名你的脚本往往不用动。 XPath 不是不能用而是应该用在信息结构复杂、确实没有语义关系的场景而不是什么情况都抄起 XPath。第三个坑隐式等待和显式等待混用的后遗症。老代码里经常看到“先设置 implicit wait又加 WebDriverWait”的操作这本意是双保险实际会让定位时间变得不可预期。迁移到 Playwright 后这些全局配置全都不要了等待逻辑全部由框架自动处理。你只需要负责“业务条件”的断言其他交给工具。4. AI 时代当自动化工具遇上 Agent 智能体4.1 为什么 AI Agent 更需要 Playwright 的感知能力现在各大团队都在尝试把大模型接入浏览器操作让 AI Agent 自己看页面、点按钮、填表单。这种场景下工具能提供什么维度的数据直接决定模型能不能做对决策。Selenium 的 WebDriver 协议只解决了“操作”这一层它告诉你命令执行成功没成功但不告诉你页面内部发生了什么。AI Agent 要判断“这个按钮到底能不能点”“为什么登录失败了”只靠截图根本不够它需要的是结构化的事件流点击事件是否被目标元素监听到页面的网络请求有没有 502控制台有没有异常堆栈这些信息WebDriver 协议给不了而 CDP 全部都能拿到。我在一个内部实验项目里让模型去完成“打开搜索页、输入关键词、筛选前三条结果并整理摘要”的流程。起步时我用过基于 Selenium 的封装模型经常在“筛选按钮找不到”这种地方卡住因为底层只给它一个异常字符串它不知道页面上到底有什么。后来换到 Playwright我把 console 事件、请求失败事件、当前页面 DOM 的关键节点信息都喂给它模型的决策准确率明显提升。不是说 Playwright 本身是 AI而是它为 AI 提供了足够丰富的“感知层”。4.2 稳定性是智能化的前提如果你接触过 AI Agent 类的项目应该知道一个很头疼的问题模型每一步都在做决策但如果基础操作不稳定它就得花大量时间去猜“是不是自己看错了”。AI 最怕的不是信息多而是信息乱且不可靠。Playwright 的 auto-wait 和语义化定位恰好把“操作层”的稳定性做得很牢。模型在大概率的稳定环境中只需要专注于规划——比如“先去结算页再填地址”而不是每个点击都要担心会不会超时、会不会点偏。这就相当于驾驶员不用操心车是不是随时会熄火才能真正去看路况。另外 Playwright 的 trace viewer 会把一次运行的每一步操作、DOM 快照、网络请求、控制台日志完整录下来。这套数据有两个用途一是遇到问题时回放还原现场而不是只对着打印日志猜二是可以拿真实操作轨迹做模型的示例让 AI 学习如何一步步完成任务。我后来做意图决策时直接拿 trace 文件做 few-shot 示例效果比纯文字描述好很多。4.3 事件监听与“意图重放”的工程价值Playwright 的事件监听能力也值得单独说一下。一行代码就能监听页面上的所有 console 日志page.on(console, lambda msg: print(msg.text))同样可以监听request、response、dialog、popup等事件。这不仅仅是调试工具更是构建 AI Agent 上下文的基础设施。你可以把用户的真实操作路径记录下来生成一组“自然语言描述 操作序列 页面状态”的数据集然后用这个数据集去微调提示词或做少样本示例。这个概念往深了说能改变自动化测试的写作方式不再是人肉维护断言而是从真实用户会话中自动抽取行为模式再交给模型去生成新的验证点。当然这一块目前还没有完全成熟的标准做法很多团队都处于摸索阶段。但有一点很确定如果你底层连事件都拿不全后续这些智能化的玩法根本无法开展。5. 选型建议什么情况下换什么情况下别动5.1 多维度对比一览表为了帮你决策我把两个框架的核心差异整理成了一张表对比维度SeleniumPlaywright底层架构WebDriver 协议HTTP 命令CDP浏览器内核直连等待机制隐式等待 显式等待混合auto-wait 自动等待多页签处理window_handles 切换多 Page 对象天然支持浏览器驱动需额外下载且版本匹配内置管理一条命令安装录制工具需要第三方扩展codegen 内建支持网络拦截/修改请求要额外引入代理库page.route()原生支持移动端模拟能力有限内置 device 模拟事件级数据获取拿不到内部细节原生支持数据丰富社区生态老牌成熟资料极多社区快速增长官方文档完善从我自己的经验看新项目、准备重构的测试基架、需要给 AI 提供页面数据的项目闭眼选 Playwright。老牌项目如果实在没有重构预算继续用 Selenium 也不会立刻出事但你要清楚这是在积累技术债。5.2 我不建议立刻迁移的几类情况聊了这么多优势但也得泼几盆冷水。不是所有项目都适合立刻迁移。第一类是已经有几千条 Selenium 用例跑得相对稳定、短期又没有大的功能迭代的项目。这种项目的核心矛盾不在框架而在“并发稳定”和“资源配额”你花三个月去迁移中途回归问题都算在你头上吃力不讨好。第二类是强依赖旧版浏览器的内网环境比如业务只能跑在某个老内核的企业浏览器上而 Playwright 强制管理浏览器版本这种封闭环境不一定兼容强行上会引入新风险。第三类是团队完全没有意愿学新东西你一个人换完框架后没人维护这种组织问题不是技术能解决的。我的建议是别搞“一刀切”可以从一条最痛苦的业务链路试点跑一个月看看稳定性数据和维护工时再决定要不要铺开。技术选型最有说服力的证据永远是你自己的真实数据不是我文章里的论断。6. 常见问题与排查技巧实录6.1 常见问题速查表实际操作中我几乎每天都碰到同事来找我看脚本为什么挂了这里把问得最多的几类问题整理成一张速查表问题现象常见原因处理方式元素明明在页面上但 click 报 intercepted元素被其他元素遮挡长在阴影 DOM 里先用expect(locator).to_be_visible()确认状态再考虑scroll_into_view_if_needed()浏览器打开后一闪就退出headless 模式没设置或启动参数有问题launch(headlessTrue)明确设置并加上--disable-gpu等参数打日志点击后页面无反应但 no error事件绑定在 document 上真正点击的元素其实被替换了给 click 加 delay或者用dispatch_event(click)检查问题并发跑用例偶发资源冲突多个 context 复用了同一个浏览器实例的某个状态给每组用例单独new_context()并限制浏览器实例并发的最大数量原来 Selenium 脚本 10 秒完成迁移后要 60 秒老脚本靠隐式等待提前返回新框架在等“真正稳定”检查 page 上是否有无限轮播、动画加载把这类资源请求 mock 掉定位器找不到动态加载项元素在 iframe 或 shadow DOM 里语义定位器穿透不了使用page.frame_locator()先定位到 iframe再找元素6.2 几条避坑心得最后分享几条我在项目里踩出来的经验这些属于文档里不会写的部分。第一个心得是一套用例尽量用同一个 Page 生命周期不要在一个 page 上无限 goto更不要在一个 page 里同时跑多套业务数据。页面跳转和状态残留都会互相干扰哪怕能跑通后续维护也容易出问题。我现在的习惯是把“创建业务态”和“执行核心断言”分开前者用 API 直接准备数据后者才真正走 UI 操作。第二个心得是不要过度依赖录制生成的脚本。codegen 能给你一个起点但录出来的脚本往往带了一堆无关步骤、等待页面某块动画平稳的隐性逻辑。手动把脚本精简到只剩关键业务动作和断言才是后期好维护的关键。我会在生成后统一改命名、加注释、去掉多余的操作步骤让它变成可读性良好的测试代码而不是一段“能跑就行”的咒语。第三个心得是 trace viewer 是个宝藏平时用例挂了除了看 log更要把 trace 翻出来看每一步 DOM 快照和网络请求时间线。很多时候你能在几十毫秒的差距里发现前端资源加载慢、某个接口异常、渲染线程卡死这类深层原因。我在排查某个支付流程偶发失败时就是从 trace 里发现有一个静态资源总是从边缘节点回源导致点击后页面白屏两秒前端团队以此为证据优化了缓存策略用例顺带稳定了。还有一个很小的技巧记得锁住 Playwright 的版本别让它在 CI 里随便升级。它虽然不像 Selenium 那样天天被浏览器版本折腾但新版本内部行为偶尔会有变化锁版本是风险最低的做法。我个人实际用下来的最大感受不是 Playwright 的 API 多漂亮而是它把我从“整天伺候工具”的状态里解放了出来。以前每天上班先去看 CI 挂了几条再埋头分析哪些又是等待不够、哪些又是版本问题现在用例出错时绝大多数都是业务真实逻辑的问题而不是自动化的随机冗余问题。如果你想在 Web 自动化的基础上做 AI 相关的尝试它的数据能力会非常值得投入研究。最后建议先迁一条最痛苦的链路试试让数据和体感说服你团队里的其他伙伴。