基准测试：Puppeteer，Selenium，Playwright和WebDriverIO

当我们决定构建Checkly的浏览器检查时，我们选择使用开源的无头浏览器自动化工具Puppeteer（后来又添加了Playwright）来做到这一点。我们希望通过综合监控和测试来支持用户，让他们知道他们的网站在任何给定时刻是否按预期工作。在我们的案例中，速度是最主要的问题。

然而，确定哪种自动化工具通常更快并不容易。因此，我们决定运行自己的基准测试，以查看新手Puppeteer和Playwright如何与经验丰富的WebDriverIO（使用Selenium和DevTools自动化协议）进行比较。

我们的基准测试结果还包括一些出乎意料的发现，例如在较短的脚本中Puppeteer的运行速度显着提高，而在较长的场景中，WebDriverIO的变异性超出了预期。请阅读以下内容，以了解有关结果以及我们如何获得它们的更多信息。

包括Puppeteer / Playwright和Selenium在内的基准测试几乎是苹果与橘子的比较：这些工具的适用范围大不相同，因此评估它们的任何人都应在考虑速度之前意识到它们的差异。

尽管如此，我们大多数人已经与Selenium合作了很多年，我们还是渴望了解这些更新的工具是否确实更快。

还需要注意的是，WebDriverIO是具有许多有用功能的高级框架，它可以在后台使用不同的工具来驱动多个浏览器的自动化。

尽管如此，我们以前的经验告诉我们，大多数选择JavaScript的Selenium用户都使用WebDriverIO来驱动其自动化脚本，因此我们选择了它而不是其他候选人。我们对测试新的DevTools模式也很感兴趣。

对我们来说，另一个重要的目标是，与我们心爱的木偶戏相比，最近在Checkly上增加了支持的Playwright表现如何。

如果您想直接获得结果，请随时跳过此部分。我们仍然建议您花些时间仔细研究一下，以便您可以更好地了解结果的确切含义。

如果要测试的工具在明显不同的条件下进行测试，则基准测试是无用的。为避免这种情况，我们整理并遵循以下准则：

资源奇偶校验：静态时，每项测试都是在同一台计算机上顺序进行的，即在基准测试期间，后台没有繁重的工作量，可能会干扰测量。

执行简单：如“入门”中所示运行脚本。每个工具的文档，例如适用于Playwright：节点script.js，并具有最少的添加配置。

可比较的脚本：我们努力将用于基准测试的脚本之间的差异最小化。尽管如此，仍必须添加/删除/调整一些指令以实现稳定的执行。

最新消息：在发布本文时，我们测试了所有工具的最新可用版本。

对于每个基准测试，我们从同一脚本的1000次成功顺序执行中收集了数据。

就Selenium基准测试而言，我们的脚本是针对独立服务器运行的，即我们并未像某些框架那样每次运行都从头启动新服务器（即使我们始终使用干净的会话）。我们选择此选项是为了限制执行时间的开销。

我们在最新一代的MacBook Pro 16＆＃34;上进行了所有测试。使用以下规格运行macOS Catalina 10.15.7（19H2）：

型号标识符：MacBookPro16,1处理器名称：6核心Intel Core i7处理器速度：2.6 GHz处理器数量：1核心总数：6 L2缓存（每个核心）：256 KB L3缓存：12 MB超线程技术：启用内存：16 GB

[email protected] /用户/ ragog /存储库/基准/脚本/ wdio-selenium├──@ wdio / cli @ 6.9.1├──@ wdio / local-runner @ 6.9.1├──@wdio /[email protected]├──@ wdio / spec-reporter @ 6.8.1├──@ wdio / sync @ 6.10.0├──[email protected]└──硒独立@ 6.22.1

您可以在专用的GitHub存储库中找到我们使用的脚本以及它们产生的单个结果。

变异系数（CV）：无单位系数，显示结果相对于平均值的变异性。

P95（第95个百分位数）：丢弃按数字排序的一组收集数据的前5％时剩余的最大值。有趣的是要了解非极端但仍然很高的数据点的外观。

