

**固定顺序全绿不等于用例干净，随机一跑，偷依赖和抢资源的当场现原形。**

>夜里十点四十，流水线一路绿，你合上电脑。第二天早上有个同事在本地随手跑了条命令，没跑全量，只从中间起——两条你谁也没碰过的用例突然挂了一条。奇怪的是：单跑它好，两条一起跑就红，把先后换个顺序又绿了。你盯着这份「本地红、CI 绿」的报告发懵，第一反应是环境不对、机器不稳，甚至怀疑网络。做自动化测试这些年，我们习惯把「谁先跑谁后跑」当成一件不用想的事，正是这个习惯，让一批套件在固定顺序下永远全绿。

Playwright 用例随机顺序这件事，v1.64 之后终于有了官方抓手。据 Playwright 官方 Release Notes（v1.64）的 Test runner 更新：跑测试时加 `--shuffle`，它会用随机顺序调度用例，官方给的示例输出就长这样——"Running 42 tests using 4 workers, shuffle seed 271828182"；关键在于 seed 是显式的，你传入同一个数字，它复现的是完全相同的执行次序，比如 `npx playwright test --shuffle 271828182`。随机一次、可复现一次，这两件看似矛盾的事凑齐，才让「顺序无关性」第一次能从口头纪律变成一个会红的门禁。

## 固定顺序全绿的套件里，藏着哪两类「假健康」？

先说清敌人。固定顺序下永远全绿，不代表用例干净，多半是它一直待在一个「刚好顺」的次序里。两类假健康最常见。

一类是**互相偷依赖**：A 用例在登录态、缓存或某个全局变量上偷偷替 B 做了铺垫，B 默认这些前提已经成立。只要 A 永远排在 B 前面，两个都绿；一旦随机把 B 提到 A 前面，B 因为缺了 A 留的后端状态当场挂。这种用例单独看谁都没毛病，问题出在它们之间那条没人写进文档的隐形依赖。官方示例里那 42 条用例用 4 个 worker 跑，随机打散后，正是这类「A 铺垫 B」的链条最容易先断。

另一类是**抢同一共享资源**：几条用例都去改同一个测试账号的全局设置、同一张表、同一个配置开关。固定顺序碰巧让它们错峰，看起来人畜无害；随机一跑，两个 worker 同时写同一处，谁最后写谁说了算，结果就是随机的红。这类和上一类的区别很关键：偷依赖是「顺序错就挂」，抢资源是「并发就挂」，治法完全不同——后面你会看到 shuffle 负责暴露前者，lock 负责兜住后者。

## 共享测试账号的全局设置，怎么让它别互相踩？

拿一个具体的 E2E 回归场景说：一组用例都围着同一个测试账号的「全局通知设置」做文章——有的开邮件通知，有的关短信通知，跑完还都断言「下单后收到/收不到某类通知」。这就是典型的抢共享资源。据 Playwright 官方 Release Notes（v1.64），`test.describe.configure()` 新增了 `lock` 选项：凡共享同一锁名的用例，跨文件、跨 worker、跨 project 都永不并发执行。给它一个锁名，等于告诉调度器「这几条排队走，别挤」。

```typescript
// user-settings.spec.ts —— 都改同一个测试账号的全局通知设置，加锁串行
import { test, expect } from '@playwright/test';

test.describe.configure({ mode: 'parallel' });

test.describe('共享测试账号 · 全局通知设置', () => {
  // 同一锁名：这组用例无论散落在几个文件、几个 worker，都不与彼此并发
  test.describe.configure({ lock: 'user-settings' });

  test('开启邮件通知后，下单应收到确认邮件', async ({ page, account }) => {
    await account.setNotification({ email: true, sms: false });
    await page.goto('/checkout');
    // ...下单
    await expect(account.lastNotificationChannel()).resolves.toBe('email');
  });

  test('关闭全部通知后，下单不应收到任何通知', async ({ page, account }) => {
    await account.setNotification({ email: false, sms: false });
    await page.goto('/checkout');
    // ...下单
    await expect(account.notificationCount()).resolves.toBe(0);
  });
});
```

