技术雷达快讯：自2017年中以来，Chrome用户可以选择以headless模式运行浏览器。此功能非常适合运行前端浏览器测试，而无需在屏幕上显示操作过程。在此之前，这主要是PhantomJS的领地，但Headless Chrome正在迅速取代这个由JavaScript驱动的WebKit方法。Headless Chrome浏览器的测试运行速度要快得多，而且行为上更像一个真正的浏览器，虽然我们的团队发现它比PhantomJS使用更多的内存。有了这些优势，用于前端测试的Headless Chrome很可能成为事实上的标准。

随着Google在Chrome 59版本放出了headless模式，Ariya Hidayat决定放弃对Phantom.js的维护，这也标示着Phantom.js 统治fully functional headless browser的时代将被chrome-headless代替。

Headless Browser

也许很多人对无头浏览器还是很陌生，我们先来看看维基百科的解释：

A headless browser is a web browser without a graphical user interface.

Headless browsers provide automated control of a web page in an environment similar to popular web browsers, but are executed via a command-line interface or using network communication.

对，就是没有页面的浏览器。多用于测试web、截图、图像对比、测试前端代码、爬虫（虽然很慢)、监控网站性能等。

为什么要使用headless测试？

headless broswer可以给测试带来显著好处：

1. 对于UI自动化测试，少了真实浏览器加载css，js以及渲染页面的工作。无头测试要比真实浏览器快的多。

2. 可以在无界面的服务器或CI上运行测试，减少了外界的干扰，使自动化测试更稳定。

3. 在一台机器上可以模拟运行多个无头浏览器，方便进行并发测试。

headless browser有什么缺陷？

以phantomjs为例

1. 虽然Phantom.js 是fully functional headless browser，但是它和真正的浏览器还是有很大的差别，并不能完全模拟真实的用户操作。很多时候，我们在Phantom.js发现一些问题，但是调试了半天发现是Phantom.js自己的问题。

   

2. 将近2k的issue，仍然需要人去修复。

3. Javascript天生单线程的弱点，需要用异步方式来模拟多线程，随之而来的callback地狱，对于新手而言非常痛苦，不过随着es6的广泛应用，我们可以用promise来解决多重嵌套回调函数的问题。

4. 虽然webdriver支持htmlunit与phantomjs，但由于没有任何界面，当我们需要进行调试或复现问题时，就非常麻烦。

那么Headless Chrome与上面提到fully functional headless browser又有什么不同呢？

什么是Headless Chrome？

Headless Chrome 是 Chrome 浏览器的无界面形态，可以在不打开浏览器的前提下，使用所有Chrome支持的特性，在命令行中运行你的脚本。相比于其他浏览器，Headless Chrome 能够更加便捷的运行web自动化测试、编写爬虫、截取图等功能。

有的人肯定会问：看起来它的作用和phantomjs没什么具体的差别？

对，是的，Headless Chrome 发布就是来代替phantomjs。

我们凭什么换用Headless Chrome？

1. 我爸是Google,那么就意味不会出现phantomjs近2k问题没人维护的尴尬局面。 比phantomjs有更快更好的性能。

2. 有人已经做过实验，同一任务，Headless Chrome要比现phantomjs更加快速的完成任务，且占用内存更少。（图片解析请看阅读原文）

3. chrome对ECMAScript 2017 (ES8)支持，同样headless随着chrome更新，意味着我们也可以使用最新的js语法来编写的脚本，例如async，await等。

4. 完全真实的浏览器操作，chrome headless支持所有chrome特性。

5. 更加便利的调试，我们只需要在命令行中加入–remote-debugging-port=9222，再打开浏览器输入localhost:9222(ip为实际运行命令的ip地址)就能进入调试界面。

能带给QA以及项目什么好处？

前端测试改进

以目前的项目来说，之前的前端单元测试以及组件测试是用karma在phantomjs运行的，非常不稳定，在远端CI上运行时经常会莫名其妙的挂掉，也找不出来具体的原因，自从Headless Chrome推出后，我们将phantomjs切换成Headless Chrome，再也没有出现过异常情况，切换也非常简单，只需要把karma.conf.js文件中的配置改下就OK了。如下

customLaunchers: { myChrome: { base: 'ChromeHeadless', flags: ['--no-sandbox', '--disable-gpu', '--remote-debugging-port=9222'] } }, browsers: ['myChrome'],

UI功能测试改进

原因一，Chrome-headless能够完全像真实浏览器一样完成用户所有操作，再也不用担心跑测试时，浏览器受到干扰，造成测试失败

原因二，之前如果我们像要在CI上运行UI自动化测试，非常麻烦。必须使用Xvfb帮助才能在无界面的Linux上 运行UI自动化测试。（Xvfb是一个实现了X11显示服务协议的显示服务器。 不同于其他显示服务器，Xvfb在内存中执行所有的图形操作，不需要借助任何显示设备。）现在也只需要在webdriver启动时，设置一下chrome option即可，以capybara为例：

无缝切换，只需更改下配置，就可以提高运行速度与稳定性，何乐而不为。

Google终极大招

Google 最近放出了终极大招——Puppeteer（Puppeteer is a Node library which provides a high-level API to control headless Chrome over the DevTools Protocol. It can also be configured to use full (non-headless) Chrome.）

类似于webdriver的高级别的api，去帮助我们通过DevTools协议控制无界面Chrome。

在puppteteer之前，我们要控制chrome headless需要使用chrome-remote-interface来实现，但是它比 Puppeteer API 更接近低层次实现，无论是阅读还是编写都要比puppteteer更复杂。也没有具体的dom操作，尤其是我们要模拟一下click事件，input事件等，就显得力不从心了。

我们用同样2段代码来对比一下2个库的区别。

首先来看看 chrome-remote-interface

再来看看 puppeteer

对，就是这么简短明了，更接近自然语言。没有callback，几行代码就能搞定我们所需的一切。

总结

目前Headless Chrome仍然存在一些问题，还需要不断完善，我们应该拥抱变化，适应它，让它给我们的工作带来更多帮助。

文／ThoughtWorks齐磊

原文链接：http://insights.thoughtworks.cn/phantomjs-and-chrome-headless/