Appetizer App 稳定性测试面面观

AppetizerIO for AppetizerIO · June 26, 2019 · Last by 丫滴 replied at August 21, 2019 · 3296 hits

现在App普遍可以运行在后台,在用户切换到的时候唤醒到前台,一方面可以避免不必要的冷启动时间,另一方面可以持续接收服务端的推送。
前后台运行时间加起来可以长达几十小时,甚至几百小时,所以对于App长时间使用的稳定性有了更高的要求,需要App稳定性测试来避免长时间运行下的偶发闪退、内存泄露、性能变差等等。
通常App稳定性测试采用Monkey类的工具来长时间全自动遍历App,并捕获期间发生的稳定性问题。综合各个Monkey方案的稳定性、可配置性、执行效率等多方面考虑,首选Maxim作为Monkey遍历工具,通过Appetizer管理和配置Maxim提高方案试错效率。稳定性测试方案有以下重点,本文将一一解答:

  • 如何配置Maxim提高遍历效率
  • 如何评估自动遍历的覆盖率以及遍历时间
  • 稳定性测试要捕获什么,可以捕获什么
  • 如何复现捕获的问题/提稳定性Issue
  • 如何拓展稳定性测试,让同样的测试时间产出更大

基础知识

Google 原生Monkey 是一个命令行工具,可以全自动随机点击屏幕,用来测试App稳定性等。Maxim@zhangzhao_lenovo 修改自 monkey的高级版本,支持 Android 5.0-9.0、操作非常高速 (10-15事件/秒),稳定性高,可配置。 AppetizerIO提供了对Maxim的深度集成,使得配置更方便,配置管理更简单。从Appetizer导航 -> 自动化测试 -> Maxim,最基本配置选好测试设备和测试APK即可开始测试。Maxim提供的配置有:

  • Maxim的遍历模式,如图

  • Activity黑白名单,选择待测APK后会出现选择,下文有截图

  • 测试时长,可以根据时间(分钟)或者自动产生的事件数

  • max.xpath.actions 指定界面确定性步骤,例如登录

  • max.widget.black 屏蔽某些界面的某些控件或者区域,例如屏蔽广告区域

  • max.config 开启定时截图;调整启动等待时间

  • 事件间延迟:两次事件间隔的时间

  • Maxim事件日志

  • 数据采集和输出路径:Appetizer可以在测试过程中收集额外数据,例如Maxim日志、logcat,Battery Historian数据等等

如何配置Maxim提高遍历效率

