1. 为什么我抛弃了旧的自动化方案转投 Playwright 阵营先交代一下背景。我之前的项目里大量使用老牌的自动化测试框架做端到端测试维护成本是真的高。每次跑测试最头疼的不是业务逻辑变复杂而是脚本和浏览器之间的“同步问题”明明页面元素已经渲染出来了脚本还在傻等偶尔网络慢一点用例就大面积误报。团队里每个人都曾被这种“不稳定”折磨过最后大家甚至对自动化测试产生了某种抵触情绪。后来我开始调研新一代的自动化测试工具注意到 Playwright 出现的频率越来越高。GitHub 上星标涨得飞快核心团队是从老牌框架项目出来的属于“原生血统”的正规军。最初我抱着试试看的心态在几个小项目里跑了一下结果发现几个痛点被精准解决了内置了自动等待机制再也不用到处写sleep(3000)或者是轮询轮询再轮询。一套 API 同时覆盖 Chromium、Firefox、WebKit 三种浏览器内核跨浏览器验证不再是奢望。默认采用浏览器上下文隔离每个测试用例天然独立互相不污染。自带Trace Viewer追踪查看器用例挂了能看到完整录屏、DOM 快照和网络请求定位问题像看回放一样。这几个特性几乎是在对着我之前踩过的坑逐一开火。所以这期内容我不打算只写一堆 API 文档翻译而是想按照我自己的学习路径和实战经验把 Playwright 从入门到落地整个流程串一遍。内容覆盖环境搭建、核心概念、常用 API、断言设计、调试技巧、测试报告以及持续集成接入尽量做到“看完就能在自己项目里用起来”。如果你正在做 Web 自动化测试或者刚接触 Playwright 想快速进入实战状态这篇文章应该能帮你省掉不少摸索时间。如果你对老框架已经很熟想找个更稳的替代方案这篇内容也可以给你一个相对客观的参考。2. 环境准备与第一个测试用例五分钟先跑起来2.1 安装与内置浏览器管理Playwright 的安装过程比我预想中还要顺。项目里只需要基于 Node.js版本建议 16 以上执行一条命令就能把核心库装好npm init -y npm install -D playwright/test很多人会问装完包是不是还得单独下载 Chrome 或者 Firefox实际上 Playwright 会自己维护一套专用浏览器版本你需要再执行一行命令把浏览器内核拉下来npx playwright install这里它默认会同时下载 Chromium、Firefox 和 WebKit 三件套。如果你只做业务上的回归测试只下 Chromium 也能跑但下载全量版本有个好处跨浏览器兼容性验证可以随时做不耽误事。注意npx playwright install下载的浏览器路径和系统里你自己装的 Chrome 不是同一个东西它们的版本是配套的互不干扰。2.2 第一个冒烟测试脚本装完依赖之后我习惯先在项目根目录建一个tests文件夹然后丢一个最简单的冒烟脚本进去const { test, expect } require(playwright/test); test(第一个冒烟用例, async ({ page }) { await page.goto(https://example.com); await expect(page).toHaveTitle(Example Domain); });这里面的page对象是由框架自动注入的每个测试都会拿到一个全新的页面实例你不需要关心它的创建和销毁过程。然后执行npx playwright test框架会自动找到tests目录下的所有.spec.js或者.test.js文件逐个跑完并输出一个美观的测试报告。刚开始跑这个用例就能感受到 exec 速度还不错。默认情况下Playwright 是并行执行测试文件的如果测试文件多了它还会自动分配 worker 进程尽量吃满 CPU 资源。2.3 为什么 Playwright 能让脚本“更稳”这里想多说一句因为很多人用老框架写自动化最后脚本全部变成了“睡眠大作战”sleep(1秒)、sleep(2秒)、循环重试……这样写出来的脚本不但慢而且特别脆。Playwright 之所以“稳”核心在于它内置了一套可操作性的检查机制Actionability Checks。在点击、填写、选择这类操作之前它自动会做几件事元素是否已经附着在 DOM 上。元素是否可见不是隐藏状态。元素是否稳定比如动画还没停它会等着。元素是否接收事件比如有没有被遮罩层挡住。元素是否可用不是 disabled 状态。这五条检查全部通过以后操作才会真正执行。如果过了一段时间仍然不满足才会报超时错误。这等于把以前大家手动写的“等待逻辑”内化到了框架层脚本稳定性和开发效率一下子提升了一个档次。3. 核心概念与定位器机制不懂这些东西后面很容易踩坑3.1 页面对象与浏览器上下文在正式写复杂用例之前有必要把 Playwright 的几个核心概念理清楚。Browser浏览器实例对应一个完整的浏览器进程。BrowserContext浏览器上下文可以简单理解成一个独立的“隐身窗口”会话。不同 context 之间的 Cookie、缓存、本地存储都是隔离的。Page页面对象表示一个标签页。大多数情况下你的操作都是围绕 page 展开的。这里最关键的设计是 BrowserContext。测试用例最怕什么最怕相互影响。A 用例登录了B 用例还是游客状态A 用例往 localStorage 写了配置B 用例读到了脏数据。在 Playwright 里每个测试默认都跑在独立的 context 里从源头上隔离了干扰。这也是我当初决定深入使用它的一个重要理由。框架还给每个测试提供了固定的pagefixture你甚至不用自己手动创建 context直接拿去用即可。3.2 定位器从 CSS 选择器到逻辑定位早期自动化测试里大家习惯用page.click(#btn-submit)这类的写法选择器写在操作里。这种写法最大的问题是改起来麻烦代码里选择器到处散落后期维护基本靠全局搜索。Playwright 推荐的方式是定位器Locator。定位器不是立即去页面上找元素而是先描述“我要找什么”等到真正要执行操作或者断言时再由框架去动态匹配。这个概念和函数式编程里的“惰性求值”有点像。举个例子原来我们可能会这样处理复选框await page.check(input[typecheckbox]);但更好的方式是把定位器抽象出来const agreeCheckbox page.locator(input[typecheckbox]); await agreeCheckbox.check();这样不仅代码可读性更高也方便复用。Playwright 同时也提供了一组语义更强的定位器方法比如getByRole()、getByText()、getByLabel()。在可访问性做得比较好的页面上我更喜欢用角色定位器例如await page.getByRole(button, { name: 提交订单 }).click();这个方法接近用户真实的使用视角——用户看到一个按钮看到按钮上的文字然后点击。脚本也按这个思路去找目标元素别想着非得写一大长串 div 嵌套层级。3.3 定位器优先级原则很多新手上来就喜欢写一气呵成的 CSS 选择器什么#root div.container div.row button.btn-primary这种选择器的问题在于一旦页面结构改版比如多加一层 div用例就全挂了。我自己总结了一个优先级的参考顺序可以给大家一个方向优先级定位方式适用场景1用户可见文本链接、按钮、标题2无障碍角色对语义标签支持良好的项目3Label 标签表单相关的输入控件4表单占位符输入框有 placeholder 提示5测试专用 ID>await expect(page.getByText(保存成功)).toBeVisible();这个断言会在超时前不断轮询直到元素可见或者超时。比原来“睡眠固定时间”可靠得多。这个设计核心就是给条件断言一个时间窗口让它在窗口内反复检查而不是盲等。4.2 什么时候需要手动等待虽然框架很聪明但有些场景还是需要一点手动控制的。比如你要等某个接口返回之后才能确定后续数据是否完整或者某个元素被隐藏后页面布局变化把另一个元素推到了新的位置。这类“时序敏感”的场景建议有两种姿势第一种是等待特定接口响应const responsePromise page.waitForResponse(**/api/order/list); await page.click(button:has-text(刷新)); const response await responsePromise; console.log(await response.json());这样写的好处是把“等待”和“业务”绑定在一起而不是干等时间。第二种是显式等待某个元素状态比如await page.waitForSelector(.loading-hidden, { state: hidden });但总体上我的原则是能靠 expect 自动重试解决的就别动 wait 相关 API能靠 waitForResponse 解决的就别写固定 sleep。固定时间等待永远是最后选项因为它在机器负载高或网络波动时一定会反过来坑你。4.3 超时配置的合理设定超时时间大家也可以按项目调一下。默认的 expect 超时是 5 秒如果你在很慢的页面或者复杂渲染场景下可以按需改到 15 秒甚至更长。我喜欢在配置文件playwright.config.js里统一管理module.exports { timeout: 30000, expect: { timeout: 10000 } };但注意不要让超时时间给脚本“兜底”。如果一个断言每次都是等到超时才通过说明前面操作可能不太稳这种隐藏风险越早暴露越好别只用超时时间掩盖。5. 断言与调试技巧少走弯路快速定位问题5.1 常用断言 API 一览Playwright 的断言写法延续了 Jest 的风格但背后加了一层自动重试的逻辑。常见的断言大概有这些await expect(locator).toBeVisible(); await expect(locator).toBeHidden(); await expect(locator).toHaveText(订单已提交); await expect(locator).toContainText(成功); await expect(locator).toHaveCount(3); await expect(page).toHaveURL(**/order/detail?id123); await expect(page).toHaveTitle(标题);这里有一个比较容易忽略的细节toHaveText是全量匹配toContainText是包含匹配。比如一个元素的文本是“xxx 你好 xxx”toHaveText(你好)会失败而toContainText(你好)会通过。很多刚上手的朋友在这里吃过亏特意提醒一下。5.2 页面快照、Trace 与录屏调试用例失败的时候第一反应当然是想知道当时页面上发生了什么。控制台会把失败信息打印出来但这远远不够。我喜欢用追踪查看器来分析它几乎相当于把测试过程“录”了下来包含页面截图、网络请求、DOM 快照和浏览器控制台日志。要让追踪功能生效只需要在命令行加一个参数npx playwright test --trace on跑完用例后会在test-results目录下生成.zip文件再执行npx playwright show-trace就能在浏览器里打开一个交互式的追踪报告。你可以逐步回放每一个操作看到点击之前的元素状态、点击之后触发的网络请求、以及浏览器报错。定位一个偶发问题比靠日志盲猜快太多了。另外如果你遇到“某些用例本地过一到 CI 就挂”的经典问题我强烈建议在 CI 失败的时候强制保留 trace。配置方式use: { trace: retain-on-failure, }这样只有失败的用例会留下完整现场既不浪费普通用例的存储关键时候又有据可查。5.3 利用 Inspector 和 Playwright 的代码生成器还有一个新手友好度极高的功能代码生成器Codegen。它可以把你在页面上的手动操作自动转成脚本。启动方式npx playwright codegen运行后浏览器会打开一个窗口你在里面点按钮、填表单、跳页面代码面板会同步生成对应脚本。刚开始玩 Playwright 的时候我会先把业务主流程用 codegen 过一遍然后再手动整理选择器和步骤效率提升非常明显。不过 codegen 生成的脚本只是一个起点它会生成很多绝对化的路径选择器我的习惯是生成之后再人工改成语义化的 getByRole / getByText并在合适的位置加上断言。6. 测试报告与 CI/CD 集成让自动化测试真正发挥价值6.1 HTML 报告与 Allure 对比测试报告是一个大家容易忽略、但实际使用体验影响非常大的部分。默认跑完npx playwright test之后控制台输出的是一个简洁的用例列表但如果想要更直观的统计信息、失败截图、console 日志建议打开 HTML Reportnpx playwright show-reportPlaywright 自带的 reporter 界面比较现代按功能模块suite、test、hooks 等分组展示点开失败用例能看到错误栈、附件截图、trace 等。大部分团队用它已经够了。如果你的团队对报告有更高的展示要求比如想按需求模块分类或者要生成更精美的 PDF 报告也可以引入 Allure。Playwright 有官方的 allure-playwright 插件安装后配置 reporter 为allure-playwright跑完用例再用命令行生成 Allure 报告。不过说实话我从实际使用体验出发先默认的 HTML 报告完全够用等团队有特殊需求再上 Allure 也不迟。6.2 GitHub Actions 集成示例自动化测试如果不能跑在持续集成环境里价值会大打折扣。这里用 GitHub Actions 举个例子。在项目根目录建.github/workflows/playwright.ymlname: Playwright Tests on: push: branches: [ main ] pull_request: branches: [ main ] jobs: test: timeout-minutes: 30 runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - uses: actions/setup-nodev3 with: node-version: 18 - run: npm ci - run: npx playwright install --with-deps - run: npx playwright test - uses: actions/upload-artifactv3 if: always() with: name: playwright-report path: playwright-report/ retention-days: 7重点说两个容易被忽略的细节--with-deps参数会同时安装浏览器运行所需的系统依赖库在 Linux 环境里这步基本是必须的否则浏览器可能起不来。if: always()意思是即使用例跑挂了也要把报告上传否则你只能在日志里看到失败信息拿不到现场 trace 和截图。实际跑起来之后PR 的每一次变更都会自动触发全量用例配合 trace 和报告上传相当于整个团队多了一个“不吃不喝的测试员”。6.3 如何控制测试执行时间自动化测试最容易被诟病的就是耗时。当用例从几十条涨到几百条时执行时间可能从几分钟涨到几十分钟。我的处理思路是这样的项目分目录按业务模块建多个 spec 文件CI 里可以并行跑多个任务。只跑关键冒烟集在 PR 阶段可以只跑一个冒烟标记的用例集全量回归放到合并前或者 nightly 定时任务里。合理使用 test.skip 和 test.fixme暂时阻塞的功能直接标注跳过别让它拖垮整体流程。我个人最喜欢的是 Playwright 的标签机制比如把用例标记为smoketest.describe(核心交易流程, () { test(下单并支付 smoke, async ({ page }) { // ... }); });然后在命令行指定只跑冒烟用例npx playwright test --grep smoke这样既保证了主流程的快速反馈又不需要把全量用例分布拆得乱七八糟。7. 进阶实战登录态复用、多页面交互与移动端模拟7.1 登录态的保存与复用做 B 端业务的自动化测试登录状态几乎是每个用例都需要的前置条件。每次用例都走一遍登录流程又慢又容易受到验证码、风控策略干扰。Playwright 支持把登录后的上下文状态保存下来之后用例直接复用// 第一次登录并保存状态 const browser await chromium.launch(); const context await browser.newContext(); const page await context.newPage(); // 登录操作... await context.storageState({ path: state.json }); await browser.close();后续用例就可以这样加载状态跳过登录流程test.use({ storageState: state.json, });这个方案在真实项目里效果立竿见影登录耗时直接归零而且能把登录模块的定制逻辑和普通业务用例解耦。7.2 多页面交互与标签页切换在实际业务里很多操作是点开新标签页完成的比如点击一个站外链接或者在新标签里打开详情页。Playwright 对这类场景的处理也比较直接等待一个新的页面出现然后切换过去。const [newPage] await Promise.all([ context.waitForEvent(page), page.click(a[target_blank]) ]); await newPage.waitForLoadState(); console.log(await newPage.title());这里的手法是一个很典型的“事件监听 触发操作”组合先注册等待事件再执行点击然后取出新页面对象。千万别先点击再去找新页面那样存在竞态条件容易偶发失败。7.3 移动端视口与设备模拟做移动端 H5 页面适配验证的时候不需要非得开一堆真机。Playwright 可以通过修改上下文参数来模拟各类设备const device devices[iPhone 13]; const context await browser.newContext({ ...device, });内置的设备描述符包含了userAgent、viewport、scaleFactor 等参数你在页面上看到的渲染结果几乎和真机相差不大。对响应式布局的校验这个功能很实用我经常用它来快速横向验证不同尺寸下的样式有没有错位。8. 避坑清单那些实测中踩过、也帮你绕开的坑这一节算是我个人最想写的内容。很多 Playwright 的教程只会教你 API 怎么调用但实际落地过程中的细节问题往往是文档里找不到的。坑一浏览器上下文不释放导致内存占用快速爬升。虽然框架会帮我们清理但是如果你在测试里手动创建了很多 context比如反复调用browser.newContext()用完记得await context.close()否则跑大批量用例时内存会被吃满。这个问题在 Windows 环境上尤为明显。坑二网络请求断言太依赖响应体。有些接口会跨域访问而 Playwright 的page.on(response)事件能看到所有网络活动包括跨域请求。但别在事件回调里直接做同步断言因为事件触发时机和页面交互进度不一定对齐。建议用waitForResponse的方式把异步流程控制住。坑三定位器的“严格模式”。如果页面中有多个元素匹配了同一个定位器Playwright 默认会报错提示你定位器不唯一而不是随便帮你选一个。刚开始可能会觉得烦但这是为了减少误操作。遇到这种问题正确姿势是进一步缩小范围比如page.locator(.list).getByText(确认)。如果页面结构没法绕开也可以用.first()或.nth(0)但我还是建议尽量保证定位的唯一性。坑四XPath 和文本定位里的反斜杠问题。某些特殊字符在 XPath 中需要转义比如单引号、反斜杠中文文本定位通常没问题但如果带特殊符号建议使用正则表达式。排查的时候多留意报错信息里是“strict mode violation”还是“element not found”两个问题解法完全不一样。坑五不要在测试脚本里依赖固定的等待时间。这一点前面反复说过但还是要提一次。我在内部评审时看到最多的问题就是有人写着await page.waitForTimeout(3000)试图“确保”某个异步操作完成。除非是验证“网络超时”这类故意场景否则这几乎都会导致用例在不稳定环境上波动。用expect的自动重试来代替无脑等待是 Playwright 实践中最值得建立的习惯。9. 一些个人体会我之前花了不少时间维护老框架脚本大部分精力其实都用在了“让脚本稳定”上而不是真正“把业务测透”。转到 Playwright 以后最大的感受是思路彻底被转换了框架已经把稳定性、可诊断性这些工程问题解决了一大半剩下只需要专注于描述业务场景和验证逻辑。如果项目里正准备端到端测试选型或者正在被老框架的稳定性折磨我真心建议认真试一下 Playwright。把时间花在写业务用例上而不是和“等待、网络、竞态”这些基础设施问题反复纠缠这个投入的性价比是很高的。最后再说一个小技巧如果你的项目里有大量重复的业务操作步骤比如新建订单、添加联系人、上传文件等可以考虑把操作封装成自定义的 fixture 或者 Page Object 类而不是每个用例把步骤重写一遍。封装以后用例本身会变得非常薄一眼就能看出这条用例到底在验证什么逻辑这才是自动化测试长期可持续发展的关键。
1. 为什么我抛弃了旧的自动化方案转投 Playwright 阵营先交代一下背景。我之前的项目里大量使用老牌的自动化测试框架做端到端测试维护成本是真的高。每次跑测试最头疼的不是业务逻辑变复杂而是脚本和浏览器之间的“同步问题”明明页面元素已经渲染出来了脚本还在傻等偶尔网络慢一点用例就大面积误报。团队里每个人都曾被这种“不稳定”折磨过最后大家甚至对自动化测试产生了某种抵触情绪。后来我开始调研新一代的自动化测试工具注意到 Playwright 出现的频率越来越高。GitHub 上星标涨得飞快核心团队是从老牌框架项目出来的属于“原生血统”的正规军。最初我抱着试试看的心态在几个小项目里跑了一下结果发现几个痛点被精准解决了内置了自动等待机制再也不用到处写sleep(3000)或者是轮询轮询再轮询。一套 API 同时覆盖 Chromium、Firefox、WebKit 三种浏览器内核跨浏览器验证不再是奢望。默认采用浏览器上下文隔离每个测试用例天然独立互相不污染。自带Trace Viewer追踪查看器用例挂了能看到完整录屏、DOM 快照和网络请求定位问题像看回放一样。这几个特性几乎是在对着我之前踩过的坑逐一开火。所以这期内容我不打算只写一堆 API 文档翻译而是想按照我自己的学习路径和实战经验把 Playwright 从入门到落地整个流程串一遍。内容覆盖环境搭建、核心概念、常用 API、断言设计、调试技巧、测试报告以及持续集成接入尽量做到“看完就能在自己项目里用起来”。如果你正在做 Web 自动化测试或者刚接触 Playwright 想快速进入实战状态这篇文章应该能帮你省掉不少摸索时间。如果你对老框架已经很熟想找个更稳的替代方案这篇内容也可以给你一个相对客观的参考。2. 环境准备与第一个测试用例五分钟先跑起来2.1 安装与内置浏览器管理Playwright 的安装过程比我预想中还要顺。项目里只需要基于 Node.js版本建议 16 以上执行一条命令就能把核心库装好npm init -y npm install -D playwright/test很多人会问装完包是不是还得单独下载 Chrome 或者 Firefox实际上 Playwright 会自己维护一套专用浏览器版本你需要再执行一行命令把浏览器内核拉下来npx playwright install这里它默认会同时下载 Chromium、Firefox 和 WebKit 三件套。如果你只做业务上的回归测试只下 Chromium 也能跑但下载全量版本有个好处跨浏览器兼容性验证可以随时做不耽误事。注意npx playwright install下载的浏览器路径和系统里你自己装的 Chrome 不是同一个东西它们的版本是配套的互不干扰。2.2 第一个冒烟测试脚本装完依赖之后我习惯先在项目根目录建一个tests文件夹然后丢一个最简单的冒烟脚本进去const { test, expect } require(playwright/test); test(第一个冒烟用例, async ({ page }) { await page.goto(https://example.com); await expect(page).toHaveTitle(Example Domain); });这里面的page对象是由框架自动注入的每个测试都会拿到一个全新的页面实例你不需要关心它的创建和销毁过程。然后执行npx playwright test框架会自动找到tests目录下的所有.spec.js或者.test.js文件逐个跑完并输出一个美观的测试报告。刚开始跑这个用例就能感受到 exec 速度还不错。默认情况下Playwright 是并行执行测试文件的如果测试文件多了它还会自动分配 worker 进程尽量吃满 CPU 资源。2.3 为什么 Playwright 能让脚本“更稳”这里想多说一句因为很多人用老框架写自动化最后脚本全部变成了“睡眠大作战”sleep(1秒)、sleep(2秒)、循环重试……这样写出来的脚本不但慢而且特别脆。Playwright 之所以“稳”核心在于它内置了一套可操作性的检查机制Actionability Checks。在点击、填写、选择这类操作之前它自动会做几件事元素是否已经附着在 DOM 上。元素是否可见不是隐藏状态。元素是否稳定比如动画还没停它会等着。元素是否接收事件比如有没有被遮罩层挡住。元素是否可用不是 disabled 状态。这五条检查全部通过以后操作才会真正执行。如果过了一段时间仍然不满足才会报超时错误。这等于把以前大家手动写的“等待逻辑”内化到了框架层脚本稳定性和开发效率一下子提升了一个档次。3. 核心概念与定位器机制不懂这些东西后面很容易踩坑3.1 页面对象与浏览器上下文在正式写复杂用例之前有必要把 Playwright 的几个核心概念理清楚。Browser浏览器实例对应一个完整的浏览器进程。BrowserContext浏览器上下文可以简单理解成一个独立的“隐身窗口”会话。不同 context 之间的 Cookie、缓存、本地存储都是隔离的。Page页面对象表示一个标签页。大多数情况下你的操作都是围绕 page 展开的。这里最关键的设计是 BrowserContext。测试用例最怕什么最怕相互影响。A 用例登录了B 用例还是游客状态A 用例往 localStorage 写了配置B 用例读到了脏数据。在 Playwright 里每个测试默认都跑在独立的 context 里从源头上隔离了干扰。这也是我当初决定深入使用它的一个重要理由。框架还给每个测试提供了固定的pagefixture你甚至不用自己手动创建 context直接拿去用即可。3.2 定位器从 CSS 选择器到逻辑定位早期自动化测试里大家习惯用page.click(#btn-submit)这类的写法选择器写在操作里。这种写法最大的问题是改起来麻烦代码里选择器到处散落后期维护基本靠全局搜索。Playwright 推荐的方式是定位器Locator。定位器不是立即去页面上找元素而是先描述“我要找什么”等到真正要执行操作或者断言时再由框架去动态匹配。这个概念和函数式编程里的“惰性求值”有点像。举个例子原来我们可能会这样处理复选框await page.check(input[typecheckbox]);但更好的方式是把定位器抽象出来const agreeCheckbox page.locator(input[typecheckbox]); await agreeCheckbox.check();这样不仅代码可读性更高也方便复用。Playwright 同时也提供了一组语义更强的定位器方法比如getByRole()、getByText()、getByLabel()。在可访问性做得比较好的页面上我更喜欢用角色定位器例如await page.getByRole(button, { name: 提交订单 }).click();这个方法接近用户真实的使用视角——用户看到一个按钮看到按钮上的文字然后点击。脚本也按这个思路去找目标元素别想着非得写一大长串 div 嵌套层级。3.3 定位器优先级原则很多新手上来就喜欢写一气呵成的 CSS 选择器什么#root div.container div.row button.btn-primary这种选择器的问题在于一旦页面结构改版比如多加一层 div用例就全挂了。我自己总结了一个优先级的参考顺序可以给大家一个方向优先级定位方式适用场景1用户可见文本链接、按钮、标题2无障碍角色对语义标签支持良好的项目3Label 标签表单相关的输入控件4表单占位符输入框有 placeholder 提示5测试专用 ID>await expect(page.getByText(保存成功)).toBeVisible();这个断言会在超时前不断轮询直到元素可见或者超时。比原来“睡眠固定时间”可靠得多。这个设计核心就是给条件断言一个时间窗口让它在窗口内反复检查而不是盲等。4.2 什么时候需要手动等待虽然框架很聪明但有些场景还是需要一点手动控制的。比如你要等某个接口返回之后才能确定后续数据是否完整或者某个元素被隐藏后页面布局变化把另一个元素推到了新的位置。这类“时序敏感”的场景建议有两种姿势第一种是等待特定接口响应const responsePromise page.waitForResponse(**/api/order/list); await page.click(button:has-text(刷新)); const response await responsePromise; console.log(await response.json());这样写的好处是把“等待”和“业务”绑定在一起而不是干等时间。第二种是显式等待某个元素状态比如await page.waitForSelector(.loading-hidden, { state: hidden });但总体上我的原则是能靠 expect 自动重试解决的就别动 wait 相关 API能靠 waitForResponse 解决的就别写固定 sleep。固定时间等待永远是最后选项因为它在机器负载高或网络波动时一定会反过来坑你。4.3 超时配置的合理设定超时时间大家也可以按项目调一下。默认的 expect 超时是 5 秒如果你在很慢的页面或者复杂渲染场景下可以按需改到 15 秒甚至更长。我喜欢在配置文件playwright.config.js里统一管理module.exports { timeout: 30000, expect: { timeout: 10000 } };但注意不要让超时时间给脚本“兜底”。如果一个断言每次都是等到超时才通过说明前面操作可能不太稳这种隐藏风险越早暴露越好别只用超时时间掩盖。5. 断言与调试技巧少走弯路快速定位问题5.1 常用断言 API 一览Playwright 的断言写法延续了 Jest 的风格但背后加了一层自动重试的逻辑。常见的断言大概有这些await expect(locator).toBeVisible(); await expect(locator).toBeHidden(); await expect(locator).toHaveText(订单已提交); await expect(locator).toContainText(成功); await expect(locator).toHaveCount(3); await expect(page).toHaveURL(**/order/detail?id123); await expect(page).toHaveTitle(标题);这里有一个比较容易忽略的细节toHaveText是全量匹配toContainText是包含匹配。比如一个元素的文本是“xxx 你好 xxx”toHaveText(你好)会失败而toContainText(你好)会通过。很多刚上手的朋友在这里吃过亏特意提醒一下。5.2 页面快照、Trace 与录屏调试用例失败的时候第一反应当然是想知道当时页面上发生了什么。控制台会把失败信息打印出来但这远远不够。我喜欢用追踪查看器来分析它几乎相当于把测试过程“录”了下来包含页面截图、网络请求、DOM 快照和浏览器控制台日志。要让追踪功能生效只需要在命令行加一个参数npx playwright test --trace on跑完用例后会在test-results目录下生成.zip文件再执行npx playwright show-trace就能在浏览器里打开一个交互式的追踪报告。你可以逐步回放每一个操作看到点击之前的元素状态、点击之后触发的网络请求、以及浏览器报错。定位一个偶发问题比靠日志盲猜快太多了。另外如果你遇到“某些用例本地过一到 CI 就挂”的经典问题我强烈建议在 CI 失败的时候强制保留 trace。配置方式use: { trace: retain-on-failure, }这样只有失败的用例会留下完整现场既不浪费普通用例的存储关键时候又有据可查。5.3 利用 Inspector 和 Playwright 的代码生成器还有一个新手友好度极高的功能代码生成器Codegen。它可以把你在页面上的手动操作自动转成脚本。启动方式npx playwright codegen运行后浏览器会打开一个窗口你在里面点按钮、填表单、跳页面代码面板会同步生成对应脚本。刚开始玩 Playwright 的时候我会先把业务主流程用 codegen 过一遍然后再手动整理选择器和步骤效率提升非常明显。不过 codegen 生成的脚本只是一个起点它会生成很多绝对化的路径选择器我的习惯是生成之后再人工改成语义化的 getByRole / getByText并在合适的位置加上断言。6. 测试报告与 CI/CD 集成让自动化测试真正发挥价值6.1 HTML 报告与 Allure 对比测试报告是一个大家容易忽略、但实际使用体验影响非常大的部分。默认跑完npx playwright test之后控制台输出的是一个简洁的用例列表但如果想要更直观的统计信息、失败截图、console 日志建议打开 HTML Reportnpx playwright show-reportPlaywright 自带的 reporter 界面比较现代按功能模块suite、test、hooks 等分组展示点开失败用例能看到错误栈、附件截图、trace 等。大部分团队用它已经够了。如果你的团队对报告有更高的展示要求比如想按需求模块分类或者要生成更精美的 PDF 报告也可以引入 Allure。Playwright 有官方的 allure-playwright 插件安装后配置 reporter 为allure-playwright跑完用例再用命令行生成 Allure 报告。不过说实话我从实际使用体验出发先默认的 HTML 报告完全够用等团队有特殊需求再上 Allure 也不迟。6.2 GitHub Actions 集成示例自动化测试如果不能跑在持续集成环境里价值会大打折扣。这里用 GitHub Actions 举个例子。在项目根目录建.github/workflows/playwright.ymlname: Playwright Tests on: push: branches: [ main ] pull_request: branches: [ main ] jobs: test: timeout-minutes: 30 runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - uses: actions/setup-nodev3 with: node-version: 18 - run: npm ci - run: npx playwright install --with-deps - run: npx playwright test - uses: actions/upload-artifactv3 if: always() with: name: playwright-report path: playwright-report/ retention-days: 7重点说两个容易被忽略的细节--with-deps参数会同时安装浏览器运行所需的系统依赖库在 Linux 环境里这步基本是必须的否则浏览器可能起不来。if: always()意思是即使用例跑挂了也要把报告上传否则你只能在日志里看到失败信息拿不到现场 trace 和截图。实际跑起来之后PR 的每一次变更都会自动触发全量用例配合 trace 和报告上传相当于整个团队多了一个“不吃不喝的测试员”。6.3 如何控制测试执行时间自动化测试最容易被诟病的就是耗时。当用例从几十条涨到几百条时执行时间可能从几分钟涨到几十分钟。我的处理思路是这样的项目分目录按业务模块建多个 spec 文件CI 里可以并行跑多个任务。只跑关键冒烟集在 PR 阶段可以只跑一个冒烟标记的用例集全量回归放到合并前或者 nightly 定时任务里。合理使用 test.skip 和 test.fixme暂时阻塞的功能直接标注跳过别让它拖垮整体流程。我个人最喜欢的是 Playwright 的标签机制比如把用例标记为smoketest.describe(核心交易流程, () { test(下单并支付 smoke, async ({ page }) { // ... }); });然后在命令行指定只跑冒烟用例npx playwright test --grep smoke这样既保证了主流程的快速反馈又不需要把全量用例分布拆得乱七八糟。7. 进阶实战登录态复用、多页面交互与移动端模拟7.1 登录态的保存与复用做 B 端业务的自动化测试登录状态几乎是每个用例都需要的前置条件。每次用例都走一遍登录流程又慢又容易受到验证码、风控策略干扰。Playwright 支持把登录后的上下文状态保存下来之后用例直接复用// 第一次登录并保存状态 const browser await chromium.launch(); const context await browser.newContext(); const page await context.newPage(); // 登录操作... await context.storageState({ path: state.json }); await browser.close();后续用例就可以这样加载状态跳过登录流程test.use({ storageState: state.json, });这个方案在真实项目里效果立竿见影登录耗时直接归零而且能把登录模块的定制逻辑和普通业务用例解耦。7.2 多页面交互与标签页切换在实际业务里很多操作是点开新标签页完成的比如点击一个站外链接或者在新标签里打开详情页。Playwright 对这类场景的处理也比较直接等待一个新的页面出现然后切换过去。const [newPage] await Promise.all([ context.waitForEvent(page), page.click(a[target_blank]) ]); await newPage.waitForLoadState(); console.log(await newPage.title());这里的手法是一个很典型的“事件监听 触发操作”组合先注册等待事件再执行点击然后取出新页面对象。千万别先点击再去找新页面那样存在竞态条件容易偶发失败。7.3 移动端视口与设备模拟做移动端 H5 页面适配验证的时候不需要非得开一堆真机。Playwright 可以通过修改上下文参数来模拟各类设备const device devices[iPhone 13]; const context await browser.newContext({ ...device, });内置的设备描述符包含了userAgent、viewport、scaleFactor 等参数你在页面上看到的渲染结果几乎和真机相差不大。对响应式布局的校验这个功能很实用我经常用它来快速横向验证不同尺寸下的样式有没有错位。8. 避坑清单那些实测中踩过、也帮你绕开的坑这一节算是我个人最想写的内容。很多 Playwright 的教程只会教你 API 怎么调用但实际落地过程中的细节问题往往是文档里找不到的。坑一浏览器上下文不释放导致内存占用快速爬升。虽然框架会帮我们清理但是如果你在测试里手动创建了很多 context比如反复调用browser.newContext()用完记得await context.close()否则跑大批量用例时内存会被吃满。这个问题在 Windows 环境上尤为明显。坑二网络请求断言太依赖响应体。有些接口会跨域访问而 Playwright 的page.on(response)事件能看到所有网络活动包括跨域请求。但别在事件回调里直接做同步断言因为事件触发时机和页面交互进度不一定对齐。建议用waitForResponse的方式把异步流程控制住。坑三定位器的“严格模式”。如果页面中有多个元素匹配了同一个定位器Playwright 默认会报错提示你定位器不唯一而不是随便帮你选一个。刚开始可能会觉得烦但这是为了减少误操作。遇到这种问题正确姿势是进一步缩小范围比如page.locator(.list).getByText(确认)。如果页面结构没法绕开也可以用.first()或.nth(0)但我还是建议尽量保证定位的唯一性。坑四XPath 和文本定位里的反斜杠问题。某些特殊字符在 XPath 中需要转义比如单引号、反斜杠中文文本定位通常没问题但如果带特殊符号建议使用正则表达式。排查的时候多留意报错信息里是“strict mode violation”还是“element not found”两个问题解法完全不一样。坑五不要在测试脚本里依赖固定的等待时间。这一点前面反复说过但还是要提一次。我在内部评审时看到最多的问题就是有人写着await page.waitForTimeout(3000)试图“确保”某个异步操作完成。除非是验证“网络超时”这类故意场景否则这几乎都会导致用例在不稳定环境上波动。用expect的自动重试来代替无脑等待是 Playwright 实践中最值得建立的习惯。9. 一些个人体会我之前花了不少时间维护老框架脚本大部分精力其实都用在了“让脚本稳定”上而不是真正“把业务测透”。转到 Playwright 以后最大的感受是思路彻底被转换了框架已经把稳定性、可诊断性这些工程问题解决了一大半剩下只需要专注于描述业务场景和验证逻辑。如果项目里正准备端到端测试选型或者正在被老框架的稳定性折磨我真心建议认真试一下 Playwright。把时间花在写业务用例上而不是和“等待、网络、竞态”这些基础设施问题反复纠缠这个投入的性价比是很高的。最后再说一个小技巧如果你的项目里有大量重复的业务操作步骤比如新建订单、添加联系人、上传文件等可以考虑把操作封装成自定义的 fixture 或者 Page Object 类而不是每个用例把步骤重写一遍。封装以后用例本身会变得非常薄一眼就能看出这条用例到底在验证什么逻辑这才是自动化测试长期可持续发展的关键。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