为什么这么写：这两条用例都在写同一个账号的 `setNotification`，不加锁时它们一旦被 `--shuffle` 分到两个 worker 并发跑，后写的会覆盖先写的，断言读到的通知通道就成了掷骰子。`lock: 'user-settings'` 把「写这个账号设置」这件事拉回串行，随机顺序照样打散别的用例，但这一组永远排队。要提醒你的是：锁名是一个作用域约定，凡是碰这份共享资源的 describe 都得写同一个锁名，漏写一个，那个漏网的就是并发里的那颗雷。

## 只跑常用项目，抢环境的重活留到 CI 全跑，怎么配？

顺序无关性要变成每晚都跑的门禁，先得解决「随机跑一遍很贵」的问题——全量 shuffle 每晚跑所有 project，机器吃不消。据 Playwright 官方 Release Notes（v1.64），`testProject.default` 让一个项目留在配置里、但默认不跑：`npx playwright test` 只跑默认项目，`--project=firefox` 单跑某一个，`--project="*"` 才全跑。日常本地和轻量门禁靠默认项目，抢共享账号的那套重 E2E 就设成默认不跑，攒到 CI 上再全跑。

```typescript
// playwright.config.ts —— 把抢共享环境的重项目设成默认不跑，CI 上再全跑
export default defineConfig({
  projects: [
    { name: 'chromium', default: true },      // 日常 npx playwright test 只跑它
    { name: 'firefox', default: false },       // 留着，但默认不跑：--project=firefox 单点
    { name: 'safari', default: false },        // 同上
    { name: 'shared-account-e2e', default: false }, // 抢测试账号那套，只在 CI --project="*" 跑
  ],
});
```

这么分是因为「随机顺序门禁」要跑得够勤才有效，勤的前提是它够快。本地和每次 PR 只 shuffle 默认项目，秒级给结论；`shared-account-e2e` 这种带锁、耗时的，交给夜间 CI 用 `--project="*" --shuffle` 全量跑一遍。默认不跑不等于不测，是把贵的活儿挪到它该待的档期。

## 每晚 shuffle 一遍，失败就锁 seed 复现成最小反例

三件套拼起来，就是一条能把顺序无关性当门禁的流水线。核心思路一句话：每晚随机跑，红了别重跑碰运气——把那个 seed 记下来，用同一个 seed 复跑（v1.64 保证同 seed 同序），再逐步缩小到「非相邻不可」的最小两条，最后把它固化成一条顺序无关断言。

```bash
# shuffle-gate.sh —— CI 里每晚随机顺序跑一遍，红了锁 seed 复现到最小反例
SEED=$RANDOM                                  # 每晚一个新 seed（本文构造的门禁写法）
LOG=shuffle_gate.log

if ! npx playwright test --shuffle "$SEED"; then
  echo "order-sensitive failure @ seed=$SEED" >> "$LOG"
  # 同 seed 复跑：v1.64 下执行次序完全一致，红点必复现，不再靠运气
  npx playwright test --shuffle "$SEED" --grep-invert "flaky-quarantine"
  # 用 --grep 逐步收窄，把「谁和谁一对上就挂」的两句锁成最小反例
  echo "minimal-repro: fix order-independence before merge" >> "$LOG"
  exit 1                                     # 顺序无关性门禁：红就挡在这里
fi
echo "order-independent OK @ seed=$SEED" >> "$LOG"
```

为什么要 `exit 1`：门禁的价值全在「红会不会挡合并」上。如果 shuffle 失败只写日志不退出非零，它永远只是早晚看到的一条告警，没人真去修。让它挡在合并前，你才第一次拿到一个客观信号——「你的用例离开固定顺序就活不了」。这里的 `--grep`/`--grep-invert` 收窄、`SEED=$RANDOM` 生成方式都是本文构造的门禁流程示例，你接进自己流水线时按实际标签改。踩过的坑也直白：最早上这条门禁时有人嫌它烦，给随机失败直接加了整轮重试「重跑就绿」——那等于亲手把门禁废了，因为换 seed 重跑蒙绿，恰恰说明用例顺序敏感没修，只是被运气盖住了。