由于Monkey本质上是无脑交互,在实际使用中,很容易由于进入了一些App场景后在里面转悠几十分钟都出不来,大大影响了遍历效率。以下经验和大家分享:

  1. 不要从全新安装的App安装开始遍历 很多人的方案开头就是自动adb安装App,其实这样效果很差,因为全新安装后会出现大量的低频新手教程、登录、权限弹框等影响Maxim。而稳定性测试本质上是模拟老用户长时间使用App的情况,所以应当已经完全登录,新手流程已经全部过掉的情况下再开始Maxim。具体实施的时候有几种选择:a. 手工安装app,登录,过掉已知的新手教程 b. 始终不清除稳定性测试设备上app的数据,较新的开发版App可以更新安装保持数据 c. 如果b不容易实现,可以试试 adb backupadb restore 保存和复原 App数据
  2. 避免动态权限弹框 动态权限弹框也是影响Maxim执行的很大因素,各个厂商弹框不同,很难适配。因此在开始Maxim遍历前,应当赋予App所有需要的权限,这步可以手工,也可以用adb pm grant <包名> <权限名>来自动实现。
  3. 关掉输入法 遍历过程中无可避免会点击到各种输入框,输入法会弹起,一旦Maxim点击到输入法,例如某狗,某度输入法,会导致非常多不可预料的情况,比如输入法广告弹框,录音弹框等等。而且Maxim遍历时如果要输入内容,也是直接输入并非通过输入法,所以输入法是一个纯干扰,最简单的方式就是在开始遍历前关掉输入法,结束后再开启。具体实现时,安装Appium Keyboard(也就是啥也没有),然后 通过adb shell ime 来设置输入法
  4. 黑名单屏蔽Activity和控件
    Maxim提供了两个级别的禁止遍历黑名单,可以通过配置直接禁止进入某些Activity,也可以通过配置屏蔽指定Activity上的区域(xpath或者坐标范围)。Activity黑名单原理是截获切换的Intent直接不发,Appetizer提供的图形化方案可以非常简单地设置Activity黑名单:

    屏蔽的规则很简单,一般屏蔽一切非App业务的第三方推送、第三方支付、第三方登录、分享、扫码、人脸识别、图片/文件选择器、人工客服。而区域屏蔽则更为精细,应当屏蔽三方登录按钮区域、付费选择、广告、分享按钮等一切能够切出App或者需要人工/摄像头的功能点。登录和支付业务不应该在稳定性测试中出现,应该是登录专项和支付业务用例里。

    max.widget.black配置项是一个数组,每一项一条屏蔽规则,规则很容易懂,指定某个Activity以及需要屏蔽的控件的xpath,或者屏幕像素区域bounds或者有多个符合xpath条件的控件条件下增加index表示第几项

  5. 调整事件比例
    Maxim MIX模式下默认会有30%完全随机事件(屏幕任意位置乱点、滑动、任意物理按键) + 70%界面元素解析后的元素级交互,在用于App稳定性测试过程中,比例应当根据App特性进行调整。Maximw从Google原生Monkey改来,完全兼容Monkey的参数,如下:

    • --pct-touch <percent> 为单击事件百分比
    • --pct-motion <percent> 为滑动事件百分比(方向、长度和速度随机)
    • --pct-trackball <percent> 随机滚动后点击事件百分比
    • --pct-nav <percent> 上下左右滑动事件
    • --pct-majornav <percent> 回退、home、最近三键
    • --pct-syskeys <percent> 系统按键,标准三键+音量等
    • --pct-appswitch <percent> 切换App 实际使用中,非0项目应该为 --pct-touch --pct-motion --pct-majornav,其中touch可以低一些,因为毕竟有元素级别touch乱点没有特别大的意义;motion可以高一点,弥补Maxim不会滑动的缺陷;majornav中等,保证有一定量的回退;推荐使用5,20,10;
  6. 多个配置结合
    配置不可能一蹴而就,也不用纠结在单个配置上。可以分几次跑,每次入口的Activity不一样,然后参数不一样来达到综合做好的情况。例如主界面有多个主业务入口,可以每个主业务入口Activity用一套配置,每套配置里面把主界面黑名单掉,这样就不会回退回来。Appetizer存取多个配置:

  7. 处理表单类界面
    表单类界面即有多个输入框,然后按钮,而按钮成功要求多个输入框满足一个验证条件,例如都要有内容。表单类界面是Maxim和Monkey类工具非常不适合的一种界面,随机能够满足验证条件的概率极低,基本没有探索价值。可以直接黑名单,或者通过 max.xpath.actions 配置项直接填写。

如何评估自动遍历的覆盖率以及遍历时间

覆盖率大致方向有两个,Jacoco(代码行覆盖)和Activity覆盖率,Jacoco需要 源代码接入,完全落地需要一定时间。在配置初期,并不用太强调代码行覆盖率,毕竟Maxim有一定的随机性,多次跑可能导致不同的结果。在配置初期,可以以Activity覆盖率作为主要参考,力求尽量覆盖到可以自动化遍历的业务Activity。
Activity覆盖率获取方式有两种:如果APK经过Appetizer插桩,每次Maxim运行后都会有Appetizer插桩数据报告,里面有Activity覆盖率以未覆盖的Activity名单;如果没有插桩,可以用Appetizer保存Maxim运行产生的stdout,然后自行parse进入过的Activity。

