项目背景分析

UI自动化测试，即通过模拟手动操作用户UI界面的方式，以代码方式实现自动操作和验证的一种自动化测试手段。如今互联网的主战场已经从web端逐渐过渡到了app端。现在，app在UI自动化方面的框架已经比较成熟，目前我选择的是Appium，今后也会对网易Airtest进行调研推广

UI能解决什么问题？

• 重复性的功能测试及验证
• 避免疲惫操作时的人为测试遗漏
• 线上功能的稳定性72小时回归

UI的优缺点是什么？

•   在实际应用中，UI自动化可以帮助我们节省人工测试成本，提高功能测试的测试效率。
•   缺点也是比较明显，随着敏捷迭代的速度越来越快，UI控件的频繁变更导致控件定位不稳定，提高了用例脚本的维护成本，同时定位的不稳定导致用例的可信度降低。

UI的应用场景

•   主要应用于冒烟测试、回归测试、Dailybuild等阶段。

UI存在的意义

•   存在即合理，软件测试的金字塔模型告诉我们越是底层，用例的执行速度越快，维护成本越低。到了最上层的UI时，执行速度处于比单元测试、接口测试慢，比手工测试快的这种阶段。维护成本上比单元测试，接口测试要高。

那么为什么需要做UI自动化呢？

• 实施起来较容易：刚开始接触测试自动化时，都是先接触UI的自动化。UI的框架比较成熟，容易上手，相关学习文档比较全面。实施起来一般都不依赖于源码，是比较容易落地的一种自动化测试手段。
• 覆盖范围广：UI上的一次操作的函数触发数量可能会非常多，相比较而言更贴近模仿用户的真实体验操作

需求背景

• 每个版本都需要执行大量的老功能回归Case，重复工作量较大
• 随着App功能的逐渐增加、回归测试点逐渐增多，在保证测试覆盖度的前提下，整体的回归测试时长在增长，增加了测试压力。在针对老功能回归测试的过程中，因回归测试点比较多，可能存在测试点漏测的情况

目标

• 覆盖大部分的回归测试Case，帮助大家执行部分功能的回归测试，减少回归测试的人工成本
• 利用UI自动化测试 自由分配、随时可执行的优势，增加已有功能的测试频率，在版本开发工程中，尽早发现因新更改影响已有功能的情况
• 对线上已发布的版本，进行主流程功能监控

技术方案

1. 用例编写简单，降低上手门槛
由于测试人员的代码编写能力参差不齐，让业务同学可以快速上手编写是基本诉求。封装基本操作，测试人员无需关心底层实现，直接调用封装好的API即可

2. 降低用例维护成本

• 当UI控件发生改动时，我们需要对对应的控件定位方式进行修改。一般地，一个控件会被多条甚至几十条用例引用到，那么维护成本与引用数量成正比，引用的地方越多，维护成本越大。如何降低控件修改成本是非常关键的。
• PO模型搭建，将定位元素、元素操作、测试用例分层处理，解决UI自动化的元素经常变换导致代码失败率高的问题把一处控件改动对应多处引用修改的一对多关系变为一对一关系，即无论引用了多少处此控件只需要修改一处代码。

3. 失败重试机制，提高用例稳定性
由于用例执行的稳定性直接决定用例在业务落地时的可信度，所以提高用例稳定性是必要的，框架提供了失败重试的机制来间接保证稳定性。即当监听到用例执行失败异常时，重新执行当前用例逻辑，如果执行成功，覆盖当前用例的执行结果；如果失败，重新执行，直到超过重试次数。

4.协助快速定位问题的能力 
框架提供了日志和失败时截图进行分析和定位问题的能力。

5.数据统计的能力
框架提供了提供了最终执行报告，详细记录最近10次的执行结果和报错截图

6.Appium并发
在每个平台进程内，根据设备列表，为每个设备分配Appium端口，互不冲突为每个设备再启动一个进程，独立执行Case，并发跑脚本得到最终结果。多平台多设备同时执行相同Case，在进行功能测试的同时进行兼容性测试（这里这边管理方案暂时采取TotalControl实现，后期搭建STF多设备兼容性平台）

7.结果通知
执行结果后通过邮件的方式发送最终的结果，日常回归时发现BUG集成微信平台实现实时报警

8. UI测试对接CI平台
与jenkins结合、更自由、敏捷的执行，设立每日回归场景，版本测试场景，功能覆盖场景通过jenkin、配置自动化执行，使用场景如每天下班时自动跑一下用例，或者当研发打了新包后自动开始运行测试脚本测试新包，下班或周末采用多设备兼容性测试。
 实现目标