避开 Playwright 常见陷阱，让你的 UI 测试更快更稳

关注 霍格沃兹软件测试开发 公众号，回复「资料」, 领取人工智能测试开发技术合集

做UI自动化测试的朋友应该都有过这种体验——本地跑得好好的，一上CI就挂；周一全绿，周二莫名其妙红一片；加了sleep能过，不加就报元素找不到。

如果你也遇到过这些情况，别急着怀疑是自己的代码写得不够好。很多时候问题出在“习惯”上——把Selenium时代的老经验照搬到Playwright里，或者没搞清楚Playwright的底层机制就开始写用例。

下面这8个坑，是我和团队在过去一年里一个一个踩过来的。整理出来，希望能帮你少走点弯路。

坑1：还在用waitForTimeout /sleep 硬等
这是新手最容易犯的错误，没有之一。

很多人习惯了Selenium里那种Thread.sleep(3000) 的写法，到了Playwright还是改不掉。动不动就page.wait_for_timeout(5000)，觉得“等5秒总该加载完了吧”。

问题在哪？ 固定等待时间就像刻舟求剑——网络快的时候浪费5秒，网络慢的时候5秒还不够。测试要么跑得慢，要么时好时坏。

正确的做法：Playwright自带自动等待机制，执行click()、fill() 这些操作之前，它会自动等待元素可见、可操作、稳定。你什么都不用写。

❌ 错误示范

page.wait_for_timeout(3000)
page.locator("#submit").click()

✅ 正确示范——Playwright自己会等

page.locator("#submit").click() # 自动等待按钮可点击
如果确实需要等待某个特定条件（比如API返回数据），用wait_for_response 或wait_for_selector，绑定到明确信号上。

什么时候可以用 wait_for_timeout？ 说实话，90%的场景用不上。只有在调试阶段或者等待第三方非交互内容加载时，才把它当作最后手段。

坑2：定位器写得“太聪明”
复杂CSS选择器、依赖文本内容的选择器、XPath——这些东西写的时候觉得很爽，一改版全废。

比如你写了个page.locator('#main-content > div:nth-child(3) > button')，开发同事把页面结构调整了一下，你的测试就挂了。

正确的做法：优先用data-testid。让开发在核心UI元素上加上测试专用的属性，这是代码和测试之间的“契约”。

❌ 脆弱的选择器

page.locator('#app > div.container > button.btn-primary')

✅ 稳定的选择器

page.locator('[data-testid="submit-button"]')
如果项目里暂时没有data-testid，退而求其次可以用get_by_role 或get_by_text，但尽量选择不容易变动的属性。

坑3：自动等待“撞上”组件重渲染
这个坑比较隐蔽，很多人都没意识到。

Playwright的自动等待机制是这样的：它检查元素是否可见、稳定、可操作，检查通过之后立即执行操作。但如果就在“检查通过”和“执行操作”之间的那个瞬间，你的组件正好重新渲染了——按钮被替换成了一个新按钮——点击就会失败，报错Element is not attached to the DOM。

典型场景：点击保存按钮，按钮变成“保存中...”的禁用状态，保存完成后再变回可点击状态。第二次点击就可能撞上重渲染。

解决方案：

方案一：用 data-testid 定位到不会重渲染的外层元素

save_button = page.locator('[data-testid="save-container"] button')
save_button.click()

方案二：点击前先显式等待一下

save_button.wait_for(state="visible")
save_button.click()
或者更干脆——在测试环境里把动画效果关掉，减少重渲染的触发。

坑4：每个测试都从头登录
一套测试用例几十上百个，每个用例都打开登录页、输用户名密码、点登录——慢不说，万一登录接口挂了，所有测试全崩。

解决方案：用storageState 保存登录态。

先跑一次登录，保存登录状态到文件

在 playwright.config.py 里配置

use = {
"storage_state": "auth.json"
}
这样每个测试启动时就已经是登录状态了，又快又稳。

坑5：测试之间“互相传染”
这个坑特别恶心——单个用例跑全过，一起跑就随机挂。问题出在测试之间共享了可变状态。

比如你在模块级别定义了一个page 对象，用例A把它导航到了页面A，用例B以为它还在首页，结果就挂了。

解决方案：每个测试用独立的page 或context。Playwright的fixture机制天然支持这一点：

✅ 每个测试都有自己的 page，互不干扰

def test_something(page):
page.goto("/page-a")
# ...

def test_something_else(page):
page.goto("/page-b") # 干净的页面，不受上一个用例影响
# ...
如果确实需要共享某些只读数据（比如配置），用beforeAll 没问题，但不要共享可变对象。

