Day 23 - Parallelism, Retries, and Sharding

今日目标

理解 Playwright 并行执行模型。
掌握 workers、retries、fullyParallel、shard。

学习时间安排（60–120 分钟）

时间	模块	做什么
0-20 分钟	核心概念与词汇	读概念表，区分 workers 和 shard 的适用场景。
20-45 分钟	官方文档阅读	读 Parallelism and sharding 文档和 retries 部分。
45-75 分钟	实操练习	对比 workers=1 和 workers=4 的执行时间和失败情况。
75-105 分钟	示例代码改写	配置 CI 并行策略并验证 shard 拆分。
105-120 分钟	复盘与作业	完成 flaky 风险清单，完成今日问题。

核心概念与词汇

English	中文	场景用法
workers	并行工作进程	Use it when you control how many test files run in parallel.
`fullyParallel`	全量并行	Use it when tests within one file also run in parallel.
retries	重试	Use it when failed tests rerun automatically, usually in CI.
shard	分片	Use it when you split a large suite across multiple CI jobs.
parallelism	并行度	Use it when you describe how many tests run at the same time.
test isolation	测试隔离	Use it when each test has its own context so parallel runs don't conflict.
flaky test	不稳定测试	Use it when a test passes and fails intermittently without code changes.
CI matrix	CI 矩阵	Use it when each shard or browser runs in its own job.
resource contention	资源争用	Use it when parallel tests fight over shared data or services.
throughput	吞吐量	Use it when you measure how many tests complete per minute.

学习材料

必读：[Parallelism and sharding](https://playwright.dev/docs/test-parallel)
必读：[Retries](https://playwright.dev/docs/test-retries)
选读：[Serial mode](https://playwright.dev/docs/test-parallel#serial-mode)（了解什么时候必须串行）

重点理解

常见配置：

export default defineConfig({
  fullyParallel: true,
  workers: process.env.CI ? 2 : undefined,
  retries: process.env.CI ? 2 : 0,
});

Shard 示例：

npx playwright test --shard=1/3
npx playwright test --shard=2/3
npx playwright test --shard=3/3

重点：

并行能提高速度。
测试隔离是并行的前提。
重试不是解决 flaky 的根本方法。
Shard 适合大规模测试集拆分到多个 CI job。

实操步骤

运行：

npx playwright test --workers=1
npx playwright test --workers=4

比较执行时间和失败情况。

示例代码

# GitHub Actions 中的 shard 矩阵
strategy:
  fail-fast: false
  matrix:
    shard: [1, 2, 3]
steps:
  - name: Run Playwright tests
    run: npx playwright test --shard=${{ matrix.shard }}/${{ strategy.job-total }}

常见坑

测试间共享数据/账号，开并行后互相干扰，比串行时更 flaky。
用 retries 掩盖真实问题，flaky 测试被“重试通过”粉饰。
workers 开太大，机器资源耗尽，执行时间反而变长。
shard 拆了但没配 CI 矩阵，三个 shard 命令串行跑完。
本地 workers 调成 1 排查问题，忘记还原配置。

今日产出

一份并行执行对比记录。
一份 flaky 风险清单。

今日问题

worker 是什么？
并行执行为什么要求测试相互独立？
retries 应该用于什么场景？
重试会不会掩盖问题？
shard 和 workers 有什么区别？

复盘要点

并行是放大器：测试独立就快得飞起，测试耦合就暴露所有隐藏 bug。
workers 解决“一台机器上快”，shard 解决“很多台机器上更快”。
retries 是护栏不是解药：它吸收偶发抖动，但 flaky 必须进修复队列。

AI 时代扩展：AI 辅助 Playwright 测试

新增概念

English	中文
flaky detection	不稳定检测
parallel safety	并行安全
resource modeling	资源建模

适用场景

让 AI 审查测试是否存在共享数据、共享账号等并行安全隐患，或者分析一批 flaky 测试的失败日志找出共同模式。

可复用表达 / 提示词

请审查我的测试集，找出并行执行时可能互相干扰的地方（共享数据、共享账号、固定端口等）。
以下是 5 条 flaky 测试的失败日志，请找出共同失败模式并判断根因方向。

追问加练

AI 说“把 retries 调到 5 就能解决 flaky”，你怎么回应？
并行导致的失败有哪些典型特征？
你如何设计实验验证 AI 的 flaky 根因判断？

今日作业

完成 workers=1 与 workers=4 的对比记录（时间、失败数、结论）。
完成 flaky 风险清单：至少 5 条，每条附触发条件。
让 AI 审查你的测试集的并行安全，修正发现的问题。

自检清单

我能解释 workers、fullyParallel、retries、shard 四个概念。
我的测试在并行下也能独立通过。
我知道 retries 应该只在 CI 开启。
我对比过不同 workers 下的执行时间。
明天学习 CI/CD 时，我能把 shard 和产物上传组合起来。