2019年10月26日，由Testin主办的第二届NCTS中国云测试行业峰会在京召开，与峰会以“AI+未来”为主题，将汇聚国内外测试领域知名专家学者、企业决策领军人物、高层技术管理者、媒体从业者等，共同探讨高新技术产业。端云测试技术，帮助测试从业者了解最前沿的行业趋势和最新的行业实践。会上，阿里巴巴技术专家于尧分享了《基于图像智能算法的端上h5页面测试提效轻量化解决方案》的内容。余尧指出，“自动化能力或多或少存在稳定性问题，我们非常关注算法能力，正在探索基于图像的算法是否能真正检测到页面。”以下为余姚演讲实录：大家好，我是阿里巴巴余姚人，我们团队主要负责集团平台产品服务于业务测试。这是我演讲的目录结构。先介绍一下这个计划的背景。我们有业务团队负责淘宝所有的A+级推广。有59个大促，A+以上为S级，比如双十一。有很多大促销活动。我们前端开发和技术做了很多动态配置的方案，方便页面的及时发布，即每次大促活动的每个会场，会场的发布展示时间，需要加载的数据都可以动态配置。那么在大促活动中，运营会及时调整策略，可能会掉一些楼层，或者运营会配置不同的算法和个性化的策略来突出不同的产品，包括模块的配置。它的页面结构在整个在线阶段会不断变化。伴随着这些问题，我们的测试时间很短。比如“99大促”期间的第一轮预览，就是整个页面的数据搭建完成，开始一个比较完整的页面效果，然后真正上线可能“99”只有4个工作日在中间。因为这些问题，我们有一些测试从来不介入的页面，一些有问题的页面会泄露给在线用户看到的页面。这是缺少监控，因为我们所有的动态配置都没有实现，测试也没有精力去照顾每一个变化和变化。我们的业务团队帮助他们不断探索哪些自动化解决方案可以解决这些问题。下面我介绍一下场馆目前的保护方案。首先是数据源控制。商家每次上传商品，上传图片，编辑商品信息，可能是在上传的时候，也可能是N+1次，对这一层数据进行算法检测和过滤。,和一些间隙。另外，在上线过程中会制定一些数据监控方案，以应对这些算法调整带来的问题。测试阶段是新页面刚上线的时候，或者是新模块上线的时候，外包适配的投入很大，业务方给大家预览一下，因为每次新建一个页面，运营和产品很关心页面是否正常。这个时候我们可能会组织一轮产品、运营、技术、测试，把大家聚集在一起，看看页面有没有问题。这两个组件实际上是纯粹的人工输入。一些不太重要的促销活动，可能是看运营本身有没有问题。是这种技术还是有没有问题大家通过自测来确定。其实这一切都看在最后。下面介绍一下集团在端到端自动化方面有哪些解决方案。一般来说，每个BU，每个战队都有自己的一套，大致可以分为三类。一种是基于Appium/Uiautomator，基于开源框架的基础能力，自己搭建持续集成平台，编写脚本与自己的发布系统对接，纯脚本。另一种是以Galileo为代表的应用程序侵入型。开发端的SDK相当于调用了自己的能力来驱动脚本，可能会配备自己的APP进程和后台来驱动一些设备。现在天华的产品这两年很火，有模块级的，也有数据级的驱动。这个模块只是一个页面，你来了之后可以写脚本。底层就是基于这个自动化框架。当一个页面来的时候，你可以定义哪些模块被分成页面，哪些模块有一些固定的ID。可以写每个页面和某个模块的某个控件。这个解决方案是为了处理框架层面的变化导致的自动运行失败。同时结合了我们集团线上流量抓取、DOOM的平台能力（收集线上机器流量、回放并与内测机进行流量对比），以及根据运营数据生成页面的能力，进行数据驱动运营。但是这三种可能都有问题，就是需要自己手动写脚本。Galileo（使用了很多内部和外部的底层hack技术，自带daemon进程，设备管理维护，嵌入待测APP）可以自己定制APP，同时运行。也就是说，稳定性会有问题，动画能力一定程度上存在稳定性问题。我们非常注重算法能力，正在探索基于图像的算法是否能真正检测到页面。下面介绍一下我们的解决方案。我们的解决方案和这个不太一样，因为他们最后可能要解决h5，native级别很多。我们解决会场层面，主要是h5。这是一种图像算法，方便、轻量级，适用于不同业务方的不同业务场景。比如我们有名片发布，他们必须依赖我们的应用，确认没有问题才可以发布。另外，不同的业务方也有时间穿越的解决方案，就是当你的页面不在线的时候，我们可以在外界不可见的时候，调整底层系统级的时间，让页面进入双十一状态场景提前，我们会做这些事情来打通，然后调整系统运行，做早期的验证和检测。.为了让大家有更好的了解，我们来看看我们的解决方案的运行情况。这是该场景的最简单示例。你可以看到整个字符串是如何连接成一个整体的。我们的手机在任何终端环境下都可以扫描这个二维码进入我们的中间页面，中页之后，我们会继续做任务巡查。扫描后，任何机器都会上传到我们的平台，可以作为实时的手机环境。我们这里会新建一个任务，然后这是一个单页检测场景。现在主要用于在线页面的检查和检测。选择我们刚刚创建的机器。对于后面的场景，我们还有一些算法定制，动作点定制和响应，录制，播放或者响应复杂的页面交互场景的需求。新建完成后，后面会有终端定制。这里会运行，运行的每一步都会截图，然后截图上传到后台后，后台算法确实会检测是否有问题。目前这些算法可能会检测到一些空楼、空楼坑、异常文字等。运行这个之后，后台可以实时看到当前页面效果。左边是每一步的截图信息，右边是拼接的长图。这个页面没有问题。当页面出现问题时，那里会出现错误信息。您可以点击不同的信息进入具体的错误页面。.然后这个页面在A客户端，速卖通上运行，运行之后，连接到系统，他们跳转到我们看运行之后的具体报错信息。看看我们的解决方案是如何工作的。我们的核心是打开手机中键发送任务。发送时，input只是输入页面的URL。输入网址后，我们在这个网址上拼接系统运行的参数，比如ID，任务类型，重要的是我们拼接了一个自己的剧本，就是红色的剧本。拼接好这个脚本后，我们就把它丢进库里。当时，我们为不同的模型创建了新的任务。机器运行完后，会在页面轮换训练中如果有任务要执行，他会拿到任务开始执行。拿到任务后，我们将脚本插入原生页面。我们最初有一个基于页面本身的模块，可以读取插入的URL脚本。后面我们直接在天猫这边做。页面泄漏后，我们会检查是否有符合条件的特殊参数。在不符合安全限制的域名上下文中将脚本插入到页面中。刚刚演示的场景是基于半自动调度的解决方案。该解决方案可能存在稳定性问题。比如页面跳转异常错误页面，不知道会跳到哪个页面，或者异常场景导致APP被关闭。如果有，自动化方案会停止设备下线，后面我们会加上自动调度，这样真机控制能力方便它返回到中间页面。因为我们有这个能力，我们支持三种任务，一种是录制任务，我们早期开通了手动录制，就是在平台上手动创建新的任务然后进行操作，操作的每一步都会上传实时到平台，当运行的任务完成后，可以确认这次任务会被记录下来。刚才演示的场景之一是自动录制场景。它是一种纯算法，纯后台驱动。对于页面级别的适配场景，我们在其他模型上重放某个录制任务。这个回放和自动化原理的区别在于，以前写脚本的时候，可能是在其他机型上找某个iOS或者PaaS。这个，然后做回访和点击。我们需要实现基于前端开发的自适应解决方案。自适应方案参考了UADDesign375的可视化图，联想的案例应该实现不同尺寸的比例放大关系。基于这个原理在播放过程中，不同大小的信息会被转化为运行、点击和搜索。如果我们点击某个位置失败，这时候比较就会出现问题。两张图片之间可能存在差异，我们会认为是它的自适应或者其他页面有bug。我们的单页场景就是刚才视频演示的简单场景，也是纯算法场景，就是做驱动和单步问题检测，然后单步做滚动操作最后进行全图拼接。我们计划的一些细节，我刚才看到我们整个驱动过程其实都是把脚本插入到页面中和后台进行交互。我们的脚本如何监控其行为并操纵点击？其实就是结合了很多库的能力，就是检测手机上的一些TUCH事件，检测手动录音场景下的行为，根据一些库获取设备信息能力，或者说设备ID能力，设备唯一指纹。能够进行上传。设备内截图方案，我们有四种截图方案。在一个浏览器上，脚本监控是浏览器环境和调整浏览器插件的截图。如果说到底，淘系有两个主流，淘系就是淘宝。天猫能用Windone，意味着能用h5就具备了容器能力。支付宝可能是另一个自研容器。在容器环境中，我们会调动容器的能力。如果出现异常场景，上传有问题，我们会使用脚本库进行截图，纯脚本实现。通过底层，我们可以像人一样操作页面滚动和点击。结合我们的后台，我们有一些真机管理，常用的后台管理能力，然后调动各种算法的检测能力，实现手动和自动录音和回放。.刚才说了截图有四种场景，所以我们其实可以在浏览器或者任何移动端运行，但是在非容器能力的应用中，比如纯脚本的截图，可能是针对特别复杂的页面。因为脚本截图可能会有一些失真。我们在终端淘app上传，上传到我们图片空间管理，然后去国际站，AE可能要转海外基站，我们上传到阿里云OSS所在位置服务。刚才讲了自动调度，提高它的稳定性，可能是调度ATS自动调度的能力，然后整个跟业务方有这一套链接，有的在页面发布的时候调用我们，或者页面需要的时候一些在线检查的检查任务转移我们的时候，或者需要一些其他创新方案的时候，检查页面转移我们。现在我们接了任务，就是有一个订单，这两天反馈了一个问题。即使签署的订单可能是空白的，它也会转移我们。应用程序运行异常空白检测。这些是我们算法的能力。最终说明单机检测具有拼接狗和兔子的能力，也有陷阱。适配检测有个性化的数据和图片对比，因为不同账号或同一账号访问页面的时间不同。使用传统的录音和回放对比会有很大出入，然后检测异常字，会调用OCR能力，或者抓光，根据业务方不同的业务需求定制。我们来看一个实际的例子，就是材质贴图模块数量的变化。我们可能通过比较会发现，不会比较的人会看这个问题。还有就是产品和坑的自适应。产品坑的死宽导致模型宽度不同。有一个问题，是通过比较能力发现的。还有清坑能力，页面地图不加载，或者没有实时商品数据默认加载。然后是坑，也就是说当我们会场页面连续出现两三个产品坑的时候，或者是volume的坑缺失的时候，这也是业务场景需要关心的。还有同样的材质，就是我们只检测单品。如果单品有相同的推荐，相同的品牌或相同的产品，在我们的场景中，后台算法没有进行适当的打散，打散的逻辑有问题。他们也会关心空楼层的问题。有楼层名称，但没有下面整个楼层的数据。另外，异常词下的营销兴趣点为null，可能是后台没填或者前端拉取异常导致的。整个屏幕或大部分屏幕都没有数据，包括兴趣点的折叠。我们介绍其中一种算法，即图像与个性化块的比较。运行过程中，可支持登录自动化账号运行，但难免出现实际场景运行或同一账号异常的情况。这就是我们在做图像比对时需要解决的问题。问题。刚才说了我们整个实现是基于前端自适应，理想情况下可以100%完美，但是不同浏览器环境开发不同的问题，或者frame层面1px的适配差异导致累积转化，而GS转换有精度问题，会有细微差别。我们会先做一个翻译，就是找两张图片，通过一些转换找到相差最小的匹配位置。此步骤的目的是使高层与企业保持一致。我们要找的计算差异区域的位置就是两幅图像差异的部分。这里有噪音。我们执行形态学操作以获得主要差异区域。得到差异区域后，我们通过边缘检测找到图片的边缘，然后将差异较大的部分覆盖掉。我们在比较两张图片的时候，就是比较它们，然后计算它们的特征和相似度值。通过这个展示，可以比较出框架层面的差异和性格层面的差异。另外，因为刚刚看到了很多算法场景，所以我们也用到了特征点匹配，OCR，以及不同分类模型的训练，包括MobileNet。同时，由于插入页面的脚本与后台进行交互，因此脚本可以获得额外的一层信息，即页面的DOM信息。这意味着整个页面都有块级元素。这个在页面中的具体位置是什么，比如这里有一个商品坑，可以得到这个坑的大小，长宽，以及具体的top和left位置。有了这些信息可以进一步提高算法检测的准确性。我们的运营数据是这样的。如果人力适应投资测试过程，则主要参与启动阶段。上线前开发完，投入一轮不同的机器，看不同的效果。这个在上线阶段、测试阶段、bug修复阶段的任何一个阶段都可以实时运行，所以我们的页面覆盖率比它高很多。同时，因为我们的算法能力，我们帮助他发现了更多与经验相关的问题。这是去年六月的数据。人力投入是对当时设备异常掉线的场景进行维护，一部分投入是算法结果的人工确认。随着算法精度的提高和自动调度方案的改进，实际上还可以进一步降低。的。这就是刚刚演示的单日检测。它每两个小时运行一次，每小时运行一次，每天检测有问题的页面数量。我的演讲到此结束，谢谢大家！