当配置优化后,同时Jacoco方案已经成熟的情况下,可以评估一次完整的稳定性测试的代码行覆盖情况。一般来说行覆盖率不会很高,原因有几个部分 1. Jacoco统计分母是所有的class,有很多三方代码和库代码是dead code实际不会执行,除非Jacoco分析的时候就去掉的这些 2. 毕竟Maxim遍历没有逻辑性,很多和数据相关的代码块并不能有效进入 3. 单机型运行的话,有些安卓版本特殊的代码也会遗漏;总体来说,行覆盖仅仅做参考,配置优化能增加就是好事,不必苛求一个具体百分比目标。

遍历时间并不是越长越好,因为执行初期对覆盖率提升非常有效,而后期大量的时间对两种覆盖率的提升都是非常有限。另一方面来说,遍历时长太久大大增加了收集到的数据量,影响分析效率,也会引入不必要稳定性坑。应当多花费时间优化配置,帮助Maxim省去非常多的不可控性和徒劳遍历,一般一套优化过的配置,只需要20分钟到1个小时即可。

稳定性测试要捕获什么,可以捕获什么

  1. crash, ANR
    • Maxim会自动log疑似App crash的情况,结果将保存在 /sdcard/maxim-output/crash.log,注意这些只是疑似情况
    • Appetizer插桩后的App会捕获crash ANR,在报告中
  2. 主线程卡顿

    • 主线程上卡顿的情况,需要Appetizer插桩,在数据报告中
  3. http 请求4xx 5xx,以及高延迟的情况

    • 接口请求失败的情况,需要Appetizer插桩,在数据报告中
  4. 截图
    Maxim支持每次执行事件后截图,还支持保存页面控件结构(XML),截图上会有事件点击的红点标注,方便发现问题后回溯到具体场景,具体字max.config里开启,如下图。注意,截图保存在 /sdcard/max-output 目录,长时间运行会占据大量的存储控件,确保每次运行前用Appetizer下载上次的截图结果,并删除

如何拓展稳定性测试,让同样的测试时间产出更大

很多时候第一次引入稳定性测试后会发现一些问题,积极性会比较高,随着时间推移,问题会发现越来越少,换个方面考虑是App低级错误越来越少,这时候会面临继续投入稳定性测试的质疑,这方面有几点:

  1. 稳定性测试和回归是一样的,是守门员,非前锋,目标是拦截不是预言,
  2. 自动遍历其实会高速发出UI事件,对App性能也是一个考验,所以自然可以收集并分析性能数据,在稳定性测试的框架上分析性能瓶颈。 具体怎么做,请期待6.28-6.29的 MTSC 2019大会,将在6.29周六下午1点QA场与大家分享

Appetizer之后会带来什么样更方便的稳定性测试

目前Appetizer为1.4.3,未来版本:

  • Appetizer 1.4.4 将支持同时在多个机型上并行跑Maxim
  • Appetizer 1.4.5 将新增稳定性专项测试,结合本文提到的所有的点 敬请期待,欢迎留言讨论。

关注Appetizer微信服务号,了解最新的测试技术方案和Appetizer功能预告

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 8 条回复 时间 点赞

手动点赞 已落地发版回归测试的流程中 结合安卓绿色联盟应用体验2.0标准 进行质量管理

这个工具挺好 顶一个

这个工具在哪下载。。看了半天觉得很牛逼,也需要。是有现成的平台?还是思路而已。

Kori 回复

https://www.appetizer.io
目前1.4.3 Maxim的配置运行都完工了

AppetizerIO 回复

感谢!

AppetizerIO 回复

请问这个工具是永久免费么。还是后续会出一些收费的功能。

是商业产品,有免费功能

imath60 回复

你好,你们是怎么判断稳定性的呢

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up