原文：blog.checklyhq.com/puppeteer-v…
当决定构建Checkly的浏览器检查时，我们选择了开源的无头浏览器自动化工具Puppeteer，后来也添加了Playwright。预期是综合监控和测试用户测的数据，来查看是否用户在任何时刻能按照预期使用网站，因此在我们的场景中速度是最关心的问题。
然而，确定哪种自动化工具更快很难。因此，我们决定运行我们自己的基准测试，看看”新手“Puppeter和Playwright如何与”老牌“WebDriverIO进行比较（使用Selenium和DevTools自动化协议）。
在我们的基准测试结果中，也有一些意想不到的发现，比如Puppeteer在较短的脚本上表现得更快，WebDriverIO在较长脚本场景中表现出比预期更大的可变性。阅读以下内容，了解更多有关结果以及我们如何获得这些结果。
目录
1.为什么要比较这些自动化工具？
2. 方法，或我们如何运行基准
a、 一般准则
b、 技术设置
c、 测量
d、 我们（尚未）测量的内容
3. 结果
a、 在演示网站上运行
b、 针对真实的web应用程序运行
4. 结论
为什么要比较这些自动化工具？
包括Puppeteer/Playwright 和 Selenium 在内的基准相当于苹果和橘子的对比：这些工具有着明显不同的使用范围，评估速度之前应该知道他们的差异。
尽管大多数人已经使用Selenium很多年了，我们依然想了解新工具是否真的更快。
WebDriverIO是一个具有大量有用功能的高级框架，它在内部使用不同的工具在多个浏览器上实现自动化。
选择WebDriverIO是因为大多数选择JavaScript的Selenium用户都使用WebDriverIO来驱动他们的自动化脚本。
另一个重要目标是，看看我们最近在Checkly上增加支持的Playwright与我们心爱的Puppeteer相比如何。
方法，或我们如何运行基准
如果您想直接了解结论，请跳过此部分。我们仍然建议您花点时间仔细阅读，以便更好地理解结论。
a、 一般准则
在明显不同的条件下进行测试是无效的。测试准则如下：
1.资源相同：每个测试都是在同一台机器上连续运行的，而它是“静止”的，即在基准测试期间，后台没有发生繁重的工作负载，这可能会干扰测试数据。
2.简单执行：脚本按照每个工具的“入门”文档所示运行，例如，Playwright: 执行node script.js，加上最少的附加配置。
3. 可比脚本：我们努力最小化用于基准测试的脚本之间的差异。尽管如此，为了实现稳定的执行，还是需要添加/删除/调整一些指令。
4.最新版本：我们在本文发布时测试了所有工具的最新可用版本。
5.相同的浏览器：所有脚本都是在无头Chromium上运行的。
有关所有要点的其他详细信息，请参阅下面的部分。
b、 技术设置
对于每个基准测试，我们使用同一个脚本顺序地跑1000次获取数据。
在Selenium基准测试中，我们的脚本运行在一个独立的服务器上，也就是说，我们没有每次运行都从头开始一个新的服务器（尽管我们总是使用干净的会话）。可以限制执行时间。
运行机器是最新一代MacBook Pro 16， macOS Catalina 10.15.7（19H2）参数如下：
Model Identifier: MacBookPro16,1Processor Name: 6-Core Intel Core i7Processor Speed: 2,6 GHzNumber of Processors: 1Total Number of Cores: 6L2 Cache (per Core): 256 KBL3 Cache: 12 MBHyper-Threading Technology: EnabledMemory: 16 GB
使用如下依赖：
bench-wdio@1.0.0 /Users/ragog/repositories/benchmarks/scripts/wdio-selenium├── @wdio/cli@6.9.1├── @wdio/local-runner@6.9.1├── @wdio/mocha-framework@6.8.0├── @wdio/spec-reporter@6.8.1├── @wdio/sync@6.10.0├── chromedriver@87.0.0└── selenium-standalone@6.22.1scripts@1.0.0 /Users/ragog/repositories/benchmarks/scripts├── playwright@1.6.2└── puppeteer@5.5.0
可以在github仓库中查找我们的脚本和各自的数据。
c、 评估
我们将以以下的参数为标准比较各个基准测试（这些值均在1000次运行中计算得出）：
- 平均执行时间（秒）
- 标准偏差（秒）：执行时间可变性的度量。
- 变异系数（CV）：表示结果相对于平均值的变异性的无单位系数。
- P95（第95个百分位测量）：去掉有序数据前5%后的最大值。查看一个非极端但仍然很高的数据点是什么样。
d、 尚未评估的内容
-
可靠性：不可靠的脚本很快就会变得无用，无论它们执行得有多快。
-
并行化效率：在自动化工具中，并行执行非常重要。不过在本文中我们想了解单个脚本的执行速度。
-
非本地环境中的速度：与并行化一样，云执行也是一个重要的一方面，也超出了本文的范围。
-
资源使用情况：所需的内存量和计算能力可以决定在哪里以及如何运行脚本。
请继续关注，因为我们可能会在即将到来的基准测试中探讨这些主题。（目前还没有更新）
结论
以下是我们基准测试的汇总结果。您可以在GitHub存储库中找到完整的数据集。github.com/checkly/hea…
在演示网站上运行
我们的第一个基准测试运行在我们的演示网站上（danube-webshop.herokuapp.com/）。此网页托管在Her…
在第一个场景中，执行快速登录过程，我们预期执行时间仅为几秒钟，这个场景对于突出实际工具之间启动速度的差异非常有用。
汇总结果如下：
_ 演示网站登录场景的基准测试结果_
最引人注意的一个现象是Playwright and Puppeteer在平均执行时间上有很大的不同，Puppeteer的执行速度快了近30%，并且差异也较小。因此我们怀疑Playwright的启动时间更长。为了只考虑我们这次的测试试验，不扩大研究范围，这个问题和类似的问题暂时搁置，在本文中不做讨论。
_ 执行时间比较 Playwright vs Puppeteer_
第二个令我们惊讶的现象是WebDriverIO运行中显示的总体可变性较低。同时结果显示时间很接近：图表显示了连续交叉的线，可见不同的自动化协议在执行时间上似乎没有太大的差异。
_ 执行时间比较 WebDriverIO with WebDriver vs WebDriverIO with DevTools_
不太令人惊讶的是，没有添加任何高级框架的情况下运行Puppeteer可以在非常短的脚本上节省大量的执行时间。
_ 执行时间 Puppeteer vs WebDriverIO with DevTools_
真实web应用程序上的运行
演示环境和真实环境通常会有很大的差异性，不可小觑。因此，我们非常希望在生产环境的应用程序上运行基准测试。我们选择了前端vue.js 和大量利用AWS的后端。
我们运行的脚本看起来很像一个经典的E2E测试：它登录到Checkly，配置了一个API检查，保存并立即删除。
Checkly检查创建场景的基准测试结果
在这个场景下，Playwright和Puppeteer在执行时间上的差异几乎消失了，Playwright占据了上风，表现出的可变性更低。
Playwright vs Puppeteer
按比例而言，新工具（Playwright/Puppeteer）与WebDriverIO之间的差异也较小。值得注意的是，与前一个场景相比，后两个场景表现更大的可变性，而Playwright和Puppeteer则呈现出更小的变化。
Playwright vs WebDriverIO with Selenium
在这个场景中，最初的测试会将cookie注入到一个全新的会话中，以便能够完全跳过登录过程。这种方法后来被放弃，因为我们在Selenium中遇到了问题——在加载了一定数量的cookie之后，会话会没有响应。WebDriverIO可靠地处理了这一点，但cookie注入步骤会增大执行时间的可变性，有时看起来挂起超过5秒。
现在我们可以后退一步，比较不同场景的执行时间：
平均执行时间 across benchmark scenarios
对结果有疑问吗？运行您自己的基准测试！您可以使用上面共享的基准测试脚本。不相信设置？请随时提交PR，以帮助进行更好的比较。
结论
首先，对这两种测试场景从最快到最慢的工具进行排序：
性能排行
这次的实验有一些有趣的发现：
- 尽管Puppeter和Playwright支持类似的API，但Puppeteer在较短的脚本上似乎有相当大的速度优势（我们观察到接近30%）。
- 与Selenium和DevTools WebDriverIO这两个相比，Puppeter和Playwright脚本显示更快的执行时间（在E2E场景中接近20%）。
- 在WebDriverIO中，WebDriver和DevTools自动化协议的执行时间相当。
总结
-
当运行许多更快的脚本时，如果不需要跨浏览器，使用Puppeteer更能节省时间。在更长的E2E脚本场景中，Puppeteer的优势就不明显了。
-
值得思考的是，是否可以运行一个更简单的设置，或者WebDriverio添加的工具是值得等待更长时间来查看结果的。
-
在基准测试中，执行时间的波动可能不是什么大问题，但在现实应用中，它们可能会堆积导致减缓构建速度。选择自动化工具时请记住这一点。
-
从双方的进展来看，我们想知道未来是否会将DevTools带到最前沿，或者WebDriver是否会维持其在浏览器自动化中的核心作用。我们建议密切关注这两种技术。
速度很重要，但它不是全部的性能指标。
