Selenium 和 Playwright 的区别：所谓现代、好写、稳定，到底具体在哪？

很多人说 Playwright 比 Selenium 更现代、更好写、更稳定。
这句话本身没错，但如果只停在口号上，基本等于没说。

真正的区别不在于“谁更新”，而在于：Playwright 把很多前端自动化里最烦的细节，做成了默认能力。

先说结论

如果是新项目，尤其是 React、Vue、Next.js 这类现代前端页面，我会优先选 Playwright。

如果公司已经有大量 Selenium 用例、Java 测试体系、Selenium Grid 平台，那 Selenium 继续用也很正常。

两者不是“新工具吊打旧工具”的关系，更像是：

工具	更像什么	优势
Selenium	老牌通用浏览器自动化标准	生态成熟、语言支持广、企业存量大
Playwright	面向现代 Web 的 E2E 测试框架	自动等待、调试舒服、对异步页面更友好

什么叫更现代？

现在的网页，已经不是过去那种“点一下，整个页面刷新”的模式。

一个登录按钮可能要经历这些状态：

页面先显示骨架屏
接口返回后渲染表单
按钮先 disabled
校验通过后才可点击
点击后出现 loading
跳转或者局部刷新页面

Selenium 能测，但你经常要自己写等待。

Playwright 的思路是：用户能不能点，不应该只看 DOM 里有没有这个按钮，而要看它现在是不是真的能被用户操作。

比如执行：

await page.getByRole('button', { name: '登录' }).click();

Playwright 在点击前会检查：

元素是否只有一个
是否可见
是否稳定，没有还在动画中
是否能接收点击事件，没有被遮罩挡住
是否可用，没有 disabled

这就是“现代”的具体表现。它默认承认现代页面是异步的、动态的、可能有动画和遮罩的。

什么叫更好写？

Selenium 写自动化时，经常会看到这种代码：

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
WebElement button = wait.until(
    ExpectedConditions.elementToBeClickable(By.id("login"))
);
button.click();

Playwright 通常是：

await page.getByRole('button', { name: '登录' }).click();

好写不只是少几行代码，而是少了很多“测试胶水代码”。

常见问题	Selenium 常见处理	Playwright 常见处理
等元素出现	手写 wait	操作和断言自动等待
判断按钮能不能点	手写条件	点击前自动检查
断言页面变化	手写等待后再断言	expect 自动重试
找元素	常用 id、css、xpath	推荐 role、label、text
调试失败	看日志、截图、堆栈	Trace、截图、视频、网络请求一起看

比如断言登录成功：

await expect(page.getByText('登录成功')).toBeVisible();

这不是立刻判断一次。Playwright 会在超时时间内反复检查，直到文本出现，或者最终失败。

这种写法更接近人的理解：
我点了登录，然后页面应该出现“登录成功”。

什么叫更稳定？

自动化测试最烦的不是一直失败，而是偶发失败：

本地能过，CI 偶尔失败；重跑一下，又好了。

这种问题通常不是业务真的坏了，而是测试代码太脆。

常见原因有：

元素还没加载出来
元素出现了，但还不能点
动画还没结束
loading 遮罩挡住了按钮
DOM 被前端框架重新渲染
断言执行得太早

Playwright 的稳定性，主要来自三件事。

第一，操作前自动检查元素状态。

它不是看到按钮就点，而是等按钮真的可操作。

第二，断言自动重试。

很多前端状态变化需要一点时间。Playwright 不会急着判死刑。

第三，Locator 每次操作时重新解析元素。

Selenium 中比较常见的 StaleElementReferenceException，本质上是之前拿到的 DOM 元素已经失效了。
Playwright 的 locator 更像一个“定位规则”，不是一个旧元素引用，所以更能适应前端重新渲染。

Selenium 不是不能用

Selenium 的价值在于标准和生态。

它的 WebDriver 是 W3C 推荐标准，浏览器厂商也围绕 WebDriver 做了自己的实现。
企业里很多测试平台、云测平台、历史用例，都是围绕 Selenium 建起来的。

所以 Selenium 更适合这些场景：

公司已经有成熟 Selenium 体系
Java 自动化测试团队为主
需要接入已有 Selenium Grid
历史用例很多，迁移成本高
团队更看重标准化和长期兼容

Playwright 更适合这些场景：

新项目从零开始做 E2E 测试
页面是现代前端框架开发
CI 上经常遇到偶发失败
希望失败后能快速看 Trace 定位问题
需要方便地做网络拦截、鉴权状态复用、多浏览器测试

一个更实在的选择建议

如果你是个人项目，或者新团队起步：

优先 Playwright。

它的默认体验更省心，特别适合现代 Web。

如果你在公司里维护老测试平台：

不要为了换工具而换工具。

先看 Selenium 用例是不是已经经常不稳定。
如果不稳定的原因主要是等待、异步渲染、DOM 变化，那可以考虑新用例用 Playwright，老用例慢慢迁。

最后一句话

Playwright 的“现代、好写、稳定”，不是玄学。

它具体体现在：

操作前自动等待
断言自动重试
Locator 更适合动态 DOM
调试链路更完整
测试隔离更自然

Selenium 像一套成熟的浏览器自动化基础设施。
Playwright 像一套已经替现代前端测试踩过坑的工具箱。

选哪个，别只看名气。
看你的页面是不是动态复杂，看团队是不是愿意维护等待逻辑，看失败时能不能快速定位问题。