坑6：滥用networkidle 等待
page.wait_for_load_state("networkidle") 看起来很美——“等所有网络请求都结束了再继续”。但问题在于：单页应用（SPA）里网络请求可能永远停不下来——轮询、WebSocket、长连接，这些东西会让networkidle 一直等下去。

解决方案：不要等“所有请求结束”，等“你关心的那个请求结束”。

❌ 可能永远等不完

page.wait_for_load_state("networkidle")

✅ 只等数据接口返回

with page.expect_response("**/api/orders") as response_info:
page.locator("#load-orders").click()
response = response_info.value
这样既精准又高效。

坑7：Trace/视频全程开着
Trace和视频确实好用，出问题的时候能帮你快速定位。但全程开着会严重拖慢测试速度，CI上跑一次多花好几分钟。

解决方案：只在失败时开启。

playwright.config.py

use = {
"trace": "on-first-retry", # 只在重试时录trace
"video": "on-first-retry",
}
这样大部分通过的测试跑得快，失败的测试也有足够的现场信息供排查。

人工智能技术学习交流群
伙伴们，对AI测试、大模型评测、质量保障感兴趣吗？我们建了一个 「人工智能测试开发交流群」，专门用来探讨相关技术、分享资料、互通有无。无论你是正在实践还是好奇探索，都欢迎扫码加入，一起抱团成长！期待与你交流！👇

坑8：盲目加并发
“测试跑得慢？加worker！”——这个思路听起来没毛病，但实际上并发不是越高越好。

并发太高会导致CPU、内存、数据库连接池资源竞争，测试反而更慢，甚至出现莫名其妙的超时失败。

解决方案：先profile再调参。先跑一遍看看瓶颈在哪——是CPU满了？数据库连接不够？还是网络带宽受限？找到真正的瓶颈再决定要不要加worker，加几个。

一张表总结
坑
核心问题
解决方案
硬编码等待
用sleep/固定超时
依赖Playwright自动等待 + web-first断言
脆弱定位器
依赖CSS层级/文本
优先data-testid 或get_by_role
自动等待撞重渲染
组件在操作瞬间被替换
用稳定定位器 + 显式wait_for
重复登录
每个用例都走登录流程
用storageState 复用登录态
测试间状态污染
共享可变对象
每个用例独立page/context
滥用networkidle
SPA里请求停不下来
等特定API响应，不等全部
Trace全程开
拖慢测试速度
只在失败/重试时开启
盲目加并发
资源竞争反而更慢
先找瓶颈再调worker数
最后说两句
上面这些坑，大多数不是Playwright本身的问题，而是使用方式的问题。它提供的工具都是好工具，关键看你怎么用。

如果你刚接触Playwright不久，建议从“坑3”（自动等待撞重渲染）和“坑6”（networkidle）这两个入手重点看一下——这两个是最容易让人困惑、也最不容易自己琢磨明白的。

如果你的测试套件已经有一定规模了，建议优先排查“坑4”（重复登录）和“坑5”（测试间污染），这两个对稳定性和速度的影响最大。

你有什么踩过的坑上面没提到的？欢迎评论区补充，大家一起避雷。

推荐学习
把指令、脚本和资源打包成一个标准化的“技能包”。一次教会，终身受用；换个平台，照样生效。

课程内容：

彻底搞懂 Skill、Prompt、MCP 三者的本质区别，从此不再概念混淆
掌握“按需加载”机制，让 AI 只读取当前任务需要的上下文，Token 省着花
手把手封装你的第一个个人专属 AI 技能，现场跑通
进阶用法：用脚本和条件触发，让 AI 自动执行复杂工作流，不再只能“查资料”
掌握开放标准，一次打包，Claude、Cursor 等多平台无缝复用

关于我们
霍格沃兹测试开发学社，隶属于测吧（北京）科技有限公司，是一个面向软件测试爱好者的技术交流社区。

学社围绕现代软件测试工程体系展开，内容涵盖软件测试入门、自动化测试、性能测试、接口测试、测试开发、全栈测试，以及人工智能测试与 AI 在测试工程中的应用实践。

我们关注测试工程能力的系统化建设，包括 Python 自动化测试、Java 自动化测试、Web 与 App 自动化、持续集成与质量体系建设，同时探索 AI 驱动的测试设计、用例生成、自动化执行与质量分析方法，沉淀可复用、可落地的测试开发工程经验。

在技术社区与工程实践之外，学社还参与测试工程人才培养体系建设，面向高校提供测试实训平台与实践支持，组织开展“火焰杯” 软件测试相关技术赛事，并探索以能力为导向的人才培养模式，包括高校学员先学习、就业后付款的实践路径。

同时，学社结合真实行业需求，为在职测试工程师与高潜学员提供名企大厂 1v1 私教服务，用于个性化能力提升与工程实践指导。