2019年10月26日，由Testin主办的第二届NCTS中国云测试行业峰会在京召开。”为主题，汇聚国内外测试领域知名专家学者、企业决策领导者、高层技术管理者、媒体从业者等，共同探讨高端云测试技术，助力测试从业者了解最前沿的行业动态和最新的行业实践，会上阿里巴巴测试开发专家巴图在《基于图片对比的页面自动化测试实践》分享内容，巴图对比了传统软件公司和互联网公司在软件发布流程上的差异，以及指出以下三点：1、页面用例自动生成是阿里测试智能探索的一部分；2、测试平台需要更好的稳定性和自动化运维；3、测试平台需要建立bug封闭循环，统计一段时间内截获的bug数量，从而体现平台的真实价值。”以下是Bat的记录你的演讲：大家早上好。我是阿里巴巴CBU技术部的巴图。今天给大家带来的话题是基于图片对比的页面自动化测试实践。这里有一些可能听说过的老朋友。这个话题，我今天就尽量深入的说一说。本主题包括以下五个议程。首先我们来看看传统软件公司和互联网公司在软件发布流程上的区别。首先从发布周期来看，传统软件公司一般以年为单位，如MicrosoftWindows、VisualStudio等，每两到三年发布一次，而对于互联网公司来说，迭代是以年为单位的。天，bug修复是按小时计算的。互联网公司在bug修复成本方面成本相对较低，对用户体验也比较友好，因为做体验的人多，资料收集难度大，联系成本高用户也比较少。传统软件公司的协作方式是强流程是的，互联网公司有强大的协作平台。软件发布后，不同公司的QA职责也不同。软件公司的QA是研发过程中的最后一个环节。主要职责是尽可能多地发现bug，bug率为零。这是它的主要目标。QA是公司的流程推动者和权限限制者；而在互联网公司，则不同。QA要构建全过程质量体系，也是工具平台的发起者和创造者。它需要捍卫真正的用户体验。其实现在很多公司都有测试开发工程师，也就是说测试要有一定的开发能力。其实阿里巴巴的测试也需要具备一定的算法能力。稍后我会详细说明。我们BU有一个三到五年的计划，实行的测试策略是实时质量，即运营包括测试，可以提供实时反馈。一句话概括就是将质量手段以模块、组件、甚至系统的形式嵌入到业务应用中。在我们看来，用于开发的代码和用于测试的代码是两个区域。为开发写的代码是服务于业务特性的代码，为测试写的代码是为业务质量服务的代码。今年我们推出了“无人值守智能自动化”，基于变化，提供全流程、多元化、智能化的无人值守诊断能力，实现质量实时反馈。到现在，QA不仅要做验收测试，还要对产品整体质量做一些诊断，保证整个过程的质量。首先我们来看一下全流程维护的水平。我们需要在发布的每个阶段都给予关怀，包括变更前的预发布阶段、变更中的灰度阶段、变更后的上线阶段。另外，为了覆盖所有的变更，包括代码变更、配置变更、DB变更，需要多维度诊断，包括自动化诊断、业务监控诊断、业务日志诊断，最后有发布权限控制作为发布权限。如有质量问题，发布将被封锁，发布将在预发布阶段和灰度阶段被封锁。这张图展示了我们目前的合作过程。我们会分支很多特性进行并行开发，这些分支会在不同的时间进行整合和发布。阿里不同BU策略不同，Ant定时集成，统一做回归测试。但对于新零售电商业务来说，分店很难统一发布，处于高频整合状态，这也给品质保障带来了很大挑战。我们需要使用分层的自动化模型来应对挑战。左边是一些自动化框架&平台，包括UI层的MyDiff和MYUI，界面层的QTest和Doom，以及在线压力测试的Amazon。分层主要分为四层，从上到下依次为展示层、界面层、服务层和数据层，层数越高，稳定性越差，但自动化效果越好。从执行阶段来看，在生产运行阶段需要进行故障诊断和线上压测，在预发布阶段需要进行变更检测和预发布自动化。在开发/功能调试阶段，进行无线组件测试和适配测试。刚刚在UI层提到了MyDiff。MyDiff是一个用于屏幕截图比较的自动化平台，零成本配置。首先，测试平台的开发需要融入整个公司的研发生态，所以我们需要把一些测试平台和协同平台对接起来，包括Gaia、Tesla、AONE等平台。我们支持CBU、ICBU、AE、RetailLink、阿里云、盒马鲜生等10多个BU。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项目和PandoraBoot框架；共享存储层是IDB和Tair提供的MySQL集群服务。阿里云提供的缓存服务和OSS文件存储服务；Web集群、图像比对集群和任务调度集群通过消息进行交互。这里写的RockeMQ是一个开源方案，RockeMQ内部称为MetaQ，任务调度集群通过HTTP与执行集群交互。下面是我们的图像比对算法的一些实践：图像比对的常规方案是对原始图像进行灰度化，然后生成差值图像，最后进行图像比对。但是在这个方案中，页面元素稍微平移后，比较的结果会不准确。在生成差异图之后，我们添加了两个关键操作，形态学扩展和形态学腐蚀。扩展就是将离散的差异像素扩展成一个连通区域。连接后，我们将进行另一次腐蚀，以避免连接区域扩大，这样每个离散的像素将形成一个区域。例如，对于UI上的一行文字，如果不进行膨胀和腐蚀，每个词可能是一个区域，经过膨胀和腐蚀处理后，一个段落就是一个区域，这样校准的结果会更加准确。让我们看看我们对非像素级图像比较的探索。肉眼看这两个图像之间存在一定差异。第一个不同是上面的导航栏，第二个不同是右图下方的toast提示。第三个是虚拟按钮。但实际上对于电脑识别来说，两张图片会被认为是完全不一致的，因为我们看两张图片的时候，首先字体是不一样的，所以从像素对比的角度来说，是不一致的。然后是卡号，包括后面的“请输入银行卡号”文本框和按钮，大小和位置都不一样。这为我们的比较提供了一定的挑战。首先，我们会通过一些预处理裁剪出一些不相关的图片，然后进行相应的元素轮廓提取，将两张图片中的所有元素都提取出来进行比较。搜索，另一边搜索不到的元素其实就是差异。当时我们测试了几种算法，包括SSIM、直方图、PSNR和两种组合算法，发现SSIM和感知哈希组合算法效果最好，达到了86.74%的识别率。当时用的是阿里系统的362群。样品。现在看看SSIM。自然图像信息是高度结构化的，像素信息具有很强的依赖性。当它在空间上很近时，依存关系携带着视觉场景中物体结构的信息。SSIM算法的优点是符合人类视觉系统的观察特性，其实现主要是通过对亮度、对比度和结构相结合所达到的相似度的评价。接下来我们看一下感知哈希的算法。图像是二维信号，包括不同频率的部分。亮度相对较小的频率是低频部分。其实左边第二张图是低频部分，但实际上，低频部分基本上就是这张图肉眼所见的信息。再者，亮度变化剧烈的区域其实就是高频部分，而高频部分肉眼看基本就是黑色或者蓝色的区域。因此，应该通过下采样来提取低频信息。提到感知哈希一般与均值哈希进行比较。实现均值哈希，首先将图像缩放为8乘8的大小，然后对图像进行灰度化，然后进行二值评估，然后计算平均值，计算出哈希指纹后得到。均值哈希实际上有一些缺点，对其进行伽马校正或直方图均衡化会影响均值，从而影响哈希值。现在业界大多采用感知哈希，就是将图像缩放到32乘32的大小，通过离散余弦变换得到低频部分。经过离散余弦变换后，将一个8×8矩阵的低频部分映射到左上角。可以看到蓝图是高频部分，提取左上角的8×8部分后指纹会更稳定。这是最终比较的实际结果。首先进行预处理，识别上部导航栏和下部虚拟按钮的特征，由于会干扰比较，因此被截掉。然后从两张图片中抽取元素，抽取一些元素在另一张图片中搜索，找不到的是两张图片的结构差异，这里可以看到，toast就是区别，右边的图片，toast被7、8、9、completion等元素遮挡，所以位置会被整体框起来。接下来就是发卡的做法了。不同公司的协同平台不一样，但是原理是一样的。例如，在我们的AONE中，我们可以创建一个新的UI测试。这张图被覆盖了。其实可以选择MyDiff服务，也可以在这个流程配置中，建立发布流程的配置。比如预发布正式流程就是先发布预发布环境，会触发自动化。自动化通过后，进行正式发布。这里以每日发布为例，包括开始、构建、每日部署、每日集成测试、每日验证、结束。重点是日常的集成测试。大家会把自动化和这个环节联系起来，部署完成后马上触发集成测试。在这里我们可以为我们的测试服务添加一个验证点。比如我们在pre-release中规定WebUI测试必须100%通过才能进行下一步。这其实是AONE中的一个真实案例。比如预发布集成测试失败，后续正式构建就已经卡住了。测试人员需要去协同平台看一下，点击查看结果看具体问题，如果没有问题可以跳过。有bug就回调，让开发修改。上图是MyDiff列表中的一个任务。总数为二，代表两页。如果两者相同，则证明执行没有问题。以下是失败的结果。询盘页面有下单区。我们将相似度设置为0.98。如果不满足0.98，则表示测试失败。下面是两张具体的真实截图。上图为预发布环境截图，下图为上线环境截图。我们电商一般都会有一些大的促销活动。大促期间，发货时间比平时要长，所以大促过程中通常会有一些文字提示，然后会有一些Differences，MyDiff平台会直接标注两张图片的不同点，这样测试人员可以一眼定位到问题所在，也可以判断是正常的业务变更还是bug。现在让我们谈谈我们对未来的计划。首先，我们需要持续优化体验，降低用户使用门槛。因为我们现在是在阿里整个经济体下推广，降低门槛有助于它更好的生存。然后是行车记录。今天会议的主题是“AI+未来”。现在大家都在探索智能。阿里的接口测试领域已经实现初级智能化。我们对智能的定义也在于自动生成。该接口可以完全通过在线流量。生成自动化用例，UI也计划利用在线流量来实现，一是智能url推荐，二是针对某个页面用例自动生成。还要在稳定性上下功夫，为各个部门提供稳定的服务，做一些自动化运维的实践。平台的价值是需要评估的，比如一个财年或者一段时间能堵多少bug，这才是平台真正的价值。我们需要建立一个bug闭环，统计所有我们能拦截的bug。然后是一些能力优化，比如执行速度，比较能力，算法能力。以上就是我的分享，谢谢。
