测试这件事很多时候卡脖子的不是用例写得慢而是跑得慢。一个全量回归集几百条用例串行跑下来几个小时CI队列排得人心浮气躁改成并行又经常遇到用例互相打架今天红几条明天绿几条排查半天发现是共享数据被串了。Playwright作为目前自动化测试的主力工具之一它的执行策略其实有很成熟的玩法顺序执行保稳定并行执行换时间分布式执行跨机器摊压力。这篇就把我在实际项目里折腾过的执行策略完整拆开讲包括底层逻辑、配置写法、适用场景和踩过的坑希望能让正在被测试耗时和稳定性折磨的人少走点弯路。我默认读这篇文章的人已经对Playwright的基本用法有概念比如会写用例、知道page对象、会用pytest或者Node Test Runner。如果没有这些基础也不影响只要你有自动化测试需求顺序、并行、分布式这三个概念以及它们背后的权衡逻辑在任何测试框架里都是相通的。1. 为什么要关心执行策略顺序执行是基础但效率瓶颈很明显1.1 顺序执行的默认行为与适用场景先用最朴素的方式说结论Playwright默认的执行方式就是顺序执行。不管你是用npx playwright test跑Node Test Runner还是用pytest集成跑Python用例默认状态下测试用例会按顺序一条条往下执行。这模拟的就是一个人坐在电脑前打开浏览器操作完一个场景再操作下一个场景的物理限制。顺序执行的价值在于确定性这一点怎么强调都不过分。用例之间如果存在状态依赖比如A用例创建了一笔订单B用例去查询这笔订单那A必须跑在B前面。这种强依赖场景下你搞并行就是自找麻烦。我在项目里专门划分了一批冒烟测试走的就是纯顺序执行登录、权限校验、核心链路走完全部串在一起。这条链路是给开发提交代码后快速验证用的跑得慢一点没关系能稳定发现问题才是第一位。顺序执行的代码形态也很简单。用pytest跑的时候什么额外配置都不用加默认逐个执行。用Playwright自带的test runner跑的时候配置文件里不设置fullyParallel默认也是串行。这种零配置特性让顺序执行成为了门槛最低、最不容易出错的起点。很多团队一开始做自动化测试就应该是从这个起点开始的。但顺序执行的问题是数学层面的N条用例每条平均耗时M秒总耗时就是N乘以M。当用例库膨胀到几百条甚至上千条的时候这个线性增长是完全不可持续的。我见过一个团队的上千条UI用例全量回归要跑6个多小时这已经不是效率问题了是致命问题——开发早上提交的代码下午下班前才拿到测试结果问题定位成本高得离谱。1.2 一条用例的时间都花在哪里要理解为什么执行策略值得花心思研究先把一条Playwright用例的时间消耗拆解开来。一条典型的UI用例时间大致分成四块启动浏览器实例Node进程拉起Chromium这一步基础耗时约1到2秒快不了页面加载、接口响应、DOM渲染网络和前端性能决定的等待时间用户操作过程中的真实等待比如点击后的交互反馈、模态框弹出、滚动加载每一步都需要等待稳定断言和清理包括截图、追踪文件生成、浏览器上下文销毁。第一和第四块是固定开销不管测试什么功能都跑不掉。真正可以压缩的是第二部分和第三部分但这是前端性能和产品交互层面的优化测试框架本身能做的有限。所以你会发现一个事实并行不是让你每条用例跑得更快而是让多条用例在同一段时间窗口内同时跑完把单位时间的吞吐量提上去。这和工厂流水线的逻辑一样——单个工人装配一台机器的时间没法缩短但多开几条流水线产量就上去了。这也就是为什么执行策略的优化空间巨大。假设一条用例平均耗时30秒800条用例串行就是6.6个小时。如果并行规模拉满到8个worker理论上可以压缩到50分钟左右这个差距是体验级的。但代价是什么代价是你会遇到各种顺序执行时根本不存在的问题测试数据冲突、端口资源抢占、数据库唯一约束爆炸、共享目录互相覆盖。工程上的一切优化都是取舍并行测试把时间问题转换成了隔离问题。2. 并行执行用资源换时间先搞清楚Playwright并行的底层机制2.1 并行不是多开几个浏览器这么简单很多从Selenium转过来的人有个误区以为Playwright并行就是多开几个浏览器窗口。实际上Playwright的并行粒度和隔离模型比Selenium时代的WebDriver方案严谨得多。这里要引入一个核心概念worker。在Playwright的测试执行体系里worker就是独立的工作进程。每个worker是操作系统层面的独立进程拥有独立的Python或Node运行时环境独立加载配置文件的最初状态然后在这个隔离环境里创建自己的浏览器实例。也就是说8个worker就是8个进程每个进程拉起自己的Chromium每个Chromium里跑自己的测试用例。它们之间在进程层面就是完全隔离的连全局变量都不共享。这才是并行的安全边界。更关键的是Playwright引入了浏览器上下文browser context这个概念。一个浏览器实例可以创建多个独立的context每个context相当于一个独立的隐身窗口会话——独立的Cookie、独立的localStorage、独立的缓存。这个隔离性比Selenium时代的多个driver实例之间互相污染要干净得多。所以用Playwright做并行测试只要你给每个测试用例创建独立的context它们之间几乎不存在浏览器层面的互相干扰。那并行数量怎么控制两条路径第一条是配置文件里设workers字段第二条是命令行传参--workers4。如果不显式设置Playwright的默认workers数量是CPU核心数的一半。这是一个很保守的默认值核心原因我在后面讲资源问题时细说。2.2 并行模式与代码示例在Playwright自带的test runner里并行的默认配置是这样的// playwright.config.ts import { defineConfig } from playwright/test; export default defineConfig({ workers: 4, // 并发worker数量按机器CPU核数和内存来定 fullyParallel: true, // 让同一个文件内的测试用例也并行执行 });fullyParallel这个参数值得单独讲。在旧版本Playwright中多个测试文件之间是可以并行的但同一个文件内的测试用例默认按顺序跑。这是从JUnit时代就传承下来的约定文件内共享一些前置状态串行更安全。但fullyParallel: true打破了这个限制让同一个文件内的用例也可以并行执行。前提是你得保证这些用例完全独立。用pytest跑的时候逻辑不一样因为pytest本身天然是串行的。Playwright官方只是把page等fixture注入给pytest执行调度权还是在pytest手里。所以pytest场景下的并行通常走pytest-xdist插件pytest tests/ -n auto-n auto意思是根据CPU核心数自动决定并行worker数。也可以手动指定-n 4就是4个并行worker。xdist的工作原理和Playwright的worker类似每个worker也是一个独立的Python进程跑一部分测试用例最后汇总结果。需要注意一点xdist的并行和Playwright自身的worker并行是两个层面的东西完全不冲突但在同一套测试工程里同时使用需要慎重容易造成资源叠加失控。2.3 并行时的三个经典翻车现场并行执行听起来美好但实际应用时我遇到过几种非常典型的翻车情况这里给后面的实践者提前排雷第一个是共享测试数据冲突。最常见的是注册类用例两条用例同时向数据库插入同一条用户记录如果有唯一索引必有一条失败。或者两条用例并行执行时都去修改同一个订单状态后读先写导致断言结果随机。这叫做测试间资源共享违背了并行隔离的前提。解决办法是每个用例准备独立的数据哪怕用时间戳或者UUID后缀生成随机用户名也比复用固定数据要可靠得多。第二个是静态资源互相覆盖。有一个项目里我把截图输出到同一个目录并行执行时两个worker同时往同一个文件名写截图结果截图文件互相覆盖严重时直接报文件占用错误。后来我把输出目录按照worker名或者测试用例名做了动态分离世界清净了。配置里outputDir可以写成动态格式比如基于测试标题生成子目录。第三个是资源耗尽导致浏览器崩溃。并行worker数量不是越多越好。每个Chromium实例大概要占用几百MB内存8个worker同时起就是好几个GB。我遇到过在只有8GB内存的CI机器上跑--workers8跑到一半机器内存耗尽worker被操作系统直接杀掉测试结果一片红。这个问题的本质是并行执行把瓶颈从CPU转移到了内存。保守做法是worker数不超过逻辑核心数的一半激进做法是看内存总量来定大致内存GB减2再除以每个浏览器占用的内存。资源维度默认策略优化建议独立进程隔离每个Worker独立进程保证测试数据在业务层面也互相独立worker数量CPU核心数的一半结合内存上限调整宁可少不可多同文件内用例串行未开fullyParallel确认无状态依赖后再开fullyParallel输出与临时文件全局目录按worker或用例动态切分目录3. 分布式测试把测试拆到多台机器Playwright的分片机制3.1 分布式和并行的本质区别并行和分布式这两个词经常被混着说但在测试执行领域它们有非常明确的界限。并行的前提是一台机器上有多个CPU核心多个worker在同一个操作系统里共享资源。而分布式的核心特征是跨机器测试用例被切分成若干片每一片交给一台独立的机器去跑机器之间只有结果汇总关系没有资源竞争。什么时候需要分布式最简单的判断标准单机并行已经压榨到极限但还是满足不了时间要求。比如800条用例每条的浏览器操作都重单机8个worker跑接近极限了还是要40分钟你希望压缩到10分钟那只能上4台机器每台跑200条可能12分钟就搞定。另一个场景是跨浏览器矩阵同一套用例要跑Chromium、Firefox、WebKit三个浏览器哪怕单机也支持串行或并行切换浏览器但为了缩短总体时间更好的方案是三台机器分别跑一种浏览器互不干扰。Playwright官方对分布式的实现方式非常干脆sharding分片。它不是自己发明一套分布式调度协议而是提供一个很简单的切分机制把全部测试用例按序号切分成N片每条命令只跑其中一片。这有点像是把一副扑克牌按顺序分成整数份每台机器拿其中一份去跑。只要每台机器拿到的片拼接起来正好是全部用例结果汇总起来就是完整报告。3.2 Playwright分片怎么用分片的命令行用法是在playwright test后面加--shard参数# 把测试分为4片运行第2片 npx playwright test --shard2/4这里的语法是分数形式2/4表示总分片数4当前跑第2片。在pytest体系里Playwright分片这个原生能力用不上但可以借助兼容方案比如pytest自带的--dist loadgroup配合自定义分组或者干脆用pytest-xdist按执行计划均匀切分。在CI里做分布式的标准做法是把分片命令放进矩阵任务配置。这里以最常用的GitHub Actions为例name: Playwright Tests on: [push] jobs: e2e-tests: strategy: matrix: shard: [1/4, 2/4, 3/4, 4/4] runs-on: ubuntu-latest steps: - name: 拉取代码 run: git checkout ${{ github.ref }} - name: 安装依赖 run: npm ci - name: 运行分片e2e测试 run: npx playwright test --shard${{ matrix.shard }}这段配置跑起来之后CI平台会自动拉起4个独立虚拟机每个虚拟机都完整安装一遍依赖和浏览器然后各自跑属于自己的那1/4用例。最后你从CI界面看到的是一次矩阵构建下的4个任务汇总整体效率和单机并行的差别在一倍以上。关于分片数量怎么定我的经验是要结合执行时间分布来考虑尽量不要盲目切太多片。因为Playwright的分片是顺序切分不是动态负载均衡。如果测试用例的执行时间方差特别大比如第3片里恰好包含了所有重用例而第1片全是轻量用例就会出现明显的长尾效应三台机器早就跑完了等最后一台等了20分钟。我的做法是先按历史执行记录把重用例打散分布在文件列表层面或者在用例层面按业务模块分目录让每片的时间相对均衡。3.3 分片之外的分布式补充方案除了官方分片还有两个思路值得提一下。一个是按标签切分这在用例数量大、业务模块清晰的团队里很好用。通过--grep login之类的tag标记把登录相关用例放一片订单相关用例放另一片每台机器跑一个业务域。这种切分的好处是业务语义清晰短板是容易切不均匀。另一个思路是用独立构建节点并行跑不同的测试套件目录。比如tests目录下有regression和functional两个子目录直接在CI里定义两个job分别跑不同目录。这其实是最早、最朴素的分布式不在同一套测试命令里做切分而是在CI层面按目录分发。它的优点是组织零成本每个人改自己的目录就行缺点是切分粒度太粗无法精细调整负载。分片也好目录分发也好本质上都是把大任务拆小、喂给多台机器。每种方式都有自己的适配场景。我自己用得最多的还是官方--shard因为它是官方设计跟测试报告、结果汇总系统配合完好不需要额外维护调度代码。4. 顺序、并行、分布式如何组合一套可落地的选择矩阵4.1 执行策略的选择矩阵策略无所谓绝对的好与坏只有合不合适的区别。我给执行策略选择列过一个简单的判断矩阵这里直接分享出来。判断的依据是三件事时间要求、稳定性要求、资源规模。场景推荐执行策略核心理由冒烟测试、核心链路验证顺序执行稳定性压倒一切结果可预期全量回归单机并行执行压缩时间提升吞吐量跨浏览器矩阵分布式分片执行每种浏览器独立机器互不拖累用例强依赖A前置给B串行片段内执行保依赖顺序避免竞态大规模用例库上千条分布式 并行组合先分片再片内并行双重加速组合用法才是生产环境里的常态。我见过的最好的方案是分级分层提交代码时跑冒烟测试纯顺序执行10分钟出结果合并代码前跑全量回归分配4台机器做分布式分片每台机器再开4到6个worker做片内并行跨浏览器兼容测试单独建一个任务只在晚上定时跑。4.2 用test.describe.configure把混跑策略写进代码组合策略的执行离不开代码层面的显式控制。Playwright给了一套很实用的API允许在同一个文件里对不同的测试组设置不同的执行模式。这个能力是用test.describe.configure实现的import { test, expect } from playwright/test; // 这个块里的用例强制串行适合有强依赖的流程 test.describe.configure({ mode: serial }); test.describe(用户下单全流程, () { test(创建订单, async ({ page }) { // ... }); test(支付订单, async ({ page }) { // ... }); }); // 这个块里的用例并行 test.describe.configure({ mode: parallel }); test.describe(独立功能点巡检, () { test(页面标题正确, async ({ page }) { // ... }); test(导航菜单可用, async ({ page }) { // ... }); });mode: serial表示这个分组内的用例按顺序执行并且如果其中一条失败后续用例会被跳过避免无意义的连锁失败。这个特性和实际场景很贴合下单失败后的支付用例本来就是无效的。mode: parallel则是明确要求组内用例并行。这套配置让执行策略的表达颗粒度从整个项目细化到了一个describe块灵活性一下子高了很多。pytest场景下没有describe.configure这个概念但pytest有自然的标记体系可以用。对需要串行的用例打标签结合-k或--dist loadscope参数在命令层控制执行方式。实际效果接近只是表达方式更偏向命令行而不是代码装饰器。4.3 执行策略之外的稳定化配套无论选什么执行策略稳定性都是底线。我这里把自己项目中验证过的四个配套手段列出来这些手段直接决定你的并行策略能不能落地。缺一个并行跑起来就是灾难。第一个是登录态管理。UI自动化里最常见的问题就是登录态。并行执行时每个worker都是独立进程登录操作会被重复执行多次既浪费时间又容易触发风控策略。我的方案是利用Playwright的storageState机制用全局setup先登录一次把登录后的上下文状态保存成一个JSON文件然后每个worker启动时直接加载这个文件跳过登录步骤。这个方案能把全量回归里的登录时间压缩到趋近于零。// playwright.config.ts import { defineConfig, devices } from playwright/test; export default defineConfig({ globalSetup: ./global-setup, // 执行一次全局前置登录并存储状态 use: { storageState: login-state.json, // 每个worker从文件加载登录态 }, });第二个是测试数据生命周期管理。并行执行时每个用例必须使用独立的测试数据。这意味着数据准备阶段要能动态生成唯一数据数据清理阶段要能精准清理自己产生的数据绝不能全局删除。我见过最惨的事故是并行跑回归时某条用例的teardown里执行了DELETE FROM orders把所有测试数据全清了其他正在跑的用例当场崩盘。数据隔离这件事必须在一开始设计用例时就刻进基因里。第三个是超时配置调优。并行环境下系统资源紧张页面加载时间会被拉长。如果不给每个等待操作设置合理的超时时间用例会因为偶发的慢启动而误报失败。Playwright里全局可以设一个expect超时单个操作又可以单独覆盖。我的一般经验是正常网络环境下expect超时设5秒CI机器上设10到15秒action超时默认是30秒基本不调。给等待留足缓冲但别设到无限长因为超时机制本来就是防挂死用的。第四个是结果可观测性。并行和分布式会让排查问题的复杂度直线上升。同一时刻有N条用例在跑你看到一条报错怎么知道它对应哪个请求、哪段网络日志、哪次DOM快照Playwright的trace功能这时候就是救命稻草。配置里开启trace保留export default defineConfig({ use: { trace: retain-on-failure, // 失败时保留追踪文件 }, });这样每条失败用例都会自动生成一个包含网络请求、页面快照、控制台日志和时间线的zip包点开就能回放整个执行过程。用这个配合并行跑报错排查效率能提升好几倍。4.4 分片大小与执行时间均衡的实操经验前面我说过playwright分片是顺序切分不是负载均衡所以执行时间的均衡性需要额外处理。处理手段有两个方向第一是合理安排测试文件目录结构。Playwright的分片粒度是测试文件级别的在fullyParallel开启前或测试用例级别的。如果文件目录按测试耗时分布不均衡分片结果就容易长尾。我的做法是在项目里把重用例单独放到tests/heavy/目录轻用例放到tests/light/分片时通过--grep参数把轻重分开跑。第二是利用CI上的历史测试时间统计反向调整。Playwright的HTML Report里自带每个文件的运行时长统计跑过几轮之后你就能识别出哪些文件是重量级的。对重量级文件可以在配置里用testMatch把它单独归类或者降低它的并行度。这些小调整属于锦上添花但对全量测试的总体耗时影响不小。5. 常见问题与排查技巧实录5.1 并行后大量超时先看资源再调配置并行执行最常见的现象就是以前串行时从不超时的用例并行后开始频繁超时。我排查过多次原因集中在三类。第一类是CPU过载worker数量开太多机器在进程调度上大量内耗每一条用例都被拖慢。这种情况直接降低workers数量就能缓解。第二类是内存不足系统开始用swap空间换页I/O阻塞导致页面加载超时这种情况要减少worker并同步调低浏览器并发数。第三类是网络IO瓶颈尤其是云上CI机器的共享带宽被占满所有worker都在抢同一个下载链路。排查方法不复杂一条命令就能看资源npx playwright test --workers2 --timeout120000先降并发跑一轮如果超时消失那基本确认是资源分配问题。再逐步提高worker数找到当前机器能承载的临界值。这个临界值就是你这个项目在这个CI环境下的稳定运行worker数。记住这个值写进配置里写死别交给Playwright自动判断自动判断永远是保守的。5.2 测试之间相互污染排查共享状态的三个入口并行跑出一堆诡异的随机失败时本质上就是有共享状态在作祟。排查共享状态我习惯按三个入口逐个检查第一个入口是浏览器上下文之外的内外部配置文件。比如用例里读了同一个临时文件、同一个环境变量、同一个本地端口。哪怕是读取操作如果另一个用例在并行中修改了它你读到的是被篡改后的值。对策是每个用例尽量只依赖自己创建的资源。第二个入口是数据库共享数据。比如两条用例用了同一个手机号注册后跑的用例被唯一索引拒绝。对策是数据生成全部走动态唯一化时间戳、UUID、随机数任选一种拼到数据末尾。这个习惯一旦养成能避开非常多的雷。第三个入口是全局前置脚本的副作用。globalSetup和全局fixture如果在其中修改了共享状态各worker启动时读到的初始状态就可能不一致。比如globalSetup里删除了某个缓存目录而另一个worker正好在用这个目录瞬间崩掉。对策是全局脚本只做追加和无害化操作避免删除和重置正在被使用的资源。5.3 调试并行问题的三个利器并行失败用例的调试比串行复杂一个维度因为复现难度大。我固定的调试三板斧如下针对性和效率都经过了几轮实战检验第一板斧是--debug模式单条跑。并行跑失败先切回串行用失败用例的标题拉起调试npx playwright test --debug -g 失败用例的标题关键词Playwright的debug模式会打开Inspector工具一步步回放执行过程看清楚到底哪个步骤和预期不符。这个模式天然是串行的不存在并行干扰。第二板斧是trace文件回放。配置里开启trace后每个失败用例的zip包里都有完整执行录像。在浏览器里打开trace文件可以逐帧查看页面截图、网络请求、控制台错误。这个功能比debug还要省事一点因为不需要重新跑一遍用例直接分析历史记录即可。第三板斧是定向观察网络请求。并行环境下很多失败本质上是接口响应与预期不符请求发到了旧环境、被限流、或者依赖的mock服务没起来。用page.on(request/response)在用例里打日志或者开启Playwright的代理抓包把黄金时段的网络交互记录下来对照分析。dial的困扰是串行时极少出现并行后偶发一旦出现基本就是环境层面的问题这个方向要有意识。6. 值得长期坚持的三个工程习惯执行策略的优化不是一个一次性动作而是一个持续迭代的过程。最后分享三个我觉得值得长期坚持的习惯。第一个习惯是每次都看一眼测试耗时分布。HTML Report里的按文件耗时排名值得每次跑完都浏览一下。哪个文件越来越胖哪类操作从秒级拖成分钟级都在这些数字里暴露无遗。发现异常就去处理别等到全量耗时突破心理预期才回头补救。我很多执行方案的调整都源于对这种耗时分布的持续观察。第二个习惯是给关键链路打执行标记。不是所有测试场景都要追求并行极致。我在项目里会明确区分三条执行链路提交时快速验证、合并主分支时全量回归、发布前跨浏览器矩阵巡检。不同链路用不同的执行策略而不是一套配置跑到底。这套思路本质上就是把策略配置工程化而不是临时手工改参数。第三个习惯是定期做垃圾清理。给存储状态文件做版本化、定期清理历史trace文件、删除已经完全无用的测试产物。并行和分布式执行会加速产生这些碎片文件。不清理的话时间一长磁盘被占满CI机器的性能会断崖式下降。技术上不复杂但容易忘记值得刻意维护。我在实际项目里最终沉淀下来的执行方案是冒烟测试串行保稳定性全量回归按业务域分片、每台片内再开4个worker并行跨浏览器矩阵独立分配机器跑。这个组合在800条用例规模上把单次回归耗时从6个小时压缩到了25分钟以内关键是失败率没有因此上升。过程中踩过的大多数坑写在了前面几个章节里希望读到这里的同行能绕开它们。如果你正在为测试耗时和稳定性两头烦从串行起步按章节顺序逐层加码执行策略大概率能找到属于你自己项目的舒适区。