为什么需要客户端稳定性测试?
稳定性测试是在保证功能完整正确的前提下,必不可少的一项测试内容,通过对软件稳定性的测试可以观察在一个运行周期内、一定的压力条件下,
软件的出错机率、性能劣化趋势等。进而大大减少软件上线后的崩溃卡死等现象,为软件的逐步优化提供方向及验证。
稳定性问题带来的危害?
在视频业务方向,某个版本迭代底层技术架构优化多例播放器的需求,用户在升级到新版本后第一次观看视频 Crash,共计 Crash 量 39k。在功能测试阶段,从功能层面出现概率极低,但是当用户量大的时候会激发。
社区客户端稳定性 Crash 降低 20%
版本灰度阶段稳定性问题闭环率 100%
日常运营稳定性测试工具,拦截集成和灰度 Bug
建立 知乎统一稳定性测试能力
方案调研
1、Google Monkey
首先来看业界用的较早也是经常听过的一款工具—— Monkey。这是 Android 官方提供的一个工具。谷歌原本设计这款工具是为了对 App 进行压力测试的。
谷歌早期在设计 Android 的时候,Android 需要响应滑动、输入、音量、电话等事件,早期 Activity 设计不完善的时候,谷歌希望测试 activity 的性能,
把所有的数据批量化的输出给 Activity ,看 Activity 一秒钟可以处理多少数据。所以早期 Monkey 是用来做 Android 的一个压力测试的工具。
由于 Monkey 在测试过程中的 “随机” 性,恰巧可以被用来做自动遍历测试,但是 monkey 的缺点很明显,不支持业务行为定制,
无法灵活的控制,经常会点到外部的 App 无法回归原测试 App ;或者点击到注销和退出,造成无法继续后面的测试;
因此 monkey 在经过调研了解后没有成为我们做稳定性测试的首选。
2、AppCrawler
AppCrawler 官方 GitHub 上对这款工具的解释是:
一个基于自动遍历的 App 爬虫工具。支持 Android 和 iOS,支持真机和模拟器。最大的特点是灵活性,可通过配置来设定遍历的规则。
这里顺便提一下的是谷歌也发布了一款自动遍历的工具,名字几乎一样,叫做 App Crawler (差了一个空格),设计的思想也一致。思寒开源的的工具比谷歌早了两年时间。
优点:
缺点:
运行速度较慢:基于 Appium 开发具备了跨平台的优点,但是也因为这层封装造成了运行速度相对较慢,再加上运行过程中加入了截图 (可以在配置中取消,但是取消后不利于结果的查看),运行起来自然就慢了;
使用门槛高:正因为使用灵活性的问题,也造成了使用门槛的提高,主要基于 YAML 文件中使用 Appium 的相关技术知识进行配置,这就对使用者有了一定的技术要求;
3、Maxim 自动化遍历
Maxim 也是一款自动遍历工具,由国内的 zhangzhao 同学开发,官方给出的定义是:
An efficient Android Monkey Tester, available for emulators and real devices 基于遍历规则的高性能 Android Monkey,适用于真机/模拟器的 APP UI 压力测试。
我们来看看这款工具的优缺点:
优点:
缺点:
因为是基于 Monkey,所以不具备跨平台性,只能测试 Android ,不能测试 iOS 及 Web 等;
这是一款很优秀的工具,可在一定程度上进行定制,如果只测试 Android 系统的话,可以考虑选用 Maxim 做自动遍历。
官方 GitHub 地址:https://github.com/zhangzhao4444/Maxim
4、字节跳动 Fastbot 健壮性测试工具
Fastbot 是字节跳动的 Quality Lab 团队开发的一款融合了机器学习与强化学习的基于模型测试的工具。
Fastbot 可以理解为 MaxIM 的升级版,为了增强覆盖,融合了多种机器学习、强化学习等相关的算法。他的执行速度很快,并显著提升了测试覆盖度。应用的效果也是非常不错的。
目前,Fastbot 已广泛应用于字节客户端类产品的稳定性测试与兼容性测试。每日启动任务数超过 300 次,每日平均发现 5000 个以上的崩溃,并有超过 100 个新捕获的崩溃。借助 Fastbot 的能力,我们在发版前就可以修复大部分的 crash,
确保线上用户的使用体验。同时,Fastbot 在整个 DevOps 流程扮演重要的基础服务角色。我们相信,越来越多的智能化测试工具,将极大的改善国内传统测试行业。
官方 GitHub 地址: https://github.com/bytedance/Fastbot_Android
优势
1、Android 多 os 兼容
同时兼容 Android 5-11,兼容国内各厂商定制化的 Android 系统及原生 Android 系统
2、事件快速注入
继承原生 Monkey 的优势,快速点击,每秒最高可发送 12 个事件
3、专家系统
不同业务线支持不同的个性化需求,业务深度定制化
4、智能化测试
基于 model-based 边遍历边建模,利用强化学习等算法做高收益决策
5、跨平台
支持非标准化控件,YOLOv3、ocr、cv 分割等 UI 图像识别能力
6、模型复用
支持模型复用,模型文件会自动存储在 /sdcard/fastbot_[包名].fbm,启动 fastbot 时如果此文件存在则默认加载模型,运行过程中每隔十分钟会覆盖存储一次,用户可根据需求删除或拷贝此文件
综合对比上面的技术框架优缺点,最终选择 Fastbot 作为 Android 稳定性测试的执行引擎。
主要有如下三个方向:
主要分为四个关键节点:
工具架构如下: 主要分为工具层和服务层
伴随客户端发版节奏,从需求上车后到构建完成集成包,自动化触发稳定性测试任务。发现稳定性问题
会自动提交 Bug 并且指派给研发同学,可以通过质量大盘全局的分析版本趋势、执行次数等指标数据。
在版本集成阶段和版本灰度阶段持续跟踪推进问题闭环,要达到闭环率 100%,稳定性指标闭环指标作为版本质量准入评估指标。
依托于 Jenkins 开源持续集成工具,做任务调度、设备执行节点。Jenkins 实例是安装在独立分隔的另一台设备上,一般称之为 Jenkins Controller 。
Jenkins Agent 本身只是一个编译、打包、运行代码的环境,并不包含 Jenkins 实例。在每一个 Jenkins Agent 上可以挂在多台 Android 设备。
在 Jenkins 中创建稳定性测试任务,编写构建脚本和执行测试策略。
过程数据:
结果数据:
Android 累计发现 75+ Bug
版本发现 Bug 趋势
集成 / 灰度阶段发现的 Bug 比例
客户端稳定性建设不是一朝一夕的事,从分析线上问题、调研、实现、推广等关键节点,最终配合严谨的发版流程严卡稳定性问题。
另外稳定性测试只是稳定性治理的一小部分,从研发侧可以从代码编写、架构设计、止损方案角度避免线上稳定性问题。
最后,一切技术专项都要有业务买单、解决实际问题。