会上，阿里巴巴技术专家羽瑶做《基于图像智能算法的端上h5页面测试提效轻量化解决方案》的内容分享。羽瑶指出，“自动化能力多多少少都有稳定性的问题，我们非常注重算法能力，正在探索基于图像算法能不能真实检测页面的问题。”
以下为羽瑶演讲实录：
大家好我是来自阿里巴巴的羽瑶，我们组主要负责集团的平台化产品来服务业务测试。这是我演讲的目录结构，我首先介绍一下这个方案的背景，我们有一个业务团队负责所有淘系级A+级大促，每次大促页面非常多，比如19年1到9月总A+级大促59个，A+以上就是S级，比如双十一这种活动。大促活动非常多，我们前端开发和技术做了很多动态化配置方案来方便页面及时发布，就是每次大促活动的每一个会场，会场的发布显示时间，要加载的数据都可以动态配置，然后大促活动当中可能运营会及时调整策略，可能就有一些楼层下掉，或者运营不同配置不同算法，个性化策略来把不同的商品突出出来，包括模块的配置化，它的页面结构在整个上线阶段会不停的变化。
伴随着这些问题我们测试时间非常短，比如“99大促”时第一轮预演，就是指整个页面的数据搭建都完成，有一个比较完整的页面效果开始，然后到真正的上线可能“99”时候中间就只有4个工作日的时间，因为这些问题，所以我们有一些页面是测试从来不去介入过程当中的，有一些有问题页面会泄露到线上用户看到的页面中，这块是缺乏监控的，因为我们所有动态化的配置是没有实现，测试没有精力兼顾每次改动和变动，我们业务团队帮助他们不停的探索有什么自动化方案可以覆盖这些问题。
介绍一下现在会场的保障方案有哪些，一是数据源管控，商家每次上传商品，上传图片，编辑商品的信息，可能就是在上传的当时或者N+1时间对这层数据做算法检测和过滤，以及一些清退。另外上线过程当中会做一些数据监控方案，应对这些算法调整带来的问题。
测试阶段就是一个新页面刚来的时候，或者有一个新模块新上线的时候，有大量外包适配投入，业务方全民预演，因为每次新搭建，运营和产品很关心页面是否正常，这时候我们可能会组织一轮产品、运营、技术、测试把大家都拉过来一起看页面有没有问题，这两块其实都是纯人力的投入。
一部分不太重要的大促活动可能就是运营自己看一下没有问题，就是这种技术或者有没有问题大家自测去保证的。
其实这都是在端上看到的，我们介绍一下现在集团在端上自动化有哪些方案，大概来说其实每一个BU每一个团队有自己的一套，大体分成三类，一类是基于Appium/Uiautomator，基于开源的框架基础能力，自己搭建持续集成的平台，自己跟自己发布系统对接写脚本，纯写脚本的这种。
另外一种是应用侵入型，以伽利略为代表，开发端上SDK，相当于自己调用自己的能力做脚本驱动，可能搭载自己守护的APP进程跟后台做一些设备驱动。
现在这一两年比较火的是天画的产品，做了模块级的和数据级驱动，这个模块只是一个页面来了以后自己可以写脚本，底层是基于这个自动化框架能力，一个页面来了可以定义页面做哪些模块切分，哪些模块有一些ID是固定的可以写每一个页面，某一个模块的某一个控件，这个方案是为了应对框架级变动导致自动化运行的失败，同时结合我们集团线上流量的抓取，DOOM（采集线上机器的流量，对beta测试机器进行流量回放并对比）的平台能力，根据运行数据生成页面的能力，做数据驱动型的运行。
但是这三种可能都有问题，就是需要去写脚本人工写脚本，伽利略（使用很多内外部底层hack技术，自有守护进程，设备管理维护，嵌入待测试APP）可能自己定制APP，同时运行来讲，稳定性都是会有问题的，动化能力多多少少都有稳定性的问题，我们非常注重算法能力，正在探索基于图像算法能不能真实检测页面的问题。
下面介绍一下我们的方案，我们的方案跟这个都不太相同，因为他们可能要解决端上h5，所有的Native级别比较多，我们解决的是会场级，是以h5为主。这个是图像算法、便捷、轻量化、贴合不同业务方不同业务场景，比如我们有业务方卡发布，他们必须靠一遍我们应用，确认没有问题才可以发布，另外还有不同业务方也时间穿越的方案，就是指你页面没有上线阶段，外面看不到的时候我们可以调整底层系统级时间，让页面提前进入双十一状态场景当中，会做这些打通再调系统运行来做提前验证和检测。
为了让大家更有体会，看一下我们的方案运行，这是最简单的场景例子，可以整体看清楚整体怎么串的，我们手机在任何一个端环境下可以扫描这个二维码进入我们的中间页，中间页以后就不停去做任务轮巡，扫了以后，任何机器上传到我们平台，可以作为实时运行的手机环境，我们在这里新建任务，然后这是单页面检测场景，现在主要是用在线上页面巡检和检测当中。选择我们刚才的机器，这后面的场景，我们还有一些算法的定制，行动点定制和应对，录制、回放或者应对复杂页面交互场景的需求，新建完成以后后面有端定制的，创建完成以后机器就会在这里跑起来，跑的每一步会做截图，然后截图上传到后台以后，后台算法就会确实是检测有没有什么问题。
这些算法目前来说可能检测一些空楼层，空楼掉坑，异常词之类的，这个跑完以后后台可以实时看到当前页面效果。这左边是我们每一步截图信息，右边是拼接好的长图，这个页面是没有问题的，在页面有问题的时候，那边有错误信息的出现，大家可以点击不同的信息到具体的错误页面。然后这个页面是在A客户端上跑的，速卖通的，跑完以后跟系统对接的，他们跑完跳到我们这里看具体错误信息。
看一下我们的方案怎么做的，我们核心就是手机打开中间键做任务下发，下发的时候其实输入只是输入页面URL，输入URL以后我们对这个URL拼接系统运行的参数，比如ID，任务类型，重要的是我们拼接了我们自己的一个脚本，就是红色的脚本，拼接完这个脚本以后我们就会落库，当时我们新建任务是针对不同机型的，跑完以后就会，机器只要在中间页轮训有任务执行的话，他就拿到任务开始执行。拿到任务我们脚本插入原生页面当中，我们原来基于页面本身有模块可以读取URL脚本做插入，后面我们直接做天猫端上的，在页面漏以后会检测有没有符合条件的特殊参数，有没有符合安全限制的一个域名环境，一个脚本插入到页面当中。
刚刚演示的场景就是一种半自动调度为主的方案，那种方案可能有稳定性问题，比如说页面跳转到了异常的错误页面，那个页面不知道会跳到那里，或者异常场景导致APP关了的话，自动化方案就停掉设备离线，我们后面加入自动调度，就是真机操控能力方便让它再回到中间页。
因为我们有这个能力，支持三种任务类型，一种是录制型任务，我们早期开人工录制口子，就是人工去在平台上新建任务后做操作，操作的每一步都会实时上传到平台上，当运行任务完成后可以确认这一次的任务做录制，刚刚演示的一种场景就是自动化录制场景，是纯算法，纯后台驱动的去做哪些行为和操作的，回放型任务是指模块级更改上线，页面级适配场景的，我们针对某一个录制型任务在其他机型做回放，这个回放和自动化原理不一样的是，以前写脚本大家可能是在其他的机型找某一个iOS或者PaaS是否有这个，然后再做回访和点击，我们基于前端开发需要实现自适应的方案，自适应方案指UAD设计375的视觉图，联想情况下应该是实现不同尺寸上是等比放大的关系，我们基于这个原理回放时候会做不同尺寸信息换算做运行、点击和查找。如果我们点击某一个位置的话失败了，这个时候对比就有问题了，两种图可能出现差异，我们就会认为它的自适应或者是其它页面是有Bug的。
我们单页面场景就是刚刚视频演示的简单场景，也是那种场景纯算法的，就是做驱动和单步问题检测，然后单步就是做滚动操作和最后做全图拼接。
我们方案的一些细节，刚刚看到我们所有的整个驱动过程其实就是插入页面当中的脚本和后台交互的，我们脚本是怎么做到可以监控它的行为，怎么做到操纵点击呢？其实是结合了很多库的能力，就是去检测手机上的一些TUCH事件，检测行为做人工录制场景，还可能根据一些库获取设备信息的能力，或者设备ID能力，设备唯一指纹，利用集团的一些能力做上传。端内截图方案，我们截图方案有四种，一种浏览器上，脚本监测是浏览器环境就调浏览器插件的截图，如果在端上，淘系段上主流有两种，淘系就是淘宝天猫用Windone的能力，就是h5使用能力有一个容器能力。支付宝可能是另外一个自己开发的容器，在容器环境中我们会调动容器能力，如果进入异常场景，上传有问题，我们会借助脚本库的能力，用纯脚本实现来截图。有了底层的这些，我们可以像人一样操作页面滚动和点击，结合我们后台就有一些真机管理，常用后台管理能力，然后调动各个方面算法的检测能力做到实现人工合自动的录制和回放。
我们刚刚讲了截图有四种场景的，所以我们运行其实可以在浏览器或者是任何移动端上运行的，但是在非有容器能力，比如说用纯脚本截图场景APP下可能针对特别复杂页面，因为脚本截图可能会有一些失真的情况。
我们上传在端内的淘系APP里，上传到我们的图片空间做管理，然后到国际站，到AE可能要转海外的基站，我们就上传到阿里云OSS服务的位置。
刚刚讲到自动调度来提升它的稳定性，可能调度ATS自动调度的能力，然后有了这一套之后跟业务方整体链路，有的是页面发布时候就叫我们，或者页面需要有一些线上巡检任务调我们，或者需要一些其他的创新方案时候，检测页面调我们，现在我们还接了任务，就是有一个订单，这两天报了一个问题，就是签订的订单可能空白了也会调我们应用跑一下异常空白的检测。
我们算法能力就是这些，最终显示单机检测有犬兔拼接能力，还有掉坑，适配检测有含个性化数据图片对比，因为不同账户或者同一个账户在不同时间访问页面也是不一样的，用传统的录制回放对比会有较大的差异问题，然后会检测异常词，这会调用OCR的能力，或者是抢光，这种看业务方不同业务需求做定制。
大家看一下实际例子，就是素材图模块级数量变动，我们可能通过对比发现对比失败人会去看这种问题导致的，还有商品和坑的自适应，商品坑写死宽度导致不同机型宽度有问题，这是通过对比能力发现的。还有空坑能力，页面图没有加载出来，或者默认加载了没有实时商品数据的。然后还有掉坑，这就是指我们会场页面一行两个或者一行三个商品坑或者是卷的坑缺失的时候这也是业务场景需要关心的。
还有相同素材，就是我们只是检测单品，单品如果出现了相同的推荐，相同的品牌或者相同的商品，我们这种场景下面其实后台算法没有做到正确打散，打散逻辑有问题的他们也会关心，还有空楼层的问题，有楼层名称但是下面整个楼层没有数据。
还有异常词下面营销利益点是null，这可能后台没有填或者前端拉取异常导致的。整屏或者大半屏没有数据，还包括利益点的折叠。
我们介绍其中一种算法，就是含个性化区块的图像对比，运行过程中可以支持登录自动化账户跑，但是难免跑实际场景或者同一个账户出现的异常，这是我们需要做图像对比需要解决的问题。刚刚说我们整个实现是基于前端自适应，但是理想情况下可以做到100%的完美，但是不同浏览器环境不同开发的问题，或者边框级1px适配差异导致累积换算时候，GS换算有精度问题，会有略微差异，我们会首先做一个平移，就是找两张图，通过一些换算找到差值最小的匹配位置，这一步目的就是把顶部对企业。
我们找的位置计算差值区域，就是两张图有差异的部分，这里有噪声我们进行形态学操作，拿到主要差别区域，拿到差别区域以后，我们用边缘检测找到图片边缘，然后将差异化大的部分盖掉，我们对比时候这两个图做对比的，然后会计算他们的特征和相似值，通过这个展示框架级差异，个性级差异是可以对比出来的。
除此之外，因为我们刚刚见过很多算法场景，还运用了特征点匹配，OCR，不同分类模型训练，包括MobileNet。同时，因为插入页面当中脚本和后台交互，所以脚本可以拿到多一层信息就是页面的DOM信息，这是指整个页面有块级元素存在，这个在页面当中具体位置是什么样的，比如说这里有商品坑，可以拿到这个坑位大小、长宽、具体顶部和左部位置，有这个信息可以进一步提高算法检测的精度。
我们的运行数据是这样的，如果人力适配投测试过程，主要是参加上线阶段，上线前开发完以后，投入一轮去不同的机器看不同效果。这个在上线阶段、测试阶段、改完Bug的任何一个阶段都可以实时跑，所以我们页面覆盖数比它高很多。同时，因为我们的算法能力，帮助他发现了更多的体验类的问题。这是之前6月的数据，人力投入是当时有设备异常掉线场景维护，还有一部分是算法结果人工确认的投入，这种随着算法精度提升和自动调度方案的改进，其实是可以进一步缩小的。这个是刚刚演示的单日巡检，两小时跑一次，一小时跑一次的场景下检测到每天页面有问题的数。
我的演讲到这里结束，谢谢！
