Chrome DevTools团队发布了，一个基于Node API的headless Chrome工具。Puppeteer提供了与其他第三方工具相似的功能，促使它们不断地创新与进步。

Selenium可以支持多种浏览器，与之不同的是，Puppeteer的目标很单一，它只支持headless Chrome。它提供了一组Node API，所以对于开发人员来说，它的使用方式与其他工具很相似。

\const puppeteer = require('puppeteer');\(async() =\u0026gt; {\const browser = await puppeteer.launch();\const page = await browser.newPage();\await page.goto('https://example.com');\await page.screenshot({path: 'example.png'});\browser.close();\})();\

这段代码是从Puppeteer的文件中摘取的。

这个项目背后的动机是要大幅简化headless Chrome（首发于Chrome v59）的交互操作。Google性能工程师Paul Irish，现有的交互协议太过复杂：

\

从我个人的经验来看，原生的DevTools协议对于开发者来说并不是最理想的，特别是如果要用它来编写自动化脚本，所以我们很需要这样的一个带有高级API的库。

\

社区也意识到这个问题。在之后，出现了很多替代者。在headless Chrome发布之后，、和也相继出现。而有了Puppeteer之后，第三方工具需要快速创新才有可能在这场竞争中生存下来。市场有可能会来一次大洗牌。

在Medium的一篇博文中，作者认为Google团队的进入对于开发者来说是积极正面的：

\

当然，如果Google决定要拥抱社区，那么状况很快就会得到改善。基于Chrome的解决方案给开发者带来了更多的选择，它们有别于那些有既定生态系统的成熟组织。

\

Chromeless在某些方面存在一定的优势，比如可以在AWS Lambda上远程运行测试用例。不过Puppeteer后续也可能支持Lambda。Puppeteer目前需要7.1版本的Node，而Lambda只支持6.10.3版本的Node。对于部分开发者来说，只能在单个浏览器上进行测试就像一个诅咒一样。不过Soh认为，对于大部分开发者来说，能够在Chrome上进行测试就已经很好了：

\

如果你可以在Chrome或headless Chrome上运行测试，那么大可以认为你的Web应用对于你的大部分用户来说是没有问题的。

\

查看英文原文：