并行化效率：在自动化工具的上下文中，并行执行非常重要。但是，在这种情况下，我们首先要了解单个脚本的执行速度。

非本地环境中的速度：与并行化一样，云执行也是一个重要的话题，不在本文的讨论范围之内。

资源使用情况：所需的内存和计算能力可以确定您在哪里以及如何运行脚本。

您可以在下面看到我们基准测试的汇总结果。您可以在我们的GitHub存储库中找到完整的数据集。

我们的第一个基准测试是针对我们的演示网站的。该网页托管在Heroku上，使用Vue.js构建，并具有小型Express后端。在大多数情况下，实际上并没有从后端获取任何数据，而前端却在利用客户端数据存储。

在第一个场景中，执行快速登录过程，我们期望执行时间仅为几秒钟，非常适合突出实际工具之间的启动速度潜在差异。

首先引起注意的是Playwright和Puppeteer的平均执行时间之间的巨大差异，后者的执行速度快了近30％，并且表现出较小的变化。这使我们想知道这是否是由于Playwright方面的启动时间更长。我们提出了这个问题和类似的问题，以避免此第一个基准测试的范围不断扩大。

第二个惊喜是WebDriverIO运行中显示的总体可变性较低。结果的接近程度也很有趣：该图显示了连续不断地交叉的线，因为在这种情况下，自动化协议似乎并没有在执行时间上产生可观的差异。

毫不奇怪的是，在不添加任何高级框架的情况下运行Puppeteer可以帮助我们在此非常短的脚本上节省大量执行时间。

以前的经验告诉我们，演示环境与现实世界之间的差异几乎总是被低估了。因此，我们非常希望针对生产应用程序运行基准测试。在这种情况下，我们选择自己的服务器，该服务器运行一个Vue.js前端和一个后端，该后端大量利用AWS。

我们运行的脚本看起来很像经典的E2E测试：它登录到Checkly，配置了API检查，保存并立即将其删除。我们期待着这种情况，但是我们每个人对数字看起来都有不同的期望。

在这种情况下，Playwright和Puppeteer之间执行时间的差异几乎消失了，前者现在居于首位，并且变异性略低。

相应地，较新的工具与两种版本的WebDriverIO之间的差异也较小。值得注意的是，与前一种情况相比，后两者现在产生的结果可变性更高，而Puppeteer和Playwright的表现出较小的变化。

有趣的是，我们对此场景的原始测试包括将cookie注入一个全新的会话中，从而能够完全跳过登录过程。后来，由于我们在Selenium方面遇到问题，该方法被放弃了，在装入一定数量的Cookie之后，会话变得无响应。 WebDriverIO可以可靠地处理此问题，但是cookie注入步骤使执行时间的可变性爆炸了，有时似乎挂了五秒钟以上。

对结果有疑问吗？运行您自己的基准测试！您可以使用上面共享的基准测试脚本。对设置不满意？随时提交PR，以帮助进行更好的比较。

首先，让我们对两种测试方案的工具从最快到最慢进行排名：

尽管Puppeteer和Playwright使用类似的API，但Puppeteer在较短的脚本上似乎具有相当大的速度优势（在我们的观察中接近30％）。

与Selenium和DevTools WebDriverIO风格相比，Puppeteer和Playwright脚本显示出更快的执行时间（在E2E场景中接近20％）。

当运行许多更快的脚本时，如果不需要运行跨浏览器，则可能值得运行Puppeteer以节省时间。在更长的E2E场景中，差异似乎消失了。

值得考虑的是，是否可以运行更多的准系统设置，或者是否值得再等待更长的时间来查看结果，这是WebDriverIO添加的工具的便利性。

在基准测试中执行时间的波动可能不是什么大问题，但在现实世界中，它们可能会堆积并减慢构建速度。 选择自动化工具时，请记住这一点。 观察双方的进展，我们想知道未来是否会将DevTools带到了最前沿，或者WebDriver是否将继续在浏览器自动化中发挥核心作用。 我们建议密切注意这两种技术。 速度固然重要，但却无法说明一切。 请保持关注，我们在进行新的实用比较时会告诉我们更多有关我们喜欢使用的工具的信息。