## 顺序敏感 / 资源竞争 / 真 flaky：三种红到底怎么分

shuffle 报红，别急着都叫「用例不稳定」，这三件事症状像、复现方式不同、治法也南辕北辙。

| 现象 | 典型症状 | 怎么复现 | 治法 |
|---|---|---|---|
| 顺序敏感（偷依赖） | 单跑都绿，换个先后就红；固定顺序永远全绿 | 记 seed 后同 seed 必现；缩小到相邻两句即挂 | 让每条用例自带前提、跑完清场，别蹭别人的铺垫 |
| 资源竞争（抢共享） | 并发就红、串行就好；红点在写同一处资源的用例上 | 提高 worker 数或 --shuffle 后并发时红 | 给共享资源用例挂同一 `lock` 锁名，退回串行 |
| 真 flaky | 同 seed 同序重跑，忽红忽绿 | 固定 seed 也复现不稳，和顺序无关 | 查等待/超时/外部依赖，进隔离队列，别混进门禁 |


![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/595398c92949b8c286deabb3b5b56ba9.png)



## 边界：shuffle 只负责暴露，不负责替你修

得把这层窗户纸捅破。`--shuffle` 是个诚实的暴露器，不是修复器——它把「谁在偷谁的依赖」揪出来，但修还是得你一条条让用例自带前提、跑完清场，随机不会替你写干净用例。同理，`lock` 也有代价：你锁得越粗，并行度掉得越狠，那组带锁用例退回串行，42 条 4 worker 的吞吐可能塌成一段长长的队。所以要权衡——把锁名收到「真正共享同一份资源」的最小范围，别图省事把整个 suite 塞进一把大锁，那等于花钱买了随机、又把并行卖回去。最后一句留个准头：pytest 侧早有成体系的随机顺序生态插件，思想是一样的；区别只是 Playwright 把 shuffle、seed 复现、跨文件跨 project 的 lock、default 项目挡在了官方 Test runner 里，你不用东拼插件就能把顺序无关性直接立成门禁。

## 结语：顺序无关不是洁癖，是能挡合并的一道红

固定顺序给你的绿灯里，混着多少「只是今天谁先跑了」的侥幸，你从来没数过。v1.64 把三件套摆上桌：`--shuffle` 负责暴露，同 seed 负责复现，`lock` 和 `default` 负责让这套东西跑得起、挡得住。把它接成每晚的门禁，你会发现有些套件第一次红的时候最难看，可那正是它欠了很久的账。

**能永远在固定顺序下全绿的套件，往往不是干净，只是侥幸没被人翻过牌——随机顺序要做的，就是把这张牌翻给门禁看。**

>本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。


夜里十点四十，流水线一路绿，你合上电脑。第二天早上有个同事在本地随手跑了条命令，没跑全量，只从中间起——两条你谁也没碰过的用例突然挂了一条。奇怪的是：单跑它好，两条一起跑就红，把先后换个顺序又绿了。你盯着这份「本地红、CI 绿」的报告发懵，第一反应是环境不对、机器不稳，甚至怀疑网络。做自动化测试这些年，我们习惯把「谁先跑谁后跑」当成一件不用想的事，正是这个习惯，让一批套件在固定顺序下永远全绿。

Playwright 用例随机顺序：--shuffle 把偷依赖的套件揪出来

人工智能

固定顺序全绿不等于用例干净，Playwright v1.64新增--shuffle随机顺序与同seed复现，配合lock锁名和default项目，让顺序无关性成为可挡合并的门禁，暴露偷依赖与资源竞争两类假健康问题。

软件测试

代码解释

短信

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Playwright 用例随机顺序：--shuffle 把偷依赖的套件揪出来-腾讯云开发者社区-腾讯云

Playwright 用例随机顺序：--shuffle 把偷依赖的套件揪出来

Playwright 用例随机顺序：--shuffle 把偷依赖的套件揪出来

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