干货 | 基于图像比对技术，低成本维护的携程机票前端测试平台SnapDiff

作者简介

陈亮，携程机票BU高级测试经理。在互联网服务端、前端的软件质量领域有多年的实战经验，喜欢钻研引入新技术，提升团队工作效率。

前言

前端由于直接和用户交互，在互联网公司具有天生的快速迭代特性，这使得测试代码的维护成本非常高，往往跟不上产品的迭代速度。

传统的测试方法是由测试人员根据测试用例，在测试代码中添加关键元素的校验点，随着测试代码的不断积累，维护成本不断上升。

每次页面改版都会带来大量的维护工作，维护工作量太高也带来投入产出比不高的问题。妥协方法往往是只维护少量核心用例，但随之产生的问题是测试覆盖不够全面，很可能会带着一些问题发布。

携程和大多数互联网公司一样，也遇到了上述问题。由于携程所处的旅游行业业务相对较复杂，业务场景众多，全面覆盖需要大量的测试场景。

以携程的机票业务举例，单一个订单详情页面的全面覆盖就需要上千个用例。在版本快速迭代的背景下，完全依靠手工测试肯定是不可行的，所以我们致力于通过一种技术方案去解决上述问题，SnapDiff平台应运而生。

一、平台简介

平台的目标是替代按传统的维护检查点方式，降低测试代码的维护成本，提升测试用例的覆盖面，推动测试效率提升，并且能够真正帮助发现问题。

设计时考虑以下五个方面：

易用性：好的平台需要尽量减少学习成本，可快速上手。所以我们选择了前端最熟悉的JavaScript语言作为开发语言。为了方便不同的使用场景，支持手工触发和持续集成触发测试。

稳定性：平台支持两个层面的对比测试，前端展示层的图像对比和前端消息处理的监听对比，需要保证获取图像，消息监听，对比算法的稳定性。

高效性：前端测试相对接口测试耗时很长，需要降低用例耗时，采用分布式多并发的方式。

扩展性：支持两个层面：测试数据和用例的快速扩展和测试页面的低成本接入扩展。

通用性：支持H5，online，offline多个使用渠道的web&crn-web端页面。

如何工作？

1、测试用例设计&测试数据准备

用户创建测试任务，在任务中配置测试用例和数据。测试数据由我们的数据中心API提供，通过关键字进行动态关联。为保证数据的稳定，我们针对数据都只做了数据镜像，在使用前服务会将数据恢复到初始状态。

2、配置任务执行模式

任务可以配置为持续集成执行和手工触发执行两种模式。持续集成执行主要对应回归测试用例，手工执行对应的是日常需求的测试用例。

3、测试任务执行

平台会从前端展示和消息监听两个层面去进行比对测试。

前端展示：根据不同的测试用例自动打开测试页面，访问不同的业务场景，截图保存，然后自动去和上一个对照版本进行图像比对。比对是基于像素级别的，比对中如果有不同的区域，就会高亮标记。

消息监听：所有的页面被打开后，平台会记录页面的请求和返回消息，保存在服务端，然后自动去和上一个对照版本进行比对。报文中如果存在不同节点，就会记录并展示。

4、测试报告分析

测试比对结果会根据配置发送到收件人的邮箱，如比对无差异则显示通过，如存在差异则需要打开报告链接进行结果分析。

这样，测试人员只需要专注于设计测试用例，做测试结果分析，就可以很快确认系统是否存在Bug。比对是基于整体页面的，所以不需要再针对每个元素单独去维护，维护工作量自然比原先大大减少。即使遇到页面大改版，我们的代码也基本不需要调整。真正做到了一次投入，长期使用。

二、使用场景

某一天，小王收到了一个需求，在界面上对某个元素的展示逻辑进行了调整。使用这个系统，小王需要设计好测试用例，在系统里配置好需要执行的测试数据，后续执行的工作就可以交给系统去自动执行完成，系统执行完成后会自动发送报告邮件给到小王。

