Playwright还是Cypress：单测更快，CI为何可能更慢

如果团队希望在本机直接并行运行测试，并自行控制CI分片，Playwright Test是更合适的起点。如果团队已有Cypress Cloud录制流程，主要难题是让多台CI机器分担耗时不一的spec，Cypress Cloud的动态调度值得重点比较。单个端到端用例跑得快，并不能直接推出整条CI更快；流水线要等最后一个任务结束。

两者解决的是不同层面的排队问题：本机有多少worker能同时工作，CI机器之间怎样分配文件，以及增加浏览器后要再执行多少任务。公开研究可以说明特定应用中用例的执行表现，却不能替团队算出自己的机器等待时间。下面用同一组明确标为假设的spec，分别计算单机、双CI机器和多浏览器流水线。

单机速度：用例耗时之外，还有worker

Playwright的并行说明写明，Playwright Test默认让不同测试文件在独立worker进程中并行，同一文件中的测试默认顺序执行；worker拥有隔离的BrowserContext。团队可以限制worker数量，也可以为文件内的独立测试启用并行。因而，同一套用例拆成多份文件，和全部放进一份长文件，可能得到截然不同的本机完成时间。

一项发表于2025年的Angular应用端到端测试研究在无头浏览器环境下测量五类场景，每类场景在Chrome、Firefox和WebKit中重复运行；Playwright在所测五类场景的平均执行时间均低于Cypress，内存占用也更低，跨浏览器耗时较一致。研究测的是该应用、测试实现和实验设备上的执行过程，没有计入CI任务排队、多机器调度或结果上传。其结果适合说明单项测试可能存在速度差异，不能直接充当完整流水线的排名。

worker也不是免费的加速倍数。并发浏览器会争用CPU和内存，测试还可能同时等待同一个应用服务或测试数据库。若一台机器资源紧张，继续增加worker可能使每份文件运行更久；若测试大多集中在少数长文件，默认的文件级并行也没有足够任务可分。评价本机反馈速度时，文件边界、worker上限和应用依赖，与框架自身的用例耗时一样重要。

跨机器：固定分片与动态领任务

Playwright Test可用--shard把一次运行拆成由不同CI任务执行的分片，每个分片仍可在自己的机器上使用worker。分片任务由CI预先启动：如果一个分片很早结束，它不会自动从另一个仍在运行的分片领取剩余文件。因此，增加机器能否缩短等待，取决于工作是否分得均匀，以及每台机器还能开多少worker。

Cypress Cloud的负载均衡说明描述了另一套机制：录制并启用并行后，Cloud利用此前运行的数据预测各spec时长；机器完成一份文件，就从共享队列领取下一份。预测还按浏览器分别计算。它可以让空闲机器接续处理尚未开始的文件，但派发单位仍是完整spec；一份已经运行的长文件，不能在中途拆给另一台机器。

这个区别使“并行能力”不能只写成有或没有。Playwright的worker解决一台机器内的同时执行，分片把工作送到多台机器；Cypress Cloud主要负责跨机器的spec派发。比较时要把机器内并发数和机器间调度分别写进配置，否则所谓框架速度很容易混入完全不同的资源条件。

同一组spec：三种流水线的账

设想一个纯粹用于计算的项目，四份互不依赖的spec在Playwright中分别耗时8、6、4、2分钟，在Cypress中分别耗时9、7、5、3分钟。每份spec在Playwright中都快一分钟。这些时间是假设值，不是前述论文的数据，也不是任何团队的实测；以下暂不计启动、重试、上传和机器性能差异。

单机、单浏览器：假设这台机器给Playwright两个worker，分别执行8加2分钟、6加4分钟的任务，两路都在10分钟结束。若Cypress在同一台机器上顺序执行四份spec，则合计24分钟。这说明本机并发可能放大等待时间上的差异，却没有说明每个用例快了同样的倍数。
双CI机器、单浏览器：假设每台机器只能运行一个worker，Playwright的固定分片一边得到8加6分钟，另一边得到4加2分钟，流水线要等14分钟。若Cypress Cloud恰好把9加3分钟、7加5分钟分别派给两台机器，两边都在12分钟结束。尽管假设中每份Playwright测试更快，不均衡的分片仍让这条CI晚于动态分配的方案。
双CI机器、双浏览器：假设Chromium和Firefox各占一台机器，各浏览器中的spec耗时仍按同一组假设值计算，且每台机器顺序执行。Playwright每台机器需要20分钟，Cypress每台需要24分钟；两种浏览器同时开始时，整条流水线分别在20分钟和24分钟结束。这两台机器已各自承担一套浏览器任务，不能同时再算作同一浏览器内的双机器并行。

双机器算例中的Playwright若把文件改配为8加2分钟、6加4分钟，等待便从14分钟降到10分钟；改变的是分配，而非用例速度。反过来，一份长spec若独占大部分运行时间，Cypress Cloud也只能等它完成。算例中的12分钟是指定派发顺序下的算术结果，实际顺序还受历史估时、任务到达时间和CI环境影响。

等待时间与资源用量也不是同一个数。仍以双机器、单浏览器的不均衡算例为例，若两项CI任务同时启动，并在各自测试结束时停止，Playwright合计占用20机器分钟，却要等14分钟才得到完整结果；Cypress合计占用24机器分钟，完整结果在12分钟到达。机器启动、浏览器安装、失败重试和报告上传都会改变真实账单与完成时间，单看最快的一份spec无法回答成本问题。

浏览器矩阵会重新分配机器

同一组端到端测试分配到Chromium、Firefox和WebKit浏览器运行，浏览器覆盖增加了流水线任务。

前述研究在Chrome、Firefox和WebKit中运行过两套测试，但实验中能运行某个浏览器，不等于产品将其列为同等成熟的支持目标。Cypress的浏览器说明列出Chrome系列与Firefox，并将WebKit标为实验性支持。若WebKit是必须通过的交付门槛，这个状态比只看Chrome中的耗时更直接地影响选型。

浏览器矩阵还决定流水线需要多少份工作。让同一组spec在两种浏览器上各跑一遍，测试任务就要分别执行；机器数量不变时，任务可能排队，也可能像上述算例一样由不同机器各承担一种浏览器。两种浏览器的真实耗时未必相等，因此不能把单浏览器完工时间机械地乘或除。若团队把主要浏览器放在每次提交，把更广的覆盖放在另一条流水线，等待时间也应分别计算。

CI成本与选择边界

机器分钟之外，Cypress Cloud还涉及录制用量。Cypress Cloud的计费说明以录制的测试结果计量套餐额度；若套餐不允许按需用量，包含和预购的额度耗尽后，录制仍可继续，但并行会停用。因此，计划依靠Cloud跨机器调度时，预算需要同时覆盖CI机器和录制结果量。Playwright自行配置分片，则需要团队承担分片均衡与CI配置维护。

选择可以落在具体工作流上：本机反馈、自有CI的worker与分片，以及WebKit覆盖更重要时，优先评估Playwright；已有Cypress测试和Cloud录制流程、spec长短差异明显时，重点评估Cloud的动态派发收益。决定等待时间的是最后结束的任务，决定计算成本的则是各机器实际运行了多久。两项指标可能指向不同选择，正如双机器算例中较早拿到结果的一方，使用的机器分钟反而更多。