Playwright分片+Docker：我是如何把测试套件从47分钟压缩到8分钟的(下)

上期我们学习了分片+Docker的完整配置。接下来继续学习耗时测算逻辑、三个细节优化、成本测算与常见踩坑点。

分片前：

●单执行机、312 条测试、worker = 1

●总耗时：47 分钟

分片后：

●6 台执行机、每个分片约 52 条测试、每个分片 4 个 worker

●单分片耗时：7–9 分钟

●流水线总耗时（最慢分片 + 合并报告任务）：8 分 12 秒

83% 的提速来自两部分：

●水平扩容：从 1 台机器变成 6 台

●分片内并发：每个分片从 1 个 worker 变成 4 个

GitHub Actions 是按总计算分钟计费，不是按流水线墙钟时间。单机任务消耗 47 分钟计算量，6 分片方案大概是 6 × 8 = 48 分钟计算量，再加 2 分钟的合并任务。账单金额基本没差，但开发体验提升是天壤之别。

分片是最显眼的优化，但三个更小的调整，额外贡献了 25% 的提速。没做这些的话，我的分片大概要跑 10-11 分钟，而不是 8 分钟。

前面提过，但值得单独拿出来说。没开之前，我最大的测试文件有 38 条用例，整个文件会被分到同一个分片，导致那个分片要跑 12 分钟，拖慢整体进度。开启按用例分片后，所有分片的负载差控制在了 4% 以内。

工作流里的 actions/cache@v4 步骤会把 ~/.npm 目录缓存下来。命中缓存的情况下，npm ci 的耗时从 90 秒降到了 11 秒。6 个分片加起来，每次运行一共能省 6 × 79 秒 = 474 秒，差不多 8 分钟的总计算量。

我最开始每个分片都上传一份 HTML 报告，每份根据追踪日志和截图多少，大小在 45-120 MB 不等，6 份上传就要花 3 分钟。换成 blob 报告之后，每个分片的上传体积只有 8-15 MB，合并任务生成最终 HTML 只需要 40 秒。

我在公开仓库上跑，GitHub Actions 是免费的。如果是私有仓库，成本测算如下：

GitHub Actions 私有仓库定价：

●免费版：每月 2000 分钟

●团队版：每人每月 4 美元，含 3000 分钟，超出部分每分钟 0.008 美元

●企业版：每人每月 21 美元，含 50000 分钟，超出部分每分钟 0.008 美元

分片前我的工作流每次跑 47 分钟。团队繁忙的时候一天跑 20 次（代码推送 + PR 触发），一天就是 940 分钟，按每月 20 个工作日算就是 18800 分钟。团队版的免费额度用完后，超了 15800 分钟，每月额外支出 126.40 美元。

分片之后，每次运行的计算量大概是 50 分钟（6 分片 × 8 分钟 + 合并任务），每月消耗 20000 分钟，额外支出 136 美元。钱差不了多少，但开发效率的提升是天差地别。

用免费版的团队，每月 2000 分钟的额度大概能跑 40 次分片流水线。不够用的话，要么付费，要么换自建执行机。

GitHub 托管的执行机最高只有 2 核 CPU、7 GB 内存。如果你的应用很吃内存，或者每个分片需要 4 个以上的 worker，可以考虑用 AWS EC2 的 c6i.2xlarge 实例（8 核 CPU、16 GB 内存）自建，按需计费大概每小时 0.17 美元。

按一天 20 次运行、6 个分片、每个分片跑 8 分钟算，每天总计算量是 6 × 8 × 20 = 960 分钟，也就是 16 小时。日成本 2.72 美元，月成本大概 54 美元 —— 比 GitHub 私有仓库的超额计费便宜很多。

代价是要自己维护：执行机集群、弹性伸缩组、镜像更新都要管。我的建议是，先把 GitHub 托管执行机的分片、worker 优化都做透了，再考虑自建。不要上来就堆硬件解决配置问题。

在班加罗尔的产品创业圈里，开 20-40 万年薪招 SDET 的团队，基本都默认用 Playwright + GitHub Actions + Docker 这套技术栈。外包公司还在用自建虚拟机跑 Selenium Grid，但差距正在快速缩小。

