一、 概述
背景
每个版本都需要执行大量的老功能回归Case，重复工作量较大
随着App功能的逐渐增加、回归测试点逐渐增多，在保证测试覆盖度的前提下，整体的回归测试时长在增长，增加了测试压力
在针对老功能回归测试的过程中，因回归测试点比较多，可能存在测试点漏测的情况
目标
覆盖大部分的回归测试Case，帮助大家执行部分功能的回归测试，减少回归测试的人工成本
利用UI自动化测试 自由分配、随时可执行的优势，增加已有功能的测试频率，在版本开发工程中，尽早发现因新更改影响已有功能的情况
不局限于已有功能的验证，利用UI Case的操作场景，在执行过程中进行其他数据的收集，供其他测试类型使用
对线上已发布的版本，进行主流程功能监控
二、 框架介绍
1、UI自动化框架
UI自动化测试框架有很多，基于以下几点考虑，选择使用Appium框架
转转Android & iOS 的App功能交互&设计始终保持一致，使用Appium可以保证一套操作逻辑，两端都可以使用，减少Case创建&维护成本
Appium支持 Native 、Webview 、混合页面的测试
属于外部测试框架、结合支持多种语言的优点，更方便扩展使用
2、UITest框架结构
框架是UI的基础，框架的稳定及易用，决定了UI自动化的整体流程的效率及稳定
3、业务Case
结构
参考PageObject设计模式，将Case的结构进行拆分管理，解耦的同时，更便于维护
case存放位置
app业务
属于基础业务，存放在UITest框架内部，可供其他业务使用部分已封装好的操作场景
其他业务
为了支持多业务使用框架，避免共同在单一工程中维护代码时互相影响，对框架进行了扩展支持
每个业务可以单独新建独立的工程进行Case的编写及维护。只需将UITest框架放置在工程内，将保存测试集的suite文件通过传参 或 在suite文件中调用UITest执行接口，就可以触发执行
4、测试结果
本地存储
存储位置：每次执行都会在工程-report目录中创建独立的文件夹存储测试结果
存储内容：设备执行Log（框架执行过程中的log，非设备本身的log）、失败Case截图、便于汇总查看的报告文件（html）
线上存储
每次的执行结果都会上报结果平台，存到数据库中，便于查看历史记录及详细的执行数据
三、 UI自动化进化过程
1、控件定位方式
iOS Native控件定位方式
初期：主要以XPATH为主 + Text 的方式定位控件，XPATH 定位较慢，App布局改变后需要重新维护
RD帮助补充 控件 NAME属性后：将主要使用XPATH的方式定位，更改为主要使用NAME & Text的方式,降低了控件定位耗时，降低了Case执行耗时
图像识别 方式扩展
初期：iOS和Android存在大量的共用图片、每个控件基本只有一张图片，在不同分辨率的设备上得到的相似度不同，会影响匹配结果判断
为每个平台创建单独目录保存图片：避免相同控件在不同平台上，图像略有不同，不能使用同一张图片识别
同控件根据不同分辨率，分别截图取样：定位控件时，先计算设备分辨率，优先查找同分辨率的图片样本进行识别
通过图片名称查找图片样本：没有通过分辨率查找到对应图片样本后，根据图片名称查找通用图片
支持Webview 控件
初期：只执行了Native 控件的识别及操作
现在：增加多种Webview定位方式的支持，从而增加了对M页功能的较好支持
2、控件操作方法
验证控件是否存在
图像识别
初期：只根据Element中存储的完整图片名称，查找图片
现在：Element中存储的为图片名称关键字，根据平台查找平台目录，优先根据分辨率+名称查找图片样本，未找到再根据图片名称查找
iOS控件增加实际显示位置判断
初期：通过Text/Name 定位的控件，与page_source对比，根据enable & visible的值，判断是否可用，其他定位方式通过Driver.find，查找到就认为可用。实际上Appium 执行时获取iOS的page_source并不稳定，发现同一页面，有时可以获取到iOS 中 当前页面已加载出的所有控件（包含为显示在屏幕区域内的），并不能进行有效操作，并且有些被Tab Bar由于被遮挡而不能正常操作到
现在：增加控件位置的计算、判断是否在屏幕可操作的区域内，若不在有效区域内，虽然可定位到，但因不可操作，也认为其不存在，配合滑动操作，将控件滑动到有效区域再操作
点击方法扩展
初期：只支持Native控件的点击操作
扩展支持WebElement类型
添加专项数据收集支持
滑动方法优化
根据设备屏幕分辨率，计算准确的坐标值，进行滑动
解决iOS滑动不好控制的问题，较好的控制滑动幅度
3、执行策略
触发方式扩展
初期：执行参数较少，基本只在配合CI时使用，本地多数还是直接运行UiTest.py触发执行的方式
扩展更多的执行参数，更自由、方便的控制执行配置，也可以较好的为外部的其他脚本／平台提供支持
封装执行接口函数，供外部工程调用框架执行时使用，参数与命令行参数一致，
多平台同时执行
解决多平台依次执行，整体时间过长，效率比较低的问题
Android ／ IOS 使用不同的预设起始端口启动Appium，互相不冲突
使用多进程的方式，每个平台启动一个单独的进程用来启动Case执行
利用执行参数 –o 或者 修改config中的optionsystem，控制当次执行时使用的平台
多平台多设备同时执行相同Case
在进行功能测试的同时进行兼容性测试
在每个平台进程内，根据设备列表，为每个设备分配Appium端口，互不冲突
为每个设备再启动一个进程，独立执行Case
每个设备单独统计测试结果、保存、发送报告
利用 –d 参数可以控制使用的设备
多平台多设备分配Case执行
Case 量越来越多，单设备全量Case的执行时长越来越长，多设备分配Case执行，可以提高执行效率、缩短整体耗时
根据Case列表筛选出每台设备都需要执行的初始化Case及 需要分配的Case集，结合设备列表，分配Case集，为每一个设备创建独立的testsuite文件
为每个设备分配一个进程，执行对应的testsuite
当同平台的所有设备都执行完后，以平台为维度，进行结果汇总，保存结果、发送报告
利用 –g 参数可以控制是否分配Case执行
4、整个框架执行逻辑对比
初期：
现在：
5、UICase筛选依据
UI自动化 Case 并不能保证100%的覆盖所有的功能Case，在不同的阶段的Case筛选依据会有所不同
建设初期（欠债）阶段：以回归测试的CheckList为依据，根据功能模块的重要性，设定优先级，逐步添加Case
参与版本周期（进度持平）阶段：新功能Case的添加，优先以冒烟测试用例为依据，筛选出UI Case 覆盖范围，再添加额外的Case
四、未来
在Case可覆盖功能 、执行策略等方面，现有的UITest框架均已满足了基本需求，可稳定使用，后续的工作都为扩展，目的是增强UI 自动化的作用，利用UI自动化做更多的事情
利用UI Case ，获取更多的数据，驱动更多种类型的测试
可视化查看、操作、控制UI 自动化 及相关测试的进行
持续集成、与CI结合、更自由、敏捷的执行
