Playwright 核心能力与实战笔记

异步模式

import asyncio
from time import sleep
from playwright.async_api import async_playwright

async def main():
    async with async_playwright() as p:
        browser = await p.firefox.launch(headless=False)
        page = await browser.new_page()
        
        await page.goto('https://www.example.com')
        title = await page.title()
        print(title)
        
        await browser.close()

asyncio.run(main())

这两种模式没有绝对优劣。同步版更适合从零开始熟悉 API，异步版适合已经在项目里用 asyncio 的场景。

6、定位元素，别把自己绕进去

自动化测试里最容易翻车的，往往不是浏览器本身，而是定位方式太脆。

CSS 选择器

page.click('#submit-button')
page.fill('.input-field', 'Hello World')

XPath

XPath 仍然能用，但我一般不会把它放在首选位，除非页面结构实在不好处理。

page.click('//button[@type="submit"]')

文本定位

page.click('text=Submit')
page.click('text=Login')

角色定位

page.click('role=button[name="Submit"]')

data-testid

如果你能控制前端代码，给关键元素加 data-testid 通常是最稳的。它不花哨，但维护成本低。

<button data-testid="login-btn">Login</button>

page.click('[data-testid="login-btn"]')

7、自动等待

Playwright 真正省事的地方，是它把很多等待逻辑内置了。执行操作前，它会先看元素是否已经出现在 DOM 中、是否可见、是否可交互、是否还在动画里。

所以大多数时候你不需要自己塞一堆 sleep()。这不是偷懒，而是减少不稳定测试的有效办法。

# 即使按钮加载慢，click 也会自动等待其就绪
page.click('#submit-btn') 

8、断言怎么写

Playwright 自带断言，够日常用了。

# 验证元素存在
assert page.is_visible('#header')

# 验证文本内容
expect(page.locator('.title')).to_contain_text('Welcome')

# 验证 URL
expect(page).to_have_url('https://www.example.com/page')

# 验证颜色值
expect(page.locator('.box')).to_have_css('background-color', 'rgb(255, 0, 0)')

这里的思路很简单：能直接用库里的能力验证状态，就别再自己造一套轮子。

9、几个常见的复杂界面处理

弹窗和新窗口

# 监听新窗口
with page.expect_popup() as popup_info:
    page.click('#open-modal')
popup = popup_info.value
popup.wait_for_load_state()

文件上传

page.set_input_files('input[type=file]', 'path/to/file.pdf')

Iframe

frame = page.frame_locator('iframe[src="/embedded"]')
frame.locator('#inner-input').fill('Content in iframe')

这些场景本身不难，难的是写出后面还能维护的定位方式。能尽量靠近业务语义，就别盯着层级很深的 DOM 结构。

10、代码生成器

Playwright 自带 codegen，可以边操作边生成代码。

# 启动代码生成器
playwright codegen https://www.example.com

这个工具很适合刚接触 Playwright 的人。你在浏览器里点几下，它会把对应的 Python 代码实时吐出来，拿来做学习起点挺合适。只是生成出来的代码通常偏'能跑'，离'适合长期维护'还有一步。

11、Trace Viewer

测试一旦失败，Trace Viewer 很值得开。它能把执行过程拆成一帧一帧的快照，比单看日志好读得多。

启用追踪

trace_path = 'trace.zip'
page.start_tracing(path=trace_path)
# ... 执行测试操作 ...
page.stop_tracing()

查看追踪

playwright show-trace trace.zip

打开之后，你能看到每一步的 DOM 快照、网络请求、控制台日志和鼠标轨迹。排查那种'本地没问题，CI 上偶发失败'的问题时，这东西挺管用。

12、CI/CD 集成

Playwright 很容易接进 CI 流程，比如 GitHub Actions。

- name: Install dependencies
  run: npm ci && npx playwright install --with-deps

- name: Run tests
  run: npx playwright test

如果项目本来就有前端构建流水线，把测试顺手挂进去并不麻烦。真正的成本一般不在接入，而在你愿不愿意把测试写得足够稳定。

13、我更建议的用法

• 页面对象模式（POM）可以上，尤其是页面多、流程长的时候。
• 别手写一堆固定等待，Playwright 的自动等待已经够用了。
• 关键元素优先用 data-testid，别把测试绑死在脆弱的结构上。
• 需要跑得快时再考虑并行，不要一开始就把复杂度拉满。
• 版本更新别拖太久，工具类库的行为变化，往往比你想象得更影响脚本稳定性。

14、最后

Playwright 受欢迎，不是因为它'看起来先进'，而是它把浏览器自动化里那些最烦人的细节处理得比较顺。安装省事，定位方式够多，等待机制也比老方案自然。对需要稳定跑 Web 端到端测试的团队来说，它确实是一个值得长期用下去的工具。