1. Playwright 是什么：定位与能力全景

本节目标：搞清 Playwright 到底是干什么的、它替你解决了哪些老大难问题，以及什么场景下该选它、什么场景下不该选。

先说痛点：自动化测试为什么总是很脆

写过 UI 自动化的人都懂那种感觉。

用例昨天绿油油全过，今天一跑红了一片。点进去看错误，元素没找到。手动打开页面，元素明明在那儿。

原因八成是时机。页面还在渲染，脚本已经去点了。于是你加一行 sleep(2000)。今天好了，下周网络慢一点又挂。

再加到 5 秒？用例跑得比蜗牛还慢。

老一代自动化工具把「等待」这件事丢给了你，你就得一辈子跟它斗。Playwright 的第一个卖点，就是把这个坑填掉。

一句话定义

Playwright 是微软开源的端到端（End-to-End，简称 E2E）测试框架。

它用一套 API 同时驱动三大浏览器内核：Chromium、Firefox、WebKit。可以在 Windows、Linux、macOS 上跑，本地跑、CI（持续集成）里跑都行，有头（headed，看得见浏览器窗口）无头（headless，后台静默运行）都支持。

注意「框架」这个词。Playwright 不只给你一个操控浏览器的库，它还打包了：

测试运行器（Test Runner）：负责发现用例、执行、汇总结果
断言库（Assertions）：判断页面状态是否符合预期
测试隔离（Isolation）：每个用例一个干净环境
并行执行（Parallelization）：多进程同时跑，省时间
一整套调试工具：录制器、UI 模式、追踪查看器

一次安装，上面这些全都有。这跟「装个库再自己拼装十个轮子」是完全不同的体验。

它到底解决了什么

自动等待（Auto-waiting）

这是 Playwright 最重要的设计。

你写 await page.getByRole('button', { name: '提交' }).click()，它在真正点下去之前，会自己确认这些事：

Locator（定位器）刚好命中一个元素
元素可见
元素稳定（不在做动画）
元素能接收到点击事件（没被遮罩层挡住）
元素处于可用状态（没被 disabled）

全部满足才动手。不满足就重试，直到超时才报错。

所以你的测试代码里，基本不需要出现 sleep。这一条就砍掉了绝大部分「偶发失败」。

Web 优先断言（Web-First Assertions）

普通断言是一锤子买卖：取值、比较、不对就挂。

Playwright 的断言会自动重试，直到条件成立或超时：

// 会一直等，直到页面标题包含 Playwright
await expect(page).toHaveTitle(/Playwright/);

页面异步加载完成得晚一点也没关系，断言会等它。

测试隔离（Isolation）

每个用例都跑在独立的 Browser Context（浏览器上下文）里，相当于一个全新的浏览器配置文件。Cookie、localStorage 互不干扰。

一个用例登录了，不会影响下一个用例的登录状态。前一个用例挂了，也不会污染后面的。

真正的跨浏览器

Chromium、Firefox、WebKit 三套内核由 Playwright 自己打包分发。你 npx playwright install 一下就有了，不用手动配驱动、对版本。

WebKit 这一条尤其值钱。它是 Safari 的内核，以前想在非 Mac 环境测 Safari 行为基本没戏。

能力全景

按用得多到用得少排一下：

能力	典型用法
定位与交互	`getByRole` / `getByText` 等定位器，点击、输入、勾选、拖拽
断言	`expect(locator).toBeVisible()` 等自动重试断言
测试组织	`test.describe` 分组、钩子、Fixture（夹具）、参数化
网络控制	拦截请求、Mock（模拟）响应、监听响应体
API 测试	不开页面，直接发 HTTP 请求做接口测试
环境模拟	视口尺寸、移动设备、地理位置、权限、时区、时钟
视觉与产物	截图、录像、视觉对比、Trace（追踪）文件
调试工具	codegen 录制、UI Mode、Trace Viewer、VS Code 插件
多语言绑定	JavaScript/TypeScript、Python、.NET、Java

本教程主线用 TypeScript 写示例，跟官方文档保持一致。其他语言的差异放在后面单独讲。

和别的工具怎么选

这部分我尽量说实话，不吹不黑。

对比 Selenium

Selenium 是老前辈，生态最广，语言绑定最全，几乎所有浏览器和云测试平台都认它。

它的短板在体验：等待要自己写（显式等待、隐式等待那一套），驱动版本要自己对，调试主要靠日志和截图，跑得也慢。

怎么选：团队已经有大量 Selenium 资产、或者必须支持一些冷门浏览器/古董环境，继续用 Selenium。新项目从零起步，Playwright 的开发效率高一大截。

对比 Puppeteer

Puppeteer 是 Chrome 团队的库，API 风格跟 Playwright 很像（Playwright 的核心作者本来就来自 Puppeteer 团队）。

区别是定位不同：Puppeteer 是浏览器自动化库，主打 Chromium，不带测试运行器；Playwright 是测试框架，跨三内核，测试所需的东西都自带。

怎么选：只做爬虫、生成 PDF、页面截图这类自动化脚本，Puppeteer 够轻。要写测试，Playwright 明显更合适。

对比 Cypress

Cypress 的调试体验非常好，交互式界面做得早、做得漂亮，前端同学上手快。

它的架构决定了一些限制：测试代码跑在浏览器里，处理多标签页、多域名、跨源 iframe 时会别扭；多浏览器支持也不如 Playwright 全。

怎么选：只测单页应用、团队吃 Cypress 生态，它没问题。要跨浏览器、要处理复杂多页面场景、要 WebKit，Playwright 更省心。

Tip

选工具别只看功能表。真正决定成败的是：团队愿不愿意维护。Playwright 的优势恰恰在这里 —— 用例更不容易坏，坏了也更容易查。

什么时候别用 Playwright

也说几句反话，免得你走弯路。

单元测试不要用它。测一个纯函数、一个工具方法，用 Vitest / Jest 更快更轻。Playwright 起浏览器是有成本的。
纯接口回归不一定用它。虽然它能发 HTTP 请求，但如果你的场景完全不涉及页面，专门的接口测试工具更顺手。
必须测真实 Safari / 真实 Chrome 特定版本时要留心。Playwright 默认用的是自己打包的 Chromium 和 WebKit，不是品牌浏览器本体。要测品牌浏览器可以切 channel，这个后面章节会讲。

版本基线

本教程统一以 Playwright 1.62.x 为基线（撰写时最新稳定版为 1.62.1）。

Playwright 是月度发布节奏，版本号形如 1.62.1。它内置的 Chromium、Firefox、WebKit 引擎版本随 Playwright 版本升级，每次升级 Playwright 后重新跑一次浏览器安装命令即可。

Note

后面所有命令和代码都按 1.62.x 写。如果你手上的版本更新，遇到差异请回查官方 Release Notes（发布说明）。

小结

Playwright 的核心价值不是「功能多」，是「用例不容易坏」。

自动等待干掉了时机问题，Web 优先断言干掉了竞态检查，测试隔离干掉了用例之间的相互污染。剩下的跨浏览器、并行、调试工具，都是锦上添花。

下一章我们把环境装起来，跑通第一条命令。