Playwright为什么老是跑不稳？12个坑踩完我终于懂了！如果你的 Playwright 测试套件老是慢、莫名失败、

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

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

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

高风险链路（登录、下单、支付）快速覆盖、严格断言
次要视觉或边界用例夜间或发版前全量回归

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

稳定的定位策略：优先 data-test 或 role / class

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

优先使用 data-test / data-testid
如果暂时不可用，可选择稳定的 class 或 role 属性
避免基于文本或深层 CSS 的脆弱选择器

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

放弃固定 sleep，靠明确信号同步

waitForTimeout 会增加测试抖动。

优先等待网络完成、元素可见或路由稳定
使用 Playwright 自动等待和 web-first 断言

示例：

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

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

重复登录既慢又易出错。

用 storageState 或 fixtures 保存登录态
测试启动即加载登录状态，快速、稳定、可靠

落地： setup 脚本生成 auth.json，测试启动时加载 context.addCookies() 或 storageState。

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

UI 流程慢、脆弱。

数据准备和清理通过 API 完成
UI 只做端到端验证或展示验证

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

Mock 外部依赖，保留少量真实监控

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

用 HAR 回放或 route/stub 固定响应
只保留少量真实调用做 Canary 监控

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

视觉回归需精细化

视觉回归容易产生噪音：

动态区域（时间戳、广告位、头像）用 mask
核心组件设置严格阈值，非核心用宽松阈值

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

Trace / 视频按需开启

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

按测试或失败条件动态开启
CI 默认关闭 trace，但失败时自动启用

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

合理设置并发与 worker 数

并发并非越高越好。

先 profile 测试 suite，找出瓶颈（CPU、DB、网络）
worker 数量结合系统资源和 suite 特性调整

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

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

传统 Page Object 易膨胀难维护。

将复杂业务流程拆成可复用的步骤函数
测试代码读起来像业务故事

示例：

await auth.loginAs(user);
await cart.addItem(item);
await checkout.placeOrder();

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

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

统计每个 spec 失败率
超过阈值标注、隔离并创建修复任务

落地： CI 输出失败率报表，高失败率用 test.skip 或 test.fixme，并跟踪 issue。

报告标准化，关键信息一目了然

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

命名标准化，方便快速定位
CI artifact 暴露 HTML 报告和 trace

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

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