职业经验 测试开发 - 用了几周的 fastbot,谈谈感受

小巴哥 · 2023年03月09日 · 最后由 chend 回复于 2023年03月10日 · 6332 次阅读

写在前面

公司自动化测试是基于 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 自动化测比重已经远远小于接口自动化和单元测试,所以我们就不必担心这样没有逻辑设计的自动化会对业务覆盖不全。

image.png

fastbot 优缺点

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

fastbot 发现了问题

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

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

image.png

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

image.png

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

image.png

image.png

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

总体感受

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

最后

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

共收到 6 条回复 时间 点赞

对于楼主的看法,其实我也有些疑问想提问的,应届新人,有说的不对的地方欢迎随时指出
我们公司当前业务线没有自动化团队,所有自动化用例都是组内同学编写,我是负责了 iOS 相关的 UI 自动化编写。结合现在的状况,有以下几个问题没有很明确答案
1、跟楼主说的一样,每次版本迭代的 UI 自动化回归,基本不会发现问题,但 app 端的回归测试,本身就需要覆盖这一块内容,按照楼主所说,废弃跑 UI 自动化,转而使用 fastbot,那是不是代表也不需要手动进行某些功能回归了
2、fastbot 我个人也有在使用,因为主要负责 iOS,所以我结合了 grafana 和 instrument 协议,搭了一台性能监控平台,让 fastbot 跑,然后企图发现一些内存泄漏、性能瓶颈,但发现自己对于捕获到的折线图不会分析😂 我也在反思这一套有没有必要落地,因为只在本地跑,还没有合并代码

KinChung 回复

首先感谢阅读,根据我的经验,业务逻辑相关的测试我建议还是通过接口自动化取覆盖,两种自动化没必要同时覆盖相同的功能,保证整体的代码覆盖率同时,可以在接口自动化上多做些工作,其实在测试金字塔中 UI 自动化的占比就是应该越少越好,希望能对你有帮助,结合 grafana 和 instrument 协议,搭了一台性能监控平台的想法非常不错,把想法落地下来带来更多的收益,然后分享一下

有个疑问,fastbot 如果只对页面进行点击操作,如果一个页面需要输入一定的信息才能进入下一个页面,比如登录,你得输入账号密码,那 fastbot 不具备这个功能,不是一直在登录页面测试?那不是没有什么意义

薄荷可乐 回复

其实 fastbot 更偏向于功能完整性,不是针对于业务逻辑,业务逻辑还是希望更多在接口自动化中完成

羡慕你们这种业务

这应该就是属于业务利好了, 感觉只适合面向大众 C 端的简单业务. 不涉及太多逻辑依赖的.

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册