写点什么

Playwright 为什么老是跑不稳?12 个坑踩完我终于懂了!

  • 2025-11-06
    黑龙江
  • 本文字数:1612 字

    阅读完需:约 5 分钟

周五傍晚,理想的状态是测试报告全绿、CI 顺利完成、泡杯咖啡享受下班时光。


如果你的 Playwright 测试套件老是慢、莫名失败、生成一堆无用截图,那说明你的测试实践还有提升空间。下面这 12 条,结合实战经验和落地方法,帮你把“周五发版提心吊胆”变成“放心发版”。



1)按风险与业务流程划分用例,而非死堆模块

把测试当成风险网,而不是功能文档。


  • 高风险链路(登录、下单、支付)快速覆盖、严格断言

  • 次要视觉或边界用例夜间或发版前全量回归


落地: 用标签(@critical / @regression)或不同集合,PR 提交只跑 @critical,发版前跑 @regression,既保证快速反馈,又覆盖全量风险。



2)稳定的定位策略:优先 data-test 或 role / class

定位器不稳定是测试不稳定的罪魁祸首。


  • 优先使用 data-test / data-testid

  • 如果暂时不可用,可选择稳定的 class 或 role 属性

  • 避免基于文本或深层 CSS 的脆弱选择器


落地: 核心元素加测试 ID,PR/Lint 检查 enforce 规范。



人工智能测试开发技术学习 Agent Dify Playwright MCP n8n

3)放弃固定 sleep,靠明确信号同步

waitForTimeout 是“坏味道”,会增加测试抖动。


  • 优先等待网络完成、元素可见或路由稳定

  • 使用 Playwright 自动等待和 web-first 断言


示例:


await page.waitForResponse(resp => resp.url().includes('/api/orders') && resp.status() === 200);await expect(page.locator('#submit')).toBeVisible();
复制代码



4)把登录和共有状态放入 fixtures / storageState

重复登录既慢又易出错。


  • 用 storageState 或 fixtures 保存登录态

  • 测试启动即加载登录状态,快速、稳定、可靠


落地: setup 脚本生成 auth.json,测试启动时加载 context.addCookies()storageState



5)测试数据优先通过 API 或后端接口准备

UI 流程慢、脆弱。


  • 数据准备和清理通过 API 完成

  • UI 只做端到端验证或展示验证


落地: CI 阶段调用 /api/test/setup 初始化数据,测试结束 /api/test/teardown 清理,保证每次运行环境可控。



6)Mock 外部依赖,保留少量真实监控

第三方服务(支付、短信、地图)可能导致随机失败。


  • 用 HAR 回放或 route/stub 固定响应

  • 只保留少量真实调用做 Canary 监控


落地: CI 中 mock 不可控接口,单独一组真实环境做稳定性监控。



7)视觉回归需精细化

视觉回归容易产生噪音:


  • 动态区域(时间戳、广告位、头像)用 mask

  • 核心组件设置严格阈值,非核心用宽松阈值


落地: 先从核心页面开始,小范围验证,再逐步扩大覆盖。



8)Trace / 视频按需开启

Trace 和视频在失败时极其有用,但全程开启会拖慢测试。


  • 按测试或失败条件动态开启

  • CI 默认关闭 trace,但失败时自动启用


落地: 失败 artifact 上传 trace 或视频,方便快速定位。



9)合理设置并发与 worker 数

并发并非越高越好。


  • 先 profile 测试 suite,找出瓶颈(CPU、DB、网络)

  • worker 数量结合系统资源和 suite 特性调整


落地: 调整并发时观察整体耗时和资源占用,避免盲目加 worker。



10)倾向“业务剧本式”辅助函数

传统 Page Object 易膨胀难维护。


  • 将复杂业务流程拆成可复用的步骤函数

  • 测试代码读起来像业务故事


示例:


await auth.loginAs(user);await cart.addItem(item);await checkout.placeOrder();
复制代码



11)让不稳定用例可见、可追踪

Flaky 测试应被量化和隔离,而非无限重试。


  • 统计每个 spec 失败率

  • 超过阈值标注、隔离并创建修复任务


落地: CI 输出失败率报表,高失败率用 test.skiptest.fixme,并跟踪 issue。



12)报告标准化,关键信息一目了然

截图、trace、网络请求是定位问题关键线索。


  • 命名标准化,方便快速定位

  • CI artifact 暴露 HTML 报告和 trace


落地: 截图命名示例:specName--step--timestamp,报告可以点击直接查看失败详情。



写在后面

Playwright 不只是工具,而是一套工程化方法:


  • 按业务风险划分用例

  • 测试数据可控、环境稳定

  • 定位器稳健、并发合理

  • Trace、截图、网络请求标准化管理


只要逐条优化,测试流程焦虑感会逐渐消失,发版不再提心吊胆。


人工智能测试开发技术学习 Agent Dify Playwright MCP n8n

用户头像

社区:ceshiren.com 微信:ceshiren2023 2022-08-29 加入

微信公众号:霍格沃兹测试开发 提供性能测试、自动化测试、测试开发等资料、实事更新一线互联网大厂测试岗位内推需求,共享测试行业动态及资讯,更可零距离接触众多业内大佬

评论

发布
暂无评论
Playwright为什么老是跑不稳?12个坑踩完我终于懂了!_测吧(北京)科技有限公司_InfoQ写作社区