2026 年我观察到的现状：

●A-D 轮产品创业公司：80% 用 GitHub Actions 或者 GitLab CI，Docker 是标配。测试套件超过 150 条之后，分片就是必做的优化。

●金融科技、医疗科技行业：这类公司要求 HTML 报告保留 90 天，每条失败用例都要有追踪日志。产物留存是合规要求，不是便利功能。

●转型自动化的外包公司：很多还在用 Jenkins + 本地代理机，迁移路径一般是 Jenkins → GitHub Actions → Docker，通常要 12-18 个月才能走完。

如果你 2026 年在面 SDET 岗位，会配置 Playwright 分片流水线是产品公司的入门要求。我做 SDET 职业辅导的时候，都会让候选人白板画出这套工作流架构。能画清楚容器、缓存层、分片矩阵的人，基本都能拿到 offer。

帮三个团队落地过这套方案之后，我总结了几个反复出现的典型问题。

●现象：一个分片 5 分钟跑完，另一个要跑 14 分钟

●原因：单个测试文件里用例太多，Playwright 把整个文件分给了一个分片

●解决：开启 fullyParallel: true，或者把大文件拆成更小的测试文件

●现象：某个分片失败了，但合并任务因为找不到报告直接崩溃

●原因：报告上传步骤用了 if: failure() 条件，而不是 if: ${{ !cancelled() }}。任务被取消或者超时的时候，不会上传产物

●解决：所有 blob 上传步骤都用 if: ${{ !cancelled() }}，同时矩阵配置开 fail-fast: false，避免一个分片挂了全组都停

●现象：报错 browserType.launch: Executable doesn't exist

●原因：Docker 镜像标签和 package.json 里的 Playwright 版本不匹配

●解决：两边都锁死同一个精确版本。我在 CI 里用脚本读取 package.json 动态拼接镜像标签：

●现象：随机报 browserType.launch: Protocol error，或者容器因为 OOM 被杀掉

●原因：4 个 worker × 3 个浏览器 × 重 JS 应用，超出了 ubuntu-latest 7 GB 的内存上限

●解决：把 worker 降到 2 个，或者增加分片数量（8-10 个），降低每个分片的并发量。也可以用 GitHub 更大规格的执行机（4 核 CPU、16 GB 内存），每分钟多加 0.032 美元。

●47 分钟的 Playwright 套件不是天经地义，只是个配置问题。

●分片就是把测试分发到多台机器并行。6 个分片把我的 47 分钟套件压到了 8 分钟。

●Docker 能消除环境差异。官方镜像 mcr.microsoft.com/playwright 预装了浏览器，每个任务能省 45-90 秒。

●fullyParallel: true 是分片负载均衡的关键，不开的话，单个大测试文件就会拖慢整条流水线。

●分片的计算成本和单机执行差不多，但给开发带来的效率提升是指数级的。

按每 50 条测试一个分片来起步就好。我 312 条测试用了 6 个分片。如果你的套件不到 100 条测试，分片的调度开销可能得不偿失；超过 500 条的话，可以考虑 10-12 个分片，或者上更多核心的自建执行机。

可以。GitLab CI 用 parallel: matrix，Azure Pipelines 用 strategy: matrix。--shard 参数是框架原生的，和 CI 系统无关，本文的思路适用于所有支持并行任务的 CI 平台。

可以，但每个系统要单独生成 blob 报告，因为截图、追踪路径可能不一样。最后还是用同一条 merge-reports 命令合并成一份 HTML 报告。

Playwright 的全局初始化是每个分片执行一次，不是整套套件执行一次。如果你的初始化成本很高（比如数据库灌数、环境准备），执行 6 次会增加额外开销。可以考虑单独起一个任务做初始化，把状态存成产物，每个分片再下载使用。

不是。你完全可以在裸 GitHub Actions 执行机上，用 npx playwright install --with-deps 装浏览器再分片。Docker 的价值是提升稳定性、节省安装时间。团队如果不熟悉 Docker，可以先从裸机分片开始，遇到版本漂移问题的时候再加上 Docker。