都2023了！别再问我，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自动化实践案例，欢迎评论区交流。

现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：110685036

三、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 自动化还有更多玩法，感兴趣的同学可以根据自己公司的业务去尝试：