Playwright不稳定的原因揭晓：经历12个坑后的深刻领悟！

每到周五傍晚，最理想的状态莫过于看到测试报告全绿、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 规范。

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.skip 或 test.fixme，并跟踪 issue。

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

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

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

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

写在后面

Playwright 不只是工具，而是一套工程化方法：

• 按业务风险划分用例
• 测试数据可控、环境稳定
• 定位器稳健、并发合理
• Trace、截图、网络请求标准化管理

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