会上，阿里巴巴测试开发专家巴图做《基于图片对比的页面自动化测试实践》的内容分享。巴图对比了传统软件公司和互联网公司在软件发布流程中有的不同，并指出如下三点：
页面用例的自动生成，是阿里测试智能化探索的一部分；
测试平台需要更好的稳定性以及自动化运维；
测试平台需要建立Bug闭环，统计出一段时间内拦截的Bug数量，这才能体现平台的真正价值。”
以下为巴图演讲实录：
大家上午好，我是来自阿里巴巴CBU技术部的巴图，今天为大家带来的议题是基于图片对比的页面自动化测试实践。这里有一些老朋友，可能听过这个议题了，我今天尽可能深入的多讲一些。
本次议题包括以下五个议程，首先我们来看一下对于传统软件公司和互联网公司他们的软件发布流程有什么不同？首先从发布周期来讲，传统软件公司一般都是以年为单位，比如说微软的Windows、Visual Studio等，都是两到三年一个周期发布，而对于互联网公司迭代是以天为单位，Bug修复是以小时为单位。互联网公司在Bug修复成本方面成本比较低，对于用户体验来讲会友好一些，因为有很多人在做体验，数据的收集难度和接触用户成本也比较低。
传统的软件公司协同方式是强流程的，互联网公司协同方式是强平台的。在软件发布之后，不同公司的QA的职责也是不一样的，软件公司的QA是研发环节最后一环，以尽可能发现Bug为主要职责，零Bug率是其主要的目标，QA是公司的流程推动者和权限的制约者；而在互联网公司又不太一样，QA要构建一个全流程的质量体系，还是工具平台的发起者和创造者，需要捍卫真实的用户体验。实际上现在很多公司都拥有测试开发工程师，就是说测试要具备一定的开发能力，实际上阿里巴巴的测试还需要具备一定的算法能力，后面我再细说。
我们BU有一个三到五年的规划，推行的测试策略是实时质量，就是运行含测试，实时可反馈。一句话总结就是将质量手段以模块、组件乃至系统化的方式嵌入到业务型应用当中。在我们看来，开发的代码和测试的代码是两个领域，开发写的代码是为业务特性服务的代码，测试写的代码是为业务质量服务的代码。
今年我们推出了“无人职守智动化”，就是基于变更，提供全流程、多样化、智能化的无人职守诊断能力，做到质量的实时反馈，到现在为止，QA不仅做验收测试，还要为整个的产品质量做一些诊断，要为全流程环节的质量做保障。
首先，来看全流程看护的层面，我们要在发布的各个阶段进行看护，包括变更前的预发阶段、变更中的灰度阶段和变更后的上线阶段。另外，要覆盖所有的变更，包括代码类变更、配置类变更和DB类变更，还需要多维度诊断，包括自动化诊断、业务监控诊断和业务日志诊断，最终拥有发布门禁，作为发布的准入，如果有质量问题会卡发布，在预发阶段和灰度阶段进行发布卡口。
这张图是我们现在的协同流程，我们会在把很多的feature创建分支，进行并行开发，这些分支在不同时间进行集成和发布。阿里不同的BU是不同策略，蚂蚁那边是在一个固定的时间大家统一来集成，统一进行回归测试的。但是对于新零售的电商业务，分支都是很难统一一个时间发布的，所以处于高频集成状态，这种高频集成状态也为质量保障带来了很大的挑战。
我们需要用分层自动化模型来应动挑战，左边是一些自动化框架&平台，包括UI层的MyDiff和MYUI，接口层的QTest和Doom，还有线上压测的Amazon。分层主要分4个层面，从上到下来是展示层、接口层、服务层和数据层，越上层稳定性越差，但是自动化效果越好。
再看执行阶段，在生产运行阶段我们要进行故障诊断和线上压测，预发布阶段进行变更检测和预发布自动化。开发/功能调试阶段进行无线组件测试和适配测试。
刚刚提到了UI层有MyDiff，MyDiff是零成本配置的截图对比自动化平台，有以下几个特点：成本低、预发布拦截、全屏与区域截图、自定义操作、支持多浏览器和多语言。
首先测试平台的发展要把自身融入到整个公司的研发生态里，所以我们要进行一些测试平台和协同平台的对接，包括盖亚、Tesla、AONE等平台。我们支持10个以上BU，包括CBU、ICBU、AE，零售通，阿里云，盒马等。MyDiff提供了任务管理、结果管理、执行机管理、数据统计、告警通知和API接口等功能，还具有两大核心能力：截图能力和对比能力。
首先看截图能力，截图能力中包含环境管理、登录管理、区域管理和前置操作四种能力：
阿里分四种环境：日常环境，预发环境，安全生产环境和线上环境。除了线上环境之外，所有的环境都需要绑定HOST访问，所以需要进行环境管理；
阿里一般分很多种登录系统，比如说大家经常登录天猫淘宝用的“淘系登录”、大麦登录、内网BUC登录，还有其他的系统自建的登录，所以，需要完善的登录管理，在我们统计过程当中90%以上页面都需要登录以后才能访问的；
区域管理，我们提供了区域截图的能力，在整个页面图片对比很难解决用户的业务问题时，用户可以定义他在一个页面具体截哪一部分，把这部分进行截图对比；
前置操作可以理解为简单的脚本功能，因为我们的MyDiff提倡的是零成本配置，所以不会提供复杂的脚本能力，复杂的脚本能力是刚才提到的MIUI提供的。
再看对比能力，对比分像素级和非像素级两种。
像素级对比，比如PC上页面在自动化过程当中可以控制浏览器尺寸，就意味着截图尺寸是一样的，可以通过简单的像素级对比来检测出他们之间有什么差异，对于无线端来讲，每一个手机的尺寸和分辨率都不相同，所以截图从像素级别来讲像素点对不上，通过传统像素对比解决不了问题，我们就进行非像素级的探索。
无论像素级或非像素级，都需要提供相似度评估和差异标定。适用的场景包括页面回归测试、页面巡检、页面异常检测和适配测试。其他场景还在探索中。
接下来看一下MyDiff在整个自动化流程里是如何工作的：
首先，开发在AONE提交代码进行发布，预发环境部署后执行STC安全扫描、CodeReview和自动化测试，这些测试都成功后才允许进行发布。我们的GAP平台接受AONE的消息，会检测应用关联哪些平台自动化的测试件，比如说UI层MyDiff或MYUI，接口层的DOOM，随后调取分层自动化的框架，框架执行完成以后会把结果反馈给GAP，GAP把结果同步给AONE。如果自动化测试失败，就需要测试人员上AONE处理，才能流转到下一步，测试人员需要判断这是一个正常业务变更引起的自动化失败还是确实测出了Bug。如果是Bug，通知开发处理，如果不是Bug就进行跳过处理。
再看一下技术实现架构：
MyDiff通过Web提供服务，需要有Web集群， Web集群里面应用的技术是阿里开源的Tengine项目和Pandora Boot框架；共享存储层，由IDB提供的MySQL集群服务、Tair提供的缓存服务和阿里云提供的OSS文件存储服务；Web集群，图片对比集群和任务调度集群之间是通过消息来进行交互的，这里写的RockeMQ作为一个开源方案，在内部RockeMQ叫MetaQ，任务调度集群和执行机集群通过HTTP进行交互。
下面是我们在图片对比算法方面的一些实践：
图片对比的常规方案是将一个原始图片进行灰度化后再生成差值图，最后进行图片对比。但是这种方案在页面元素轻微平移后，对比的结果就不准确了。我们在生成差值图后，增加了形态学膨胀和形态学腐蚀两步关键操作，膨胀是为了把离散的差值像素点膨胀成一个一个连通区域，连通以后为了避免连通区域扩大再进行一次腐蚀，这样就会把各个离散的像素点都组成区域。
举个例子，比如UI上一行文字，如果不进行膨胀腐蚀的时候可能每个字是一个区域，进行膨胀和腐蚀处理后一段话是一个区域，这样再进行标定结果就会更准确。
再来看我们在非像素级图片对比的探索，用肉眼看这两张图是有一定的差异，第一个差异点是上面的导航栏，第二个差异点是右图下面的一个toast提示，第三个是虚拟按键。但实际上对于计算机识别来说，会认为这两个图是完全不一致的，因为我们来看两张图，首先字体就不太一样，所以从像素点比较来看，他们之间是对不上的。再就是卡号，包括后面“请输入银行卡号”文本框和按钮尺寸都不一样，位置也不一样。这为我们对比提供了一定的挑战，我们首先会通过一些预处理，把一些与业务无关的图片剪切掉，然后再进行相应的元素轮廓提取，把所有的元素提取出来，在两张图互相搜索，在另一方搜索不到的元素实际上就是差异了。
当时我们测试了几种算法，包括SSIM、直方图、PSNR和两种组合算法，发现SSIM和感知哈希的组合算法的效果最好，可以达到86.74%的识别率，当时用了362组阿里系的样本。
现在看一下SSIM，自然图像信息高度结构化，像素信息具有强烈的依赖性，在空间上接近时依赖性携带关于视觉场景中的对象结构信息，SSIM算法的优势在于契合人类的视觉系统的观察特性，它的实现主要是通过亮度、对比度和结构的度量组合来实现的相似度的评估。
接下来看一下感知哈希的算法，图像都是二维信号，包括不同频率的部分，亮度比较小的频率是低频的部分，实际上在左边的第二张图就是一个低频部分，但是实际上，通过肉眼来看低频部分基本上是这张图的信息了。再就是亮度变化剧烈的区域实际上是高频部分，高频部分肉眼基本上看到是一块黑或者一块蓝的区域。所以要通过下采样提取低频信息。
提到了感知哈希一般都会与均值哈希进行对比，均值哈希的实现，首先将图片缩放成8乘8的尺寸，再把图片灰度化，之后再进行二值化求值，然后对平均值进行计算以后得到哈希指纹。均值哈希实际上有一些缺点，对它进行伽马校正或直方图均衡会影响均值，从而影响hash值。现在业界大多应用感知哈希，是把图缩放到32乘32的尺寸，通过离散余弦变换来获得低频部分，离散余弦变换后有一个8乘8矩阵的低频部分映射到左上角了，大家看到蓝图就是高频的部分，提取出来左上角8乘8部分算出来指纹就会比较稳定。
这是最后对比出来的实际结果，首先进行预处理，识别出来上面的导航栏的特征和下面的虚拟按键的特征，因为会干扰对比切掉了。然后两张图进行元素提取，把一些元素提取出来后去另外一张图搜索，搜索不出来的就是两张图的结构差异，这里面可以看到，toast就是差异，对于右图来讲toast遮挡的7、8、9、完成等元素，所以会把位置整体框出来。
接下来是卡发布的实践，各家公司协同平台不太一样，但原理都是一样的，比如，在我们AONE当中可以新建UI测试，这张图被遮盖了实际上可以选择MyDiff服务，也可以在这个流程配置当中建立发布流程的配置，比如预发布正式的流程，就是先进行预发环境发布，会触发自动化，自动化通过以后才进行正式发布。
这里用日常发布举例，包括开始、构建、日常部署、日常集成测试、日常验证、结束。关键点在于日常集成测试，大家会把自动化关联到这个环节，部署完成以后立刻去触发集成测试。这里可以为我们的测试服务添加验证点，比如，我们设置在预发需要WebUI测试100%通过后，才能进行下一步。
这实际上是在AONE当中真实案例，比如预发集成测试过程当中失败了，就已经卡住后面的正式构建了，需要测试人员来上协同平台看一下，点击查看结果看一下具体的问题，如果没有问题就可以进行跳过，如果有Bug的话就打回去让开发进行修改。
上面这张图是MyDiff列表里的一条任务，总数是两个，代表两个页面，相同的是两个的话就证明执行通过没有问题。下面的是一条不通过的结果，询报价单页面里有订单区域，我们为相似度设置0.98，如果不满足0.98代表测试不通过。
这里就是一个具体的真实的两张截图，上面截图是在预发环境的截图，下面这个是在线上环境的截图。我们电商一般都会有一些大促活动，大促期间发货时间比日常延长，所以一般会在大促的过程中进行一些文字提示，然后这就是本次发版与线上之间会有一些差异，MyDiff平台会直接把他们两张图之间的差异标出来，这样测试人员就可以一眼定位到问题在哪里，也可以判断这是一个正常业务变更，还是Bug。
现在说一下我们对未来的规划，首先体验要持续优化，降低用户门槛，因为我们现在是在阿里整个经济体下进行推广，所以降低门槛有助于让它生存得更好。再就是流量录制，今天会议的主题是“AI+未来”，现在大家都在探索智能化，阿里接口测试领域已经实现初级智能化，我们的智能化定义也在于自动生成，接口完全可以通过线上流量生成自动化用例，UI也计划着使用线上流量来实现，一个是智能url推荐，还有就是对于某一个页面用例自动生成。还要在稳定性上下工夫，为各个部门提供稳定的服务，做一些自动化运维的实践。平台的价值需要评估出来，比如，在一个财年或者一段时间内，能拦截多少Bug，这才是平台真正的价值。我们需要建立Bug的闭环，把我们能拦截的所有的Bug统计出来。再就是一些能力优化，比如执行速度、对比能力以及算法能力。
我的分享就到这里，谢谢。
