看了一篇关于前端关于兼容性的文章，觉得信息量很大，翻译来分享给大家

　　谷歌的Instant Pages(即时页面)是一个非常酷的加速用户搜索的方式，当谷歌发现用户想点击哪个搜索结果之前，会在后台先预加载这个页面，当用户点击这个页面的时候会立即渲染呈现，这将为用户节约5秒的时间，当你知道每天搜索量非常庞大，特别是当你知道其他搜索优化都是亚秒级别的时候，5秒的效果将会非常显著。

　　即时页面的测试问题也很有趣。这个功能需要客户端和服务端相互调用完成，我们需要在一个看不见的后台预加载和渲染网页，我们要确保这些在后台预加载的页面在渲染出来后没有问题

　　初的想法是叫开发人员通过浏览一些他们打开的网页去测试，但是相对于庞大的互联网页数量这种测试是不可度量的，并且这种方式重复执行的成本很高，此外你不知道预期的页面应该是什么样，写selenium的自动化代码验证成千上万的网站也会无休止的执行下去，毕竟产品发布时间是第一位的。我们的解决办法是通过自动化的代码来对比两种页面，一种是使用了即时页面功能的页面，一种是没有使用即时页面功能的页面

　　我们是如何对比两个结果的呢?特别是当页面上的内容或者广告不断变化，我们根本不知道内容或者广告下一刻会变成什么样子的话，我们又该如何对比呢?我们可以使用缓存的办法，但是用这种方法测试毕竟与真实的情况不一样，并且需要花费一定的时间去创建这种缓存的机制，还要花精力去解决每种缓存页面创建和更新的定时策略不统一的问题。我们终采用了利用DOM的办法来对比网页。我们逐个像素地扫描网页，我们主要关注在每个像素点上DOM中哪个元素是可见的，而不是关注每个像素点的color/RGB的值。然后我们对这些紧密的像素点的匹配结果做一个简单的度量可以了。这种测试方法是是由我们所谓的“质量机器人”产生的，这些机器人会生成分数0〜的分数，意味着所有的测量值是相同的。

　　当我们执行这些测试的时候，发现绝大部分(大约95%)的比较正如我们所期望的那样是几乎相同的。对于其中不相同的每对页面，我们建立了一个网页，以图片和高亮的方式显示两个页面间的差异。这能使开发人员更简易、快速、直观地验证渲染过程中页面上的内容或其他非结构上引起的差异。任何时候这些自动化测试都是可度量的、可重复的，可量化的，开发人员可以不通过我们进行测试，这是多美好的一件事情呀!

　　这种测试是怎么建立起来的呢?像在谷歌测试中的许多东西一样，是人们之间聊天谈起了这个东西，这种聊天可以使自己正在实现的工作可以帮助其他工程师。这是自下而上的，而非自上而下。 TEJAS Shah主要从事通过质量机器人解决chrome和其他浏览器的兼容性(更多的是在以后的文章中)的工作。当他去即时页面开发人员的办公楼参观的时候，他和这些开发人员开始聊了起来，他们赞同用他的机器人可能会帮他们一些忙。他然后在接下来的几个星期把它与即时页面的测试连在了一起，后跟这个团队共享了这个成果。

　　而现在质量机器人的更多应用开始浮出水面。如果我们保持浏览器不变，仅仅修改应用程序的版本会怎么样呢?这些机器人能够帮助验证Web应用程序的一个独立的功能而不用再重新编写和维护自定义的验证脚本吗?