报告里会汇总界面和消息处理与原先基准版本的对比区别点，然后小王要做的是仔细分析一下报告中内容，考虑下是否存在问题，是否后续还需要增加的哪些场景等。

三、遇到的问题和解决思路

1、提升报告准确性

• 前端的样式经常会有一些细微的调整，有时调整一个空格，一个换行就会导致页面中的元素位置产生变化。如果我们想忽略这种变化，只关心展示的内容是否正确，是否有一种方式可以快速实现呢？ 我们想到了图像文字识别，通过这种技术，可以直接告知用户具体的不同点，用户不必看图，减少了报告分析者的分析工作量。
• 前端有的模块是已知的不同点，比如说：广告轮播模块，针对这类部分可以设置截图时自动忽略这个部分。
• 比对结果智能分类：针对不同数据发现的同一类问题，系统会根据不同点进行自动聚合分类，只在报告中展示一个样例，使用者可自行决定是否需要查看其它数据
• 智能忽略：使用者在分析报告过程中，如果发现一些不同点是正常的，可设置忽略，系统下次对比时就会自动将这类内容标识为可忽略。

2、提升执行效率

• 使用无头浏览器测试方案 在我们的SnapDiff平台中，我们使用了Chrome开发团队去年新推出的PuppeteerAPI，Puppeteer是一个Nodejs的库，支持调用Chrome的API来操纵Web，相比较Selenium或是PhantomJs,它最大的特点就是它的操作Dom可以完全在内存中进行模拟既在V8引擎中处理而不打开浏览器，而且关键是这个是Chrome团队在维护，会拥有更好的兼容性和前景。
• 分布式并发 平台首先会将任务分发到不同的测试服务器，然后在每台服务器上多线程并发执行，通过这种方式，整体耗时大幅减少。

3、降低接入成本

• 支持自助接入 对于非定制类的常规测试需求，用户可自助创建测试任务，通过在配置中心里配置对比页面的url, div, 运行规则，报告收件人等即可实现接入
• 支持Job自助启动 测试任务的执行控制可自助操作完成

4、测试数据稳定性问题

数据是测试的前提，这个问题如果不能保证稳定会导致测试结果不稳定，我们具体是通过下面两种方式去解决。

• Mock 通过我们的mock平台，将测试用例和mock报文关联起来，用例开始执行前会首先自动配置好所有的mock。
• 数据镜像&恢复 将数据库中的测试数据创建数据镜像，保存在镜像仓库中，测试前通知数据服务做镜像恢复，这种方式比mock方式更贴近真实环境。

四、使用效果

不能帮助我们找到系统问题的测试框架都不完美，说明这个框架只是解决了一部分问题。所以我们在设计这个平台的时候，是抱着能够尽量多的发现问题的目的去做的。我们希望在测试的每个阶段都能够把工具引入进来，而不是只在某一个阶段。

工具可以支持开发同学自测，测试同学做新功能的测试，也可以做最后的回归测试，正因如此，它能够帮助我们发现更多的系统问题。

在我写这篇文章过去的30天内，这套比对系统帮助我们发现了60几个系统bug，未来我们还会不断优化，让这个系统发挥更大的作用。

我们希望测试人员专注于测试用例的设计和测试数据的梳理，测试执行类的工作我们会尽量交给工具去完成，当然前端的特殊性决定了一些任务仍然还需要进行手工测试，但我们一直在努力尽量把这些执行类的工作自动化，让测试人员更专注于测试设计，测试报告分析，优化，形成了一套测试设计->工具执行->测试报告分析->测试设计再优化的闭环。

五、平台的不足

1、目前接入的主要是H5&Web&Crn-web页面，后续会逐步支持Native&RN接入。

2、测试报告的易读性还可以进一步提升。

3、稳定性和性能需要进一步提升。