别再问我，UI自动化测试怎么做了……
本文关键词：移动端UI自动化思路
大家好，我是小码哥。之前测试交流群里有同学问“有没有自动化测试在工作中的案例可以分享“，有是有的。
今天我会详细的描述一个【UI自动化实战在实际工作中的应用】，这是之前贝壳找房我们团队做的一个真实UI自动化案例，由于APP版本更新迭代太多次，代码也有缺失，所以一些细节没法完全描述清楚。
但我会把做这个项目的思路和流程，详细的分享出来，希望能帮到大家。
本文干货预警，全文5300字，预计阅读时间14分钟。
目录
一、自动化测试的主要分类
二、适合做UI自动化的场景
1）【回归验证】
2）【巡检】
3）【移动端的埋点测试】
三、UI自动化实战案例
1）项目背景
2）项目选型
3）开始安装部署
4）执行测试方案
四、对UI自动化的思考
五、自动化测试学习资源分享
一、自动化测试的主要分类
自动化的形式主要可以分为接口自动化和UI自动化。
根据测试金字塔理论，越往顶层，ROI（投入产出比）就越高。
一般大家都会加大力度投入到接口自动化的建设当中，而UI自动化因为投入产出比太低了，所以基本上对UI自动化的建设会投入比较少。
但这并不代表UI自动化就完全没有必要做，在下边部分我会列举3种【适合做UI自动化的场景】。
二、适合做UI自动化的场景
一般来说有3种场景是比较适合做UI自动化的：回归验证、巡检、移动端埋点测试。
1）回归验证
项目上线或者APP发版，传统的手工测试耗时较多。一到上线发版日，尤其是改动较大的发版，同事们都是采用手工用例走查的方式去进行验证回归，压力非常大！
当时一般一次上线回归验证，基本上都要花费30分钟-2个小时，对于测试人员和开发人员来说，都是一种煎熬。
有时候人手不够了，还需要产品、运营一块协助回归验证，效率十分低下。
这个时候，可以用UI自动化去覆盖一些功能改动较少的功能。
2）巡检
线上环境复杂，容易出现各种意想不到的问题，而手工巡检测试压力大。
比如：
-
运营配置错误；
-
用户的一些非常规的操作；
-
不同手机终端的兼容性问题。
这些问题从暴露给用户，到反馈到开发这边，再到开发修复解决，可能都已经过去很长时间。
以往，同事一般会定期人工线上巡检去发现一些线上问题。
这么做确实也有效果，但问题在于：
人工巡检也会耗费不少测试时间，有时候忙起来，就很难坚持执行下去。
这个时候，可以用UI自动化去覆盖一些主流程，确保主流程不要出问题。
3）移动端的埋点测试
如果一直做简单且重复性高的测试工作，不仅效率低，也非常严重打击测试人员的工作积极性。
最典型的就是移动端的埋点测试，传统的测试方法，就是在手机上操作，触发埋点上报，然后通过手机抓包，获取埋点数据，然后再依据埋点文档，去对每个字段进行一一人工校验。
这一通操作很无脑，但是实际上花费的时间是相当多的，埋点需求一多起来，可能测一天都测不完，还非常消磨测试人员的精力：每次测试完埋点，都感觉自己的视力下降了很多（对数据废眼）。
这个时候，可以尝试用UI自动化去自动触发埋点，并通过一些校验逻辑，对埋点进行自动校对。
4）除此之外，UI自动化还可以解决：
-
APP 兼容性测试
-
APP 竞品对比测试
-
APP 数据抓取
-
...
如果你还有更多的UI自动化实践案例，欢迎评论区交流。
三、UI自动化实战案例
目录如下：
1）项目背景
2）项目选型
3）开始安装部署
4）执行测试方案
1）项目背景
之前我还在贝壳找房的时候，随着公司业务的不断增长，APP功能越来越多，每一次APP大发版，测试人员都需要花费比以往更多的精力去进行线上回归验证。
据统计，我们部门目前线上回归验证的手工用例数大概在1000条左右，如果全部用例都需要进行回归测试，需要花费至少2个小时才能完成，这无疑给APP的测试同学带来极大的挑战。
如果用例回归不充分，把Bug遗留到生产环境上，将会给用户带来不好的体验。
传统的手工测试，已经很难满足日常的测试需要，我们发现，不少用例其实是可以通过自动化的形式去实现的，这将大大缓解APP测试同学的压力。
下面给大家展示部分“手工用例”转换成“自动化“的表格截图，虽然方法很笨，但是我们当时就是这么来统计自动化的场景覆盖率的。
既然用例已经梳理清楚了，我们就开始准备着手开发UI自动化框架和脚本了，从头开发肯定是不可能的，实际工作中没有那么多时间去重复造轮子，所以我们首先要做的，是要选一个好的轮子，然后在此基础上去做开发。
2）项目选型
在 APP 的UI自动化领域，近几年涌现了很多很多优秀的 UI自动化测试框架（工具）。
比如：Appium、Robotium、Instrumentation、UIAutomator、ATX等等。
因为团队内的小伙伴，基本上都是 Pythoner，所以我们在测试框架选型时，优选考虑对 Python 有良好支持的框架。
经过一轮对比，发现 Appium 和 ATX 对 Python 的支持比较好，并且都有 Android 和 iOS 的成熟解决方案。
所以后面决定在 Appium 和 ATX 之间进行选择。
以下是Appium和ATX的一些对比情况：
项目开始初期，我们也同时搭建了 Appium 和 ATX 的运行环境。
后来因为 Appium 安装部署相对来说比较复杂、项目启动和运行比 ATX 稍微慢一些（框架比较重）、Appium 配置比较繁琐。
所以我们逐步放弃了 Appium，最终采用 ATX 进行 UI自动化工程的搭建。
这里可以再简单介绍一下 ATX 的生态圈：
可以看出来 ATX 还是很强大的，项目也在不断维护和更新。
不过，光有底层的UI自动化驱动框架还不行，你还得需要有专业的测试框架来管理你的自动化测试项目（用例）。
pytest 和 unittest 是最流行的解决方案。
我们欣喜的发现，在GitHub上已经有人把脚手架工程给做出来了：ATX-Test。
ATX-Test是基于ATX-Server的UI自动化测试框架，可以实现多设备的并行测试，并生成统一的测试报告。
采用的技术栈包括：
既然已经有比较好用的项目了，我们直接在该框架下进行二次开发就好了，避免重复造轮子。
ATX-Test目前不支持iOS，我们在二次改造的时候，就可以把 facebook-wda的驱动给集成进去。
3）安装部署的步骤
使用ATX的前提条件有：
Python 运行环境（Python 3.6+ (社区反馈3.8.0不支持, 但是3.8.2支持）
Android版本 4.4+（需要安装uiautomator2）
iOS（需要安装 facebook-wda）
安装部署步骤
第一步，安装uiautomator2
（适合 Android）
pip install --upgrade --pre uiautomator2
对 Android 手机进行初始化
# init 所有的已经连接到电脑的设备
python -m uiautomator2 init
# 高阶用法
# init and set atx-agent listen in all address
python -m uiautomator2 init --addr :7912
关于 u2 的详细使用文档，可以参考：
https://github.com/openatx/uiautomator2
此处不再赘述。
第二步，安装 weditor
pip install -U weditor
启动 weditor
python -m weditor
weditor 可以抓取安卓控件元素、自动生成脚本代码并进行Debug。
第三步，安装 facebook-wda（适合iOS）
需要 MacOS 运行环境，并且需要安装 Xcode。
打包 WebDriverAgentRunner
xcodebuild -project WebDriverAgent.xcodeproj -scheme WebDriverAgentRunner -destination 'platform=iOS Simulator,name=iPhone 6' test
WDA在真机上运行需要一些配置，可以参考这篇文章：
ATX 文档 - iOS 真机如何安装
WebDriverAgent：
https://testerhome.com/topics/7220
配置完之后运行下面的命令即可（需要用到Mac的密码，以及设备的UDID）
# 解锁keychain，以便可以正常的签名应用
security unlock-keychain -p $your-mac-password-here ~/Library/Keychains/login.keychain
# 获取设备的UDID
UDID=$(idevice_id -l | head -n1)
# 运行测试
xcodebuild -project WebDriverAgent.xcodeproj -scheme WebDriverAgentRunner -destination "id=$UDID" test
安装 facebook-wda
pip3 install -U facebook-wda
关于 facebook-wda 的使用文档，可以参考：
https://github.com/openatx/facebook-wda
此处不再赘述。
第四步，iOS抓取控件的方法，一般有常用的有两种方式：
Appium 团队提供的 appium-ios-inspector 项目地址：
https://github.com/mykola-mokhnach/Appium-iOS-Inspector
Macaca的app-inspector工具 项目地址：
https://macacajs.github.io/app-inspector/cn/
第五步，关于云真机集群部署
什么是云真机集群，说白了也就是能够在云平台上远程去调度移动端真机（手机管理平台）。
现有的云真机集群，一般可以分为：公有云真机集群和私有云真机集群。
公有云真机集群，是测试行业内一些公司提供的云真机服务。
比较著名的有Testin、WeTest等。
-
优点：无需自建，而且有海量手机设备可以选。
-
缺点：要钱，贵。
私有云真机集群，需要自己采购真机设备和专用机柜。
我们最后决定搭建私有云真机环境，来行真机调度和管理。
真机采用测试淘汰下来的机器，有时候也会针对性的去买一些热门机型进行UI自动化测试。
私有云真机有没有什么优缺点？
优点：机器是自己的，平台是自己的，想怎么玩就怎么玩。
缺点：
-
真机成本也很高。
-
如果是有线连接的话，电池长时间充电，有较大耗损，电池会鼓包，如果假期无人值守，最坏的情况会导致机柜爆炸。
-
如果是无线连接的话，电池的监控又是一大问题，需要频繁的进行人工看护。
现在常用的私有云真机管理平台，可以采用：
STF：https://github.com/openstf/stf
或者，
atxserver2：https://github.com/openatx/atxserver2
atxserver2 可以无缝对接 ATX，所以我们采用的是 atxserver2 来管理我们的云真机。
4）执行测试方案
先来看一下我们的整个测试架构：
生成测试报告：
如果比较喜欢用pytest的话，可以把 uiautomator2 + htmltestrunner 换成 pytest + allure 也挺香的。
因为涉及到一些公司机密，这部分就不做具体的演示了。
感兴趣大家可以自己去搭建一套UI自动化测试运行环境。
四、对UI自动化的思考
如果真正去接触 UI 自动化的话，你会发现 UI 自动化的可玩性也挺强的，而且对于新手测试来说，从 UI 自动化开始入门去学习自动化测试，是一条很不错的线路。
当你看到你的手机按照你预设的脚本去操作 APP，会有一种莫名的成就感，并且会激励你继续深入学习下去。
我看到很多 ”XXX 从入门到放弃“ 的案例，绝大多数都是因为学习路径过于陡峭，导致对知识的获取感到了彷徨，慢慢的就放弃了。
但是 UI自动化 本身实操起来并不难，可能也就环境的搭建稍微要麻烦一些，总的来说，UI自动化 对新手来说，还是很友好的。
当然UI 自动化并不能解决所有的问题，比如：
-
APP 版本迭代太快，UI 变化频繁。
-
操作流程复杂的测试场景。比如，经常会有各种弹窗（拼多多让你砍一刀），用例的通过率就会很低。
-
垒代码没有意义，测试场景设计优于实现。比如，为了追求极致的自动化测试的覆盖率，可能会为一些很边缘化的功能做自动化测试，这些功能甚至极少有用户去触发，做这部分功能自动化，显然是没有意义的。
-
平台化是趋势，有些团队把自动化脚本的编写都抽象成平台上”点点点”的操作了，看似更方便了，但实际上编写效率还不如 Coding，所以应该权衡利弊之后，选择适合自己团队的自动化方案。
最后，不管是接口自动化还是UI自动化，都有自己的局限性和适用范围，二者应该是互补的。
千万不要把 UI自动化 不擅长的工作，丢给 UI自动化 去做。
UI 自动化 还有更多玩法，感兴趣的同学可以根据自己公司的业务去尝试：
-
利用 AI 技术，预测定位元素，提升编写脚本的效率。
-
UI 自动化可以利用图像识别进行对比测试。
-
结合 Maxim、Monkey 或者 遍历测试 工具，进行稳定性精准测试。
-
结合 Perfdog 等性能测试工具，进行移动端性能测试。
如果有写的不好的地方，请大家多多指教。如果有其他想法，也欢迎在评论区和我交流。
学习资源分享
最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走
这些资料，对于想进阶【自动化测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。希望对大家有所帮助…….
