1、UI自动化的作用和意义是什么
又回到这个最开始我们做UI自动化的初衷，不管是为了自动化而自动化、还是提高自己的技术能力、亦或者是为了提高自己的工作效率，既然我们开始做自动化后，就应该在做的时候去反思，为什么要去做自动化，自动化是否真的为我们提升了效率，以及怎么完善自动化的流程步骤。
自动化的目的：
毫无疑问自动化本身是为了代替频繁而且重复的人工操作，从而提升效率，实际应用中一般作为回归测试的一个实现工具。
2、如何去推动和落地自动化？
做UI自动化之前的考量：
这里依旧要重申一下，做UI自动化需要满足的条件，我个人觉得要做这个对于项目以及人员的要求都蛮高的，所以这也是ui自动化经常失败的原因，这里我觉得在做自动化之前要考虑好项目本身以及项目组测试成员能否满足自动化的需要。
1.项目要求：
需求相对稳定
重复任务较多
项目开发周期长
2.人员要求以及工作量安排
代码能力
人员充足与否
工作量任务安排
3.测试项目组要求：
项目测试评估：
当前项目的测试覆盖率、测试质量以及测试工作投入
加入自动化后的测试覆盖率、测试质量以及测试工作投入
自动化的发起人、负责人以及目的
自动化测试的推进：
目前的测试用例、以及需要做自动化的用例，需要讨论分析，哪些些用例需要做自动化，做了自动化后的工作量和测试安排、对测试进度和项目进度的影响。
1.确定测试用例
在评估确定好要做自动化后，第一步是确定我们的自动化用例，需要测试的项目组一起把当前项目用例拿出来，评估哪些用例需要做自动化，自动化用例的选择标准是什么。第二步就是确定自动化的实现方式，使用哪儿种框架来实现自动化。
2.工作量安排以及项目协调
确定好用例以及实现方式后，需要安排测试小组进行自动化编写。一般来说需要一个核心测试开发，来主要负责框架的搭建以及相关功能的补充，其他人员主要负责case、page具体用例的实现。
在制定自动化计划时，也要考虑到项目当前的测试工作量和测试效果，在满足基础手工测试的基础上进行自动化的工作安排。
3.定期回归用例
在第一批用例编写完成后，接下来就是定期维护和检查用例，比如页面元素的调整、需求功能的更改，都会需要再次调整用例。这个时期如果要考虑增加用例，需要谨慎一些，因为如果自动化用例增加太多，也会导致维护成本的增加，可能大部分时间用来维护甚至重写用例，反而会本末倒置。
3、UI自动化优缺点以及应用场景
优势：
自动化测试可以代替大量的手工机械重复性操作，测试工程师可以省下大量的时间来设计测试用例和新功能。
自动化测试可以大幅度提升回归测试的效率，非常适合敏捷开发。
自动化测试可以充分利用无人值守时间，来进行测试，特别是非工作时间执行，工作时间只需要分析一下测试的执行结果。
自动化测试可以高效的实现某些手工测试无法实现的或者代价巨大的测试。例如，关键业务7*24小时稳定性测试测试。
自动化测试还可以保证每次测试的
劣势：
并不能取代手工测试。
无法应对被测系统的变化。
开发工作量大，只有执行次数大于等于5次之上时，才能回收成本。
仅能发现回归测试的缺陷。
不稳定
用例开发效率低，后期需要重构。
业务测试人员和自动化测试人员是两批人。
使用场景：
需求稳定，不会频繁变动的场景。
研发和维护周期长，需要频繁执行回归测试的场景。
需要在多个平台上重复运行相同测试的场景。
通过手工测试无法实现或成本太高的场景。
被测软件开发较为规范，并且能够保证系统可测试性的场景。
测试人员已经具备编程能力的场景。
适合做UI自动化的场景
一般来说有3种场景是比较适合做UI自动化的：回归验证、巡检、移动端埋点测试。
1）回归验证
项目上线或者APP发版，传统的手工测试耗时较多。一到上线发版日，尤其是改动较大的发版，同事们都是采用手工用例走查的方式去进行验证回归，压力非常大！
当时一般一次上线回归验证，基本上都要花费30分钟-2个小时，对于测试人员和开发人员来说，都是一种煎熬。
有时候人手不够了，还需要产品、运营一块协助回归验证，效率十分低下。
这个时候，可以用UI自动化去覆盖一些功能改动较少的功能。
2）巡检
线上环境复杂，容易出现各种意想不到的问题，而手工巡检测试压力大。
比如：
运营配置错误；
用户的一些非常规的操作；
不同手机终端的兼容性问题。
这些问题从暴露给用户，到反馈到开发这边，再到开发修复解决，可能都已经过去很长时间。
以往，同事一般会定期人工线上巡检去发现一些线上问题。
这么做确实也有效果，但问题在于：
人工巡检也会耗费不少测试时间，有时候忙起来，就很难坚持执行下去。
这个时候，可以用UI自动化去覆盖一些主流程，确保主流程不要出问题。
3）移动端的埋点测试
如果一直做简单且重复性高的测试工作，不仅效率低，也非常严重打击测试人员的工作积极性。
最典型的就是移动端的埋点测试，传统的测试方法，就是在手机上操作，触发埋点上报，然后通过手机抓包，获取埋点数据，然后再依据埋点文档，去对每个字段进行一一人工校验。
这一通操作很无脑，但是实际上花费的时间是相当多的，埋点需求一多起来，可能测一天都测不完，还非常消磨测试人员的精力：每次测试完埋点，都感觉自己的视力下降了很多（对数据废眼）。
这个时候，可以尝试用UI自动化去自动触发埋点，并通过一些校验逻辑，对埋点进行自动校对。
4）除此之外，UI自动化还可以解决：
APP 兼容性测试
APP 竞品对比测试
APP 数据抓取
4、APP UI 自动化框架设计思路
目前APP UI自动化框架存在的一些问题和解决思路：
要提高 UI 测试稳定性，首先我们需要知道到底是什么原因引起的。尽可能的找出那些引起不稳定因素，然后找到相关不稳定因素对应的解决措施。
1、page Object设计模型
（1）PO是什么？
[1]. PO(Page Object)页面对象模型，是一种设计模式，用来管理和维护一组web元素的对象库
[2]. 在PO模式下，应用程序的每一个页面都有一个对应的page class
[3]. 每一个page class维护着该页面的元素集合和操作这些元素的方法
（2）PO的优势
[1].PO提供了一种业务流程与页面元素分离的模式，这使得测试代码变得更加的清晰
[2].页面对象与用例分离，使得我们能够更好的复用对象
[3].可复用的页面代码会使的我们的代码风格更加的优化
PO模型参考文档：
https://blog.csdn.net/Q0717168/article/details/120942175?utm_source=app&app_version=5.5.0
2、UI自动化常见问题，总结了以下几种原因：
操作界面非预期的弹框、广告、浮层
页面元素发生了变化
测试数据原因
页面控件点击失效或者未加载出来
测试系统的 A/B 策略
操作界面非预期的弹框、广告、浮层
系统层面、第三方软件一些意外弹框，例如第三方软件的广告、系统权限提示、系统更新提示
解决方案：
关闭系统更新、浏览器更新
尽量不要安装非必要的第三方软件，目前第三方软件常用推送广告
保证测试机器干净，减少非必要的异常出现
3、测试软件本身弹框，例如详情页根据用户画像，自动推送一些广告弹框，这种一般很难知道在什么时候会出现，导致测试用例执行不成功
解决方案：
增加黑名单机制，将遇见过得弹框都记录到黑名单里面，在元素定位封装时增加黑名单判断
自动失败异常弹框算法
增加用例失败重试机制，结合上面两种方案
4、页面元素发生了变化
页面增加新功能，导致页面元素发生改变
解决方案：
尽量不要使用元素本身的ID、name、class定位，尽量使用xpath定位方式
采用模糊匹配
采用组合定位策略
5、开发修改了元素名称(公司将前端改写成了vue)
解决方案：
使用不改变的值进行定位，例如控件的文本，例如不管怎么改，登录 文案不会改变
6、如果是页面改版，就需要修改定位
终极解决方案：
定时扫描页面元素是否发生改变，使用page_source获取页面元素分析，一旦改变是否影响用例执行，及时修改用例
7、测试数据原因
主要是用例执行的前置操作未完成，例如用例依赖前面用例执行产生数据或者已有历史数据被其他人删除
解决方案：
可以通过 API 生成数据
通过 数据库 生成数据
通过 API 和 数据库 造数据效率比较高且准确，前提对于相应数据库结构和api需要比较熟悉
8、页面控件点击失效或者未加载出来
网络或者服务器偶尔响应比较慢
解决方案：
脚本增加智能等待
脚本增加重试机制
9、页面控件元素点击无效
解决方案
增加异常处理，是否点击操作太快、元素是否可见、元素被遮挡等处理
可以增加1-2次重复点击，例如第一次点击失败，再点击一次
使用js定位操作
10、测试系统的 A/B 策略
由于公司运营活动，每次选择不同的城市进行，导致同一个城市不同时间看见页面不一样，效果也不一样
解决方案
测试用例编写兼容处理，根据不同时期，拿到活动标识，调用不同逻辑进行处理
总结：
操作界面非预期的弹框、广告、浮层，主要采用方案：保证测试机器干净、关闭系统更新和增加黑名单机制、自动失败异常弹框算法、失败重试机制
页面元素发生了变化，主要采用方案：采用模糊匹配、使用xpath定位、采用组合定位策略、使用page_source获取页面元素分析元素是否发生改变
测试数据原因，主要采用方案：通过 API 和 数据库 造数据
页面控件点击失效或者未加载出来，主要采用方案：增加智能等待和重试机制、增加异常处理、使用js定位
测试系统的 A/B 策略，主要采用方案：测试用例编写兼容处理
5、UI自动化用例设计思路与原则
1) 一个脚本是一个完整的场景，从用户登陆操作到用户退出系统关闭浏览器或关闭app
2) 一个脚本脚本只验证一个功能点，不要试图用户登陆系统后把所有的功能都进行验证再退出系统
3) 尽量只做功能中正向逻辑的验证，不要考虑太多逆向逻辑的验证，逆向逻辑的情况很多（例如手号输错有很多种情况），验证一方面比较复杂，需要编写大量的脚本，另一方面自动化脚本本身比较脆弱，很多非正常的逻辑的验证能力不强。（我们尽量遵循用户正常使用原则编写脚本即可）
4) 脚本之间不要产生关联性，也就是说编写的每一个脚本都是独立的，不能依赖或影响其他脚本。
5) 如果对数据进行了修改，需要对数据进行还原。
6、UI自动化一些常用框架
1、selenium web自动化
2、appium iOS 安卓，跨平台
3、Airtest iOS 安卓，跨平台，图像识别
4、facebook-wda iOS
5、uiautomator2 安卓
每个框架的优缺点可自行查找资料
7、iOS自动化框架技术选型
项目选型
在 APP 的UI自动化领域，近几年涌现了很多很多优秀的 UI自动化测试框架（工具）。
比如：Appium、Robotium、Instrumentation、UIAutomator、ATX、Airtest等等。
因为团队内的小伙伴，基本上都是 Pythoner，所以我们在测试框架选型时，优选考虑对 Python 有良好支持的框架。
经过一轮对比，发现 Appium 和 ATX 对 Python 的支持比较好，并且都有 Android 和 iOS 的成熟解决方案。
所以后面决定在 Appium 和 ATX 之间进行选择。
以下是Appium和ATX的一些对比情况：
Appium 安装部署相对来说比较复杂、项目启动和运行比 ATX 稍微慢一些（框架比较重）、Appium 配置比较繁琐。
所以我们逐步放弃了 Appium，最终采用 ATX 进行 UI自动化工程的搭建。
这里可以再简单介绍一下 ATX 的生态圈：
可以看出来 ATX 还是很强大的，项目也在不断维护和更新。
不过，光有底层的UI自动化驱动框架还不行，你还得需要有专业的测试框架来管理你的自动化测试项目（用例）。
pytest 和 unittest/pytest 是最流行的解决方案。
我们欣喜的发现，在GitHub上已经有人把脚手架工程给做出来了：ATX-Test。
ATX-Test是基于ATX-Server的UI自动化测试框架，可以实现多设备的并行测试，并生成统一的测试报告。
采用的技术栈包括：
8、 iOS UI 自动化框架
1、项目名称：hago-iOS-uiauto
框架：python + pytest + facebook-wda +weditor + allure + jenkins + git
项目代码地址：https://...
相关参考文档：
使用facebook-wda进行iOS APP自动化测试
https://blog.csdn.net/QQqun810119819/article/details/120939806
Windows上实现iOS APP自动化测试
https://blog.csdn.net/u010698107/article/details/119492403
iOS自动化环境搭建步骤：
iOS 设备安装 wda（安装 webdriveragent ，要用xcode，打包）
优缺点：（同样适用接口自动化框架）
优点：1、灵活，可根据需要进行二次开发和封装2、数据驱动，测试数据与脚本分离
3、用例编写方便
4、充分利用现有资源
5、落地周期短
缺点：
1、门槛稍高，需要会代码与测试平台对比：1、第三方测试平台有可能会涉及数据安全2、开源测试平台，后期有可能收费，不开源
3、自己开发测试平台需要开发水平较高，专门由测试开发人员进行开发和维护，投入较高
4、方案落地周期长
建议：
1、不必过于纠结框架选型，以项目快速落地，能够跑起来，实现自动化为目标，只有经历用过，踩坑之后，才会有自己的一些心得，这时候可以去横向对比一些框架的优劣势
2、多查资料，多交流
结合自身项目应用场景：
1、BVT用例回归（整理出适合UI自动化用例）
2、性能专项测试（多次重复场景）
9、安卓自动化框架技术选型
工具地址：http://....:8080/
项目名称：hago-android-uiauto
框架：python + pytest +uiautomator2 +weditor + allure + jenkins + git
项目代码地址：https://mayuchao/android-uiauto.git (后期提供github地址)
参考文章：
https://blog.csdn.net/lovely_pigpig/article/details/116939757?utm_source=app&app_version=5.5.0
10、落地后的维护以及对框架优化的思考
1、用例如何管理和维护
2、测试人员对自动化投入的时间和产出收益如何
3、不懂代码的测试人员如何去做自动化
4、如何优化自动化测试时间，考虑ATX2-server集群 + 多进程程方式
5、测试用例执行通过率不是100%的情况，怎么处理
1）通过断言机制甄别报错信息，是程序自身错误还是bug导致
2）失败case结合人工验证的方式确认
3）经常失败的case需考虑优化，或者去掉这个case，复杂的场景不适合自动化
11、测试平台的应用
1、ATP一体化测试平台
支持web、app、接口自动化
开源，近两年没有维护
项目地址：https://github.com/ooqitech/ATP
2、opendx参考文章：https://www.jianshu.com/p/ac801fc6e884
项目地址：https://github.com/opendx
3、metersphere
支持接口自动化，性能自动化4、httprunner，支持接口自动化
5、APifox，支持接口自动化
6、YApi，支持接口自动化
7、luckyFrame，支持接口自动化
8、sosotest，支持接口自动化
9、LynTest，支持接口自动化
10、httprunner，支持接口自动化
