文娱妹导读
自动化测试能力建设过程中，自动化框架选型、框架设计核心和思路、自动化能力平台接入，是自动化测试能力建设过程中重要环节。文章分享优酷APP自动化测试能力建设过程中的经验
本系列文章将陆续发布，感兴趣的朋友持续关注！

前言

随着移动端版本迭代的加快，快速测试，快速反馈已经是一个常态化的流程，周期内版本发布频率的增加，各项测试的时间正在急剧缩短，且回归性的任务不断充斥当中，各个阶段都需要回归测试的介入来确保集成之后各个模块的正确性。

在当前回归测试中主要集中以下几个痛点问题：

测试回归主次模糊，抓不住回归重点的内容，导致在较短时间内很难完成大量的回归case
回归用例基本大部分都是靠手工执行，重复性工作较多，回归效率低下
各个业务团队或多或少都有一些自动化的研究和接入，但开发的工具本身都是各自为战没有起到互相配合&互相补充的作用，无法实现工具红利。

基于客户端的自动化能力进行测试框架的封装，实现脚本编写&执行与平台无缝对接，并且结合了业务场景进行平台自动化能力的落地，同时统一自动化框架的开发以及核心case用例的整合，使得整体回归测试成本降低。

客户端自动化基础能力

自动化测试驱动选型

在这里插入图片描述

如何选取一款自动化测试框架呢？

一款好的测试框架具备这样几个特征：
双端一致性，也就是说ios和android可以在同一框架下编写用例，提高脚本开发效率；
运行稳定性，对UI自动化本身存在不稳定性，框架需要运行稳定才能更好的支持测试；
简单易用，框架接入本身需要简单易懂降低入门的门槛，方便快速使用；
低耦合性，各个层级保持低耦合性来降低脚本的维护成本，高扩展性指的是方便与平台的对接能力和脚本调用能力。

自动化测试框架设计

核心场景自动化结构设计主要分为3层:最下层为驱动能力，提供核心驱动力和操作的能力，维护整个case执行的生命周期。

中间层是框架封装层，直接依赖Driver层，提供通用basecase的入口和工具类的使用，以及业务通用能力抽象。最上层为TestCase直接依赖框架封装层，封装业务逻辑以及testcase的编写，层级之间相互解耦，层层依赖。
在这里插入图片描述
框架层结构，主要分为4大块内容：

第一部分为Framework_Core，这部分主要是围绕着BaseCase进行的扩展， Basecase作为framework的入口，是所有case的父类，遵循框架的生命周期持有driver对象
第二部分是Device_Config,这里主要初始化一些设备和配置信息，例如deviceid、pkgName等
第三部分utility，这部分是工具类的封装，包含图像相关的处理，路由跳转功能。丰富的util类目的是让测试case的验证更加全面准确。
第四部分是Report.这块主要是测试报告的生成，生成对接平台标准化的报告结果

框架Log体系&Check体系&基础操作封装

框架中还封装了完整的Log体系，主要用于测试过程trace的追踪和测试报告的生成。Log体系主要包含：

添加case步骤
添加截图
添加验证点
添加操作动

除了Log体系外，business logic还封装了check体系，check体系主要包含元素检查以及页面布局检查，check内容例如：check元素是否为空、字符串是否相等、元素文本是否为空以及两张图片相似度等，完善的check体系可以增加case的验证内容，比断言的方式更加贴合UI自动化的使用。

框架中还封装了BaseOperation基础操作，例如：pageSwipe 会按照屏幕尺寸进行页面的滑动，确保case在不同设备上滑动幅度相同，ModuleSwipe可根据传入element范围内进行滑动，入参包括滑动方向、滑动幅度以及滑动次数等，提供基础的操作内容方便上层脚本更加顺畅的调用。

图像识别能力

在随着框架基础能力的封装完善，只满足传统UI自动化使用已经限制了自动化本身的覆盖度，局限性也比较大。目前可以通过数据和图像两个方面的补充使传统UI自动化扩展性更好一些。

数据方面主要指是自动化测试的一些input数据内容例如mock数据的设置等，另一方面就是图像，自动化测试框架也封装了图像相关的api进行补充完善。

在图像方面框架还有截图处理的能力，例如：截图标记的功能，可以完善测试报告，增强排查手段，如下图所示，当传入check元素后进行截图，截图图片上会自动标记出校验的区域或者元素，框架还支持图片剪裁的能力，主要是方便支持区域OCR识别以及图片相似度对比的验证。最后还支持图片的翻转能力，这块主要是为了解决iPad转屏后截图不正，影响图像识别准确性的问题。

在这里插入图片描述