天天看点

客户端Android稳定性测试实践

作者:闪念基因

背景

为什么需要客户端稳定性测试?

稳定性测试是在保证功能完整正确的前提下,必不可少的一项测试内容,通过对软件稳定性的测试可以观察在一个运行周期内、一定的压力条件下,

软件的出错机率、性能劣化趋势等。进而大大减少软件上线后的崩溃卡死等现象,为软件的逐步优化提供方向及验证。

稳定性问题带来的危害?

  • 影响品牌口碑
  • 用户留存降低
  • 影响用户体验

在视频业务方向,某个版本迭代底层技术架构优化多例播放器的需求,用户在升级到新版本后第一次观看视频Crash,共计Crash量39k。在功能测试阶段,从功能层面出现概率极低,但是当用户量大的时候会激发。

反思: 从质量保障角度层面,发现视频业务在集成阶段 缺乏前置 拦截测试手段 。

客户端Android稳定性测试实践

故障复盘

目标

  • 社区客户端稳定性 Crash 降低 20%
  • 版本灰度阶段稳定性问题闭环率 100%
  • 日常运营稳定性测试工具,拦截集成和灰度Bug
  • 建立 知乎统一稳定性测试能力

技术方案设计

方案调研

1、Google Monkey

首先来看业界用的较早也是经常听过的一款工具—— Monkey。这是 Android 官方提供的一个工具。谷歌原本设计这款工具是为了对 App 进行压力测试的。

谷歌早期在设计 Android 的时候,Android 需要响应滑动、输入、音量、电话等事件,早期 Activity 设计不完善的时候,谷歌希望测试 activity 的性能,

把所有的数据批量化的输出给 Activity ,看 Activity 一秒钟可以处理多少数据。所以早期 Monkey 是用来做 Android 的一个压力测试的工具。

由于 Monkey 在测试过程中的“随机”性,恰巧可以被用来做自动遍历测试,但是 monkey 的缺点很明显,不支持业务行为定制,

无法灵活的控制,经常会点到外部的 App 无法回归原测试 App ;或者点击到注销和退出,造成无法继续后面的测试;

因此 monkey 在经过调研了解后没有成为我们做自动遍历测试的首选。

Monkey 官方链接: https://developer.android.com/studio/test/monkey

2、Maxim自动化遍历

Maxim 也是一款自动遍历工具,由国内的 zhangzhao 同学开发,官方给出的定义是:

An efficient Android Monkey Tester, available for emulators and real devices 基于遍历规则的高性能 Android Monkey,适用于真机/模拟器的 APP UI 压力测试。

我们来看看这款工具的优缺点:

优点:

  • 基于Monkey二次开发,运行速度非常快
  • 提供了多种遍历算法以提高覆盖度
  • 提供了定制化功能,可以实现流程控制

缺点:

  • 因为是基于 Monkey,所以不具备跨平台性,只能测试 Android ,不能测试 iOS 及 Web 等;

这是一款很优秀的工具,可在一定程度上进行定制,如果只测试 Android 系统的话,可以考虑选用 Maxim 做自动遍历。

官方 GitHub 地址:https://github.com/zhangzhao4444/Maxim

3、AppCrawler

AppCrawler 官方 GitHub 上对这款工具的解释是:

一个基于自动遍历的 App 爬虫工具。支持 Android 和 iOS,支持真机和模拟器。最大的特点是灵活性,可通过配置来设定遍历的规则。

这里顺便提一下的是谷歌也发布了一款自动遍历的工具,名字几乎一样,叫做 App Crawler (差了一个空格),设计的思想也一致。思寒开源的的工具比谷歌早了两年时间。

下面来看看 AppCrawler 的作用和价值。看看它为何满足我们的测试需求,它的优缺点又在哪里。

优点:

  • 跨平台性:AppCrawler是基于 Appium 开发的,所以支持 Android、iOS、Web
  • 灵活定制:对遍历的页面、控件、事件、深度等都可自由控制

缺点:

  • 运行速度较慢:基于 Appium 开发具备了跨平台的优点,但是也因为这层封装造成了运行速度相对较慢,再加上运行过程中加入了截图(可以在配置中取消,但是取消后不利于结果的查看),运行起来自然就慢了;
  • 使用门槛高:正因为使用灵活性的问题,也造成了使用门槛的提高,主要基于 YAML 文件中使用 Appium 的相关技术知识进行配置,这就对使用者有了一定的技术要求;

4、字节跳动Fastbot 健壮性测试工具

Fastbot 是字节跳动的 Quality Lab 团队开发的一款融合了机器学习与强化学习的基于模型测试的工具。

中文介绍

基于model-based testing 结合机器学习、强化学习的APP 稳定性测试工具

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 Monkey执行引擎。

能力建设

主要有如下三个方向:

  • 数据分析 分析下钻各个阶段的产生问题归类,发生比例、修复率等指标。
  • 流程规范: 制定Crash修复流程,降低灰度和全量的风险。
  • 工具能力: 框架搭建、bug上报、持续集成、提高覆盖率、精准bug分发、工具推广。
客户端Android稳定性测试实践

客户端稳定性测试建设

里程碑

主要分为四个关键节点:

  • 需求调研
  • 技术调研
  • 业务试点
  • 运营分析
客户端Android稳定性测试实践

方案里程碑计划

工具架构

工具架构如下: 主要分为工具层和服务层

  • 工具层主要提供测试工具执行的基础能力。
  • 服务层主要提供提供给工具层服务能力,如: 安装包数据、创建 Bug 服务、保存报告服务等。
客户端Android稳定性测试实践

工具能力架构

发版流程

伴随客户端发版节奏,从需求上车后到构建完成集成包,自动化触发稳定性测试任务。发现稳定性问题

会自动提交 Bug 并且指派给研发同学,可以通过质量大盘全局的分析版本趋势、执行次数等指标数据。

在版本集成阶段和版本灰度阶段持续跟踪推进问题闭环,要达到闭环率100%,稳定性指标闭环指标作为版本质量准入评估指标。

客户端Android稳定性测试实践

版本质量准出

持续集成

依托于Jenkins开源持续集成工具,做任务调度、设备执行节点。Jenkins 实例是安装在独立分隔的另一台设备上,一般称之为 Jenkins Controller 。

客户端Android稳定性测试实践

Android稳定性测试自动化分布式执行

Jenkins Agent 本身只是一个编译、打包、运行代码的环境,并不包含 Jenkins 实例。在每一个Jenkins Agent 上可以挂在多台Android设备。

在Jenkins中创建稳定性测试任务,编写构建脚本和执行测试策略。

客户端Android稳定性测试实践

monkey执行任务列表

落地效果

过程数据:

  • 执行次数: Android 3500+
  • 执行机器: 多台设备(小米、华为、鸿蒙、红米) * 每天定时三次
  • 执行时长: 累计执行时间: Android 20w+分钟 每单次执行 60 分钟
  • 接入方: 知乎、知乎日报、知学堂

结果数据:

  • Android累计发现 75+ Bug

版本发现Bug趋势

客户端Android稳定性测试实践

版本发现比例

客户端 集成 / 灰度阶段发现的Bug比例

客户端Android稳定性测试实践

阶段发现比例

结语

客户端稳定性建设不是一朝一夕的事,从分析线上问题、调研、实现、推广等关键节点,最终配合严谨的发版流程严卡稳定性问题。

另外稳定性测试只是稳定性治理的一小部分,从研发侧可以从代码编写、架构设计、止损方案角度避免线上稳定性问题。

最后,一切技术专项都要有业务买单、解决实际问题。

作者:信希

出处:https://zhuanlan.zhihu.com/p/593676356