如果你的自动化测试跑到第30分钟还没出结果大概率不是用例写得不好而是执行策略没搭对。我见过太多项目用例设计得挺用心却在“怎么把这一千多条用例跑完”这件事上反复卡壳——要么一条条慢吞吞地串行跑要么开了并行之后天天冒偶发失败要么把用例拆到好几台机器上之后发现报告全丢了。Playwright测试执行策略绕来绕去就是顺序、并行、分布式这三件事。把这三件事吃透自动化测试的吞吐量至少能翻两三倍而且踩坑的概率会直线下降。这篇文章就围绕这三个关键词展开适合那些正在维护Playwright用例集、想把回归时间降下来、准备接入CI稳定执行的团队。先说结论顺序执行是兜底方案并行执行是默认提速手段分布式执行是规模化之后的扩容方向。三者不是替代关系而是根据用例特性、环境资源和团队阶段动态组合的关系。下面我按实际落地的顺序来拆解从原理到配置再到问题排查尽可能把执行策略这层窗户纸捅破。1. 三种执行模式的本质区别与选型思路1.1 为什么三种模式各有各的适用场景顺序执行就是一条用例跑完再跑下一条整个测试过程只有一个执行流。这种模式的优点是执行上下文完全可预测前面的用例如果创建了订单后面的用例可以直接去查询这个订单前面的用例如果登录了系统后面的用例可以继续沿用登录态。缺点是速度慢一千条用例哪怕每条只要十秒也要将近三个小时。所以在小规模用例集、强依赖业务链路、以及调试定位问题的阶段顺序执行是主力。并行执行核心是“隔离换速度”。多个worker进程同时跑不同的测试文件互不干扰整体耗时由最慢的那条用例和最少的那一批worker共同决定。举个直观的数字一台8核机器把100条独立用例分到8个进程里跑理想耗时是串行的八分之一。当然现实世界里不可能那么理想因为每条用例耗时不一样还有数据隔离、资源抢占、报告汇总等额外开销。但就算打五折速度提升也很可观。分布式执行就是把用例分片到多台机器上。当单台机器的CPU和内存已经撑不住并发规模或者回归时间被单机硬件锁死到临界点就需要横向扩容。分片方式很简单每台机器领走一部分用例跑完再把结果汇总。分布式执行适合用例规模上千甚至上万、且已经做好数据隔离的成熟项目它的成本也是最高的环境同步、结果收集、资源监控都得跟上。1.2 选型背后的技术权衡很多人以为执行策略就是“越快越好”这其实是个误区。速度只是结果真正决定策略的是三件事用例之间的依赖强度、测试数据的隔离程度、以及机器资源的规模上限。如果用例之间强依赖并行就会变成灾难。比如一个用例依赖上一个用例在界面上创建的记录那并行之后必然是随机失败。如果测试数据没有隔离好多进程同时写同一张表、操作同一个账号各种脏数据就会互相污染。反过来说如果每一条用例都可以独立生成自己的数据、独立准备前置状态那么并行几乎没有什么心理负担。在实际项目里我建议先用“依赖分析”来分桶强依赖链路放进串行组弱依赖的独立用例放进并行组两组用不同的配置跑。这比一刀切全并行要稳得多。资源规模方面单机8核16GB以下用并行就够了一旦并发打到几十个worker内存先爆这种情况才需要看分布式。1.3 一张表理清三种模式的核心差异维度顺序执行并行执行分布式执行执行单元单进程单线程多进程多文件多机多分片速度最慢较快最快隔离要求低可共享状态中需数据隔离高需环境一致调试难度低问题复现容易中需区分环境干扰高需跨机排查适用用例量级百级以内百到千级千级以上成本低中高这张表是我在多个项目里反复验证过的分类方式。选型的时候不用纠结“高端方案”先对号入座你的用例数量、隔离状态和机器资源决定了你现阶段该用哪一招。2. 顺序执行落地串行模式与状态管理2.1 Playwright的串行执行配置与依赖用例在Playwright的JS/TS版本里串行控制最直接的方式是test.describe.serial。我把一段常见的代码贴出来import { test, expect } from playwright/test; test.describe.serial(订单全流程, () { test(创建订单, async ({ page }) { await page.goto(/orders/new); // 填写表单、提交 await expect(page.locator(.success)).toBeVisible(); }); test(支付订单, async ({ page }) { // 依赖上一个用例创建的订单数据 await page.goto(/orders/list); await page.locator(.pay-btn).first().click(); await expect(page.locator(.paid)).toBeVisible(); }); });关键点在于test.describe.serial块内部的测试默认按顺序执行而且如果前一个用例失败后面没跑完的用例会被直接标记为跳过不会继续执行。这非常符合业务链路的逻辑——支付关联的订单都不存在了后面去查订单详情没有任何意义。如果你用的是Python生态pytest-playwright配合pytest-order插件可以做到类似效果用装饰器指定顺序import pytest pytest.mark.order(1) def test_create_order(page): page.goto(/orders/new) # ... pytest.mark.order(2) def test_pay_order(page): # ...Python方案的优点是pytest生态丰富缺点是没有原生串行块那么直观。所以我的建议是如果团队主语言是TypeScript直接用test.describe.serial如果是Python老老实实用插件并且把依赖链写清楚。2.2 顺序执行中的状态处理与实践细节顺序执行最大的“福利”是可以共享状态但你得管好状态否则串行比并行更容易踩雷。最常见的做法是全局登录一次保存storageState后续用例直接复用登录态。在playwright.config.ts里这样配置import { defineConfig } from playwright/test; export default defineConfig({ globalSetup: ./global-setup, use: { storageState: ./storageState.json, }, });global-setup.ts里负责启动浏览器、登录、把cookie和localStorage写入storageState.json。这样所有用例启动时都会自动加载登录态顺序执行时尤其省时间。但这里有个很多人忽略的坑storageState里不仅包含登录态还包含一些动态数据比如上次访问的页面路径、临时token。如果某个用例把localStorage里的字段改乱了后面的用例就会继承这个脏状态。我的建议是除了登录必需的字段其余都别依赖storageState保存用例内部需要什么就自己构造什么。另外顺序执行下的数据库记录清理也不能偷懒。前面的用例在数据库里插了一条记录后面的用例如果没用到它最好在用例结束后自行清理否则跑完全套测试库里全是垃圾数据下一次回归很可能因为数据量膨胀而变慢甚至在查询接口里出现超时。2.3 什么时候必须退回到顺序执行我见过不少团队为了追求速度强开并行结果每轮跑完都有五六条偶发失败排查半天发现是数据冲突。这种时候就别硬扛了退回顺序执行先把用例本身的正确性焊死。必须用顺序执行的典型场景有三个。一是强业务链路比如订单创建到支付再到退款每一步都依赖前一步产生的数据强拆并行只会自找麻烦。二是共享互斥资源比如被测系统只允许同一账号单点登录两个worker用同一个账号同时操作后登录的会把先登录的踢下线。三是需要精确回放的复杂流程比如一笔支付请求要校验流水号唯一这种场景下并发会导致不可控的竞态。还有一个实用技巧排查问题阶段也建议临时用workers1跑一遍。命令是npx playwright test --workers1。一旦你确认在串行模式下用例全部通过再切回并行模式就能快速定位问题到底是用例自身缺陷还是并行环境下引入的干扰。3. 并行执行提速worker机制与用例隔离3.1 并行方式的两种打开方式Playwright的并行能力来自worker进程。一个worker就是一个独立进程跑一组测试文件拥有自己的浏览器实例。默认情况下worker数量是CPU核心数的一半左右但你可以在配置文件里显式指定export default defineConfig({ workers: 4, // 或者 fullyParallel: true让单个文件内的用例也能被打散到多个worker上并行跑 });命令行方式是npx playwright test --workers4实测下来命令行优先级更高。另一个参数fullyParallel很多人容易搞混我解释一下默认情况下多个文件之间是并行的但同一个文件内部的用例还是按顺序跑如果你把fullyParallel打开文件内部那些彼此独立的用例也会被多个worker并行执行。这个开关适合那些把很多用例堆在同一个文件里的项目。Python生态里对应的方案是pytest-xdist跑的时候加上-n参数pytest --base-urlhttp://localhost:8080 -n 4-n auto会根据CPU核心数自动决定进程数。pytest-xdis的另一个好处是--distloadscope它会把同一个文件里的用例尽量分配给同一个worker避免文件和文件之间的用例切来切去导致fixture重复执行。3.2 worker数量到底怎么定才合理关于worker数量网上说法五花八门有说两倍核心数的有说等于核心数的。我的实测经验是不要死记倍数要看两个硬指标——内存和IO。一个Chromium渲染进程大概需要300到500MB内存这还没算页面本身的资源占用。如果你在8核16GB的机器上开16个worker大概率跑到一半出现资源耗尽整机卡死。稳妥起见我一般先把worker数设为核心数然后跑一轮监控内存峰值。如果内存峰值稳定在物理内存的60%以下再逐步往上加一旦出现内存抖动或者页面加载时间明显变长就降下来。其次要看被测应用的承载能力。有些后端服务在本地开发模式下扛不住十几个并发请求接口直接超时。这种情况属于“能力错配”你再怎么调worker数都没用。我的做法是给测试环境配一个最简单的压测探测先用4个worker跑小样本用例集观察接口P95响应时间。如果P95比起串行时翻倍了多半是服务端瓶颈worker数开得越大反而越慢。最后提一个参数--max-failures。并行模式下如果失败用例太多全跑完要花很多时间可以设置失败次数上限比如失败超过10条就提前终止。这个参数在CI里特别有用能省掉大量无谓的执行时间。3.3 用例隔离并行测试的地基工程我可以负责任地说并行测试里90%的偶发失败都是隔离没做好。所谓隔离不光是Playwright给每个测试创建独立BrowserContext这么简单更重要的是业务层面的数据隔离和状态隔离。数据隔离最基础的要求用例里不要写死手机号、用户名、订单号。我通常用一个生成器每次跑测试都生成随机且唯一的标识function randomUser() { const suffix Date.now() Math.floor(Math.random() * 10000); return { phone: 138${suffix.toString().slice(-8)}, email: test${suffix}example.com, name: tester_${suffix}, }; }这么做不是因为“随机性好”而是因为并行的两个worker可能在同一个毫秒级窗口内注册同一个写死的手机号数据库唯一索引直接冲突。用时间戳随机数环境前缀三件套基本可以避开冲突。状态隔离方面最常见的坑是localStorage和cookie。虽然每个测试有独立的BrowserContext但如果你在代码里手动写了一个全局session管理器把token放在模块变量里那么这个token会跨用例共享。并行跑的时候后创建的token可能覆盖先创建的token前面的用例瞬间变成未登录状态。正确的做法是token跟着fixture走每个测试自己获取或生成而不是塞进公共变量。3.4 并行场景下的共享数据与fixture设计并行带来的另一个挑战是全局初始化操作会重复执行。比如你有一个“准备测试数据”的步骤串行时跑一次就够并行时如果有4个worker它会跑4次。如果这个操作是幂等的比如创建一批只读配置那还好如果它会往数据库里插入记录很可能就重复插了。Playwright的fixture体系里有个关键概念叫scope。默认scope是test的意思是每个测试都会重新创建如果你希望某个fixture在每个worker里只创建一次可以设置scope: workerconst test base.extend({ // 每个worker只登录一次并共享storageState workerToken: [async ({}, use) { const token await loginAndGetToken(); await use(token); }, { scope: worker }], });这个设计的妙处在于它既保持了并发隔离的安全性又避免了重复登录带来的资源浪费。我强烈建议把所有高成本的准备动作登录、初始化配置、生成基础数据做成worker级fixture把低成本的个性化数据做成test级fixture。还有一个容易被忽略的点并行模式下测试之间不要共享文件。比如两个worker同时往同一个临时文件里写日志或者往同一个截图目录里写同名文件直接互相覆盖。正确的做法是每个测试用自己的输出目录或者让Playwright自动管理test-results目录不要在用例代码里手动拼接固定路径。4. 从单机到集群分布式测试的工程实现4.1 Playwright的sharding分片机制当单台机器并行到极限仍然不够快时就该上分布式了。Playwright原生支持sharding用--shard参数把整套用例按比例切成几份npx playwright test --shard1/4 npx playwright test --shard2/4 npx playwright test --shard3/4 npx playwright test --shard4/4这里的1/4表示四份里的第一份。四台机器各跑一条命令整体回归时间理论上可以压缩到原来的四分之一。shard参数在CI的矩阵策略里特别好用后面我会讲到具体配置。有一点要注意Playwright的sharding是以测试文件为最小分配单位。也就是说一个文件会被完整分配到某个shard里不会把一个文件内部的用例切开分到不同机器。这个特性决定了用例文件的粒度设计很重要如果你把所有用例堆在一个大文件里那么这个文件只会落在某一台机器上其他机器闲得要死这一台却跑到天荒地老。4.2 基于CI的分布式执行方案分布式测试落地最普遍的地方就是CI。以GitHub Actions为例用matrix矩阵来天然生成多个并行任务name: playwright-tests on: schedule: - cron: 0 2 * * * jobs: e2e: runs-on: ubuntu-latest strategy: matrix: shard: [1, 2, 3, 4] steps: - uses: actions/checkoutv4 - uses: actions/setup-nodev4 with: node-version: 20 - run: npm ci - run: npx playwright install --with-deps - run: npx playwright test --shard${{ matrix.shard }}/4 - uses: actions/upload-artifactv4 if: always() with: name: test-results-${{ matrix.shard }} path: test-results/这个配置的价值在于四台独立的runner同时开工每一台只跑四分之一用例。无论你是自己搭的Jenkins集群还是云上弹性节点思路都是同理的——用多个runner承担同一套回归任务。Jenkins里可以配置多个并行stage每个stage执行不同的shard命令再把产物统一归档。关键点是每个分片必须独立携带自己的报告和trace否则最后查问题的时候素材全丢了。4.3 分布式下的报告汇总与artifact收集分布式执行最容易被低估的工作是报告合并。一开始我的做法是每台机器各自生成一份HTML报告测试结束之后人工打开四份报告分别看哪些用例挂了。这样不但低效而且用例名一多根本分不清哪条跑在哪台机器上。Playwright后来提供了Blob Report的合并方案专门解决这个问题。每个分片机器生成blob格式的中间报告最后用merge-reports统一合并成一份HTML报告npx playwright test --shard1/4 --reporterblob npx playwright test --shard2/4 --reporterblob把各分片机器输出的blob-report目录全部收集到一起后再执行npx playwright merge-reports --reporter html ./blob-report合并出来的完整报告包含所有分片的测试结果还有一个聚合后的时间线排查失败用例时不用来回切换工具。我这个流程已经稳定用了大半年每次分布式的回归结果都在庄重报告里一目了然。强烈建议大家不用零散HTML直接上blob合并。4.4 分布式下的环境一致性与数据互斥问题分布式测试最头疼的问题不是“跑不快”而是“同一套代码在不同机器上结果不一样”。这个问题多半出在环境一致性上A机器的Node版本是20B机器是22A机器的浏览器缓存了旧版本资源B机器是全新环境。踩过几次坑之后我现在要求分布式集群里所有运行镜像统一用Docker容器预装好Node、Playwright、浏览器三件套并且固定版本号。数据互斥是另一个大坑。四台机器同时跑如果都去操作同一个账号或者同一批数据必然产生冲突。我的建议是给不同分片分配不同的数据域比如shard 1用test_data_shard1前缀的账号shard 2用test_data_shard2前缀的账号以此类推。测试数据生成器里加上shard标识参数从源头隔离。还有一个容易被忽略的点每台机器上的“当前时间”可能不一致。如果用例里有跟时间相关的断言比如校验创建时间小于当前时间那不同机器之间的时钟偏移会导致偶发失败。我的做法是在分布式执行里统一不用真实时间做断言改用接口返回的时间字段相对值或者用mock时钟固定时间。5. 常见问题与排查方法实录5.1 问题速查表问题现象排查方向解决方案并行后偶发失败多个worker冲突随机唯一数据 独立BrowserContext接口频繁超时worker数过多调低workers观察服务端P95耗时本地通过CI挂环境变量或依赖版本不一致统一镜像与Node版本固定依赖锁文件多台机器结果不一致数据环境不同分片分配独立数据域重建预置环境顺序用例失败连带后续失败依赖链未处理用test.describe.serial或标记跳过报告只显示部分结果分片报告未合并用blob report merge-reports登录态在并行下失效共享账号互踢每个worker独立账号或token化单个文件时长特别长shard粒度卡文件拆分大文件让分片粒度更细这张表基本涵盖了我接手过的项目里80%的执行策略问题。看到现象先别急着改代码按表格里的排查方向找根因大多数时候是环境或设计问题不是Playwright本身的问题。5.2 我在实操中踩过的一些坑坑一随机数据生成器没加环境前缀。早期我们的测试数据生成器只用了时间戳加随机数本地和CI同时跑的时候两个环境可能生成同一个手机号。数据库唯一索引冲突直接导致“近10%用例无规律失败”排查了两天才定位到是数据生成撞车。后来给生成器的前缀加上环境名local、staging、prod冲突问题彻底消失。坑二并行全开之后忘了管测试账号。有一段时间我们的UI自动化全部用同一个管理员账号登录workers从2提到6以后频繁出现“登录后马上被登出”页面报401但串行跑得好好的。原因是多个worker同时用同一账号登录最新登录把之前的session全部挤掉。后来改成按worker数量准备账号池每个worker持有独立账号问题当场消失。坑三仓库里所有用例写在一个大文件里。有个同事习惯把全部测试堆在一个spec文件里本地串行跑没事上CI做4分片之后就发现——3台机器十几秒就结束1台机器跑了半小时。根因就是shard的最小分配单位是文件一个巨型文件只能落在同一台机器上。后来做了文件级拆分按业务模块分成8个文件分片均衡多了。坑四分布式下trace/image没有及时上传。我们第一次搭分布式时只把最终HTML报告传到了制品库各个分片机器上的trace和视频全丢了。遇到失败用例根本没法排查。后来增加了upload-artifact步骤把test-results目录整体上传每个分片独立命名排查效率立竿见影。坑五环境变量在不同机器上不一致。有个阶段的CI配置里BASE_URL在部分runner上没有设置导致分片跑到登录后重定向到localhost。后来我把所有环境变量都写进CI的env统一配置并且在测试启动前加一层配置自检缺失变量直接报错而不是带病执行。5.3 排查偶发失败的一套组合拳偶发失败是执行策略项目里最常见的“慢性病”特征是跑十次有九次通过就偶尔挂一两条。我的排查路径有一套固定的组合拳分享给大家。第一步固定参数复现。先用--workers1串行跑挂的用例如果不再出现基本可以判断是并行干扰如果串行还挂那是用例自身的bug。第二步看trace。Playwright会在失败时自动录制trace直接在HTML报告里打开看是网络请求导致的超时还是页面元素定位异常。trace里还包含了API请求和响应比截图信息量大得多。第三步看浏览器控制台和网络日志。把page.on(console)和page.on(requestfailed)在fixture里挂上把输出写到测试报告里。偶发失败很多时候在界面上看不出来但控制台里的js异常会提前暴露问题。第四步做数据痕迹比对。把失败用例的输入数据和通过时的输入数据放在一起对比重点看有没有相同的手机号、订单号、时间戳。如果发现有“写死痕迹”直接改成随机数据生成器。这套组合拳在大多数场景下10分钟内能定位问题根因。真正要避免的是一遇到偶发失败就“重跑一遍试试”不加分析那样问题永远隐藏在黑暗里。最后聊点实操后的真心话。执行策略这件事我在不同规模的项目里反复调整过多次最深的体会是顺序、并行、分布式不是一个由低到高的进阶菜单而是一套组合工具。小项目在串行下能稳定跑完就没有必要为了“看起来高级”硬上并行中等规模先把并行做好让每条用例真的可以独立运行比盲目追求worker数量更有价值只有用例规模确实大到单机资源捉襟见肘再引入分布式并花力气把环境一致性、报告合并、数据域隔离这三件套彻底打通。我个人在实际操作中还有一个习惯每次调整执行策略后会留存一轮完整的执行日志作为基线包含总耗时、失败率、每个分片耗时分布。下一轮改动之后对比基线数据效果好坏一眼就能看出来。如果你正在为慢吞吞的回归发愁不用着急先从串行稳定性做起再逐步放开并行最后再看分布式——这条路我走过很多遍每一步的收益都比想象中扎实。