写在前面

公司自动化测试是基于 appium 开发的，每个版本需要抽出 1 人天的时间进行维护，但是每个版本自动化发现的问题不足 1 个，根据一年多的维护和产出进行了对比，决定废弃现有的自动化测试，选用 fastbot 进行代替。

fastbot 介绍

本段引用 fastbot 官网介绍，Fastbot，由字节跳动自研的智能化测试系统，支持 Android 和 iOS，它是一套基于模型（MBT）的智能化 GUI 测试服务。我们将测试任务转换为对 App 进行遍历搜索和构建有向有环图模型的搜索任务。同时，分拆了客户端和服务端，实现了海量设备上的多机协同执行 GUI 测试任务。在客户端做 GUI 信息监听上报和动作注入，在服务端做模型搭建和动作决策，并基于 UCB 公式设计了多套符合有向有环图遍历的算法，避免了局部死循环的情况，极大的提高了测试覆盖能力和测试效率。

fastbot 使用

• Android 项目https://gitee.com/ByteDance/Fastbot_Android
• iOS 项目 https://gitee.com/ByteDance/Fastbot_iOS

详细的使用步骤这里就不说了，官网项目写的非常清楚，可以参考下这两个项目

对自动化理解

为什么选用 fastbot，不选用传统的自动化测试技术呢，传统的自动化技术偏向于业务能力，而 fastbot 偏向于功能，这是怎么说能，因为传统的 UI 自动化是根据用例设计进行自动化脚本编写的，而 fastbot 通过遍历页面下的功能按钮，实现自动化测试，可能有人会有疑问，这样的测试怎么能发现问题呢？由于现在的项目多数业务逻辑在后端实现，前端不会再有逻辑相关的代码，所以我们在实现自动化测试的时候，应该把逻辑部分多在接口自动化和单元测试中实现，而 UI 自动化测试简单的页面功能即可，只要把握好整体的自动化覆盖率，按比重来分配 UI 自动化、接口自动化、单元测试，正如测试金字塔模型一样，UI 自动化测比重已经远远小于接口自动化和单元测试，所以我们就不必担心这样没有逻辑设计的自动化会对业务覆盖不全。

fastbot 优缺点

在几周的使用过程中，总结了一些优点和缺点，优点：1、不用传统自动化的环境的搭建，push 几个 jar 包到手机内就能使用，2、通过一些配置文件可以实现页面的白名单和黑名单，不需要点击的地方等功能，3、有完整的 log 可以对报错进行分析，缺点：1、配置了登录页面的黑名单或退出登录不点击，还是会奇怪的退出登录，2、报告在手机端生成，如果集成到平台可能需要自行处理。

fastbot 发现了问题

自动化结束后，会生成几个比较有用的 log 文件

• max.activity.statistics.log 文件，这个文件写了 覆盖了那些页面和页面的覆盖率，可以方便我们后续做出统计

• meminfo，这个文件统计了使用过程中的内存占比，可以方便我们进行 app 性能分析

• crash-dump.log 文件，这个文件是一些报错内容，包括 app 的 crash 和 anr 等，可以接入测试报告，进行跟进处理

可以看出，报告还是非常详细的，包括哪个页面出现了什么问题，这样也方便开发进行处理跟进。

总体感受

总体使用下来感觉，维护成本确实是大大降低了，也能发现更更多的问题，降低的线上的风险，可能页面配置还是会有差错，如果不配置老是退出登录就可能导致 有的页面执行不到，个人感觉还是比较符合迭代较快的公司。

最后

我是小巴哥,一个陪你成长,实实在在分享 测试干货职场经验的人,欢迎关注!!!