移动应用专项测试的思路和方法
对于移动应用,顺利完成全部业务功能测试往往是不够的。如果你的关注点只是业务功能测试,那么, 当你的移动应用被大量用户安装和使用时,就会暴露出很多之前完全没有预料到的问题,比如:
流量使用过多;
耗电量过大;
在某些设备终端上出现崩溃或者闪退的现象;
多个移动应用相互切换后,行为异常;
在某些设备终端上无法顺利安装或卸载;
弱网络环境下,无法正常使用;
Android环境下,经常出现ANR(Application Not Responding); …
这样的问题还有很多,为了避免或减少此类情况的发生,所以移动应用除了进行常规的功能测试外,通 常还会进行很多移动应用所特有的专项测试。
今天这篇文章,我就从交叉事件测试、兼容性测试、流量测试、耗电量测试、弱网络测试、边界测试 这6个最主要的专项测试来展开。
第一,交叉事件测试
交叉事件测试也叫中断测试,是指App执行过程中,有其他事件或者应用中断当前应用执行的测试。
比如,App在前台运行过程中,突然有电话打进来,或者收到短信,再或者是系统闹钟等等情况。所 以,在App测试时,就需要把这些常见的中断情况考虑在内,并进行相关的测试。
注意,此类测试目前基本还都是采用手工测试的方式,并且都是在真机上进行,不会使用模拟器。
首先,采用手工测试的原因是,此类测试往往场景多,而且很多事件很难通过自动化的方式来模拟,比 如呼入电话、接收短信等,这些因素都会造成自动化测试的成本过高,得不偿失,所以工程实践中,交 叉事件测试往往全是基于手工的测试。
其次,之所以采用真机,是因为很多问题只会在真机上才能重现,采用模拟器测试没有意义。
交叉事件测试,需要覆盖的场景主要包括:
多个App同时在后台运行,并交替切换至前台是否影响正常功能; 要求相同系统资源的多个App前后台交替切换是否影响正常功能,比如两个App都需要播放音乐,那 么两者在交替切换的过程中,播放音乐功能是否正常; App运行时接听电话; App运行时接收信息; App运行时提示系统升级; App运行时发生系统闹钟事件; App运行时进入低电量模式; App运行时第三方安全软件弹出告警; App运行时发生网络切换,比如,由Wif切换到移动4G网络,或者从4G网络切换到3G网络等; …
其实你可以发现,这些需要覆盖的场景,也是我们今后测试的测试用例集,每一场景都是一个测试用例 的集合。
第二,兼容性测试
兼容性测试顾名思义就是,要确保App在各种终端设备、各种操作系统版本、各种屏幕分辨率、各种网 络环境下,功能的正确性。常见的App兼容性测试往往需要覆盖以下的测试场景:
不同操作系统的兼容性,包括主流的Andoird和iOS版本; 主流的设备分辨率下的兼容性; 主流移动终端机型的兼容性; 同一操作系统中,不同语言设置时的兼容性; 不同网络连接下的兼容性,比如Wif、GPRS、EDGE、CDMA200等; 在单一设备上,与主流热门App的兼容性,比如微信、抖音、淘宝等; …
兼容性测试,通常都需要在各种真机上执行相同或者类似的测试用例,所以往往采用自动化测试的手 段。 同时,由于需要覆盖大量的真实设备,除了大公司会基于Appium + Selenium Grid + OpenSTF去 搭建自己的移动设备私有云平台外,其他公司一般都会使用第三方的移动设备云测平台完成兼容性测 试。
第三方的移动设备云测平台,国外最知名的是SauceLab,国内主流的是Testin。
第三,流量测试
于App经常需要在移动互联网环境下运行,而移动互联网通常按照实际使用流量计费,所以如果你 的App耗费的流量过多,那么一定不会很受欢迎。
流量测试,通常包含以下几个方面的内容:
App执行业务操作引起的流量; App在后台运行时的消耗流量; App安装完成后首次启动耗费的流量; App安装包本身的大小; App内购买或者升级需要的流量。
流量测试,往往借助于Android和iOS自带的工具进行流量统计,也可以利 用tcpdump、Wireshark和Fiddler等网络分析工具。
对于Android系统,网络流量信息通常存储在/proc/net/dev目录下,也可以直接利用ADB工具获取实时 的流量信息。另外,我还推荐一款Android的轻量级性能监控小工具Emmagee,类似于Windows系统 性能监视器,能够实时显示App运行过程中CPU、内存和流量等信息。
对于iOS系统,可以使用Xcode自带的性能分析工具集中的Network Activity,分析具体的流量使用情 况。
但是,流量测试的最终目的,并不是得到App的流量数据,而是要想办法减少App产生的流量。虽然, 减少App消耗的流量不是测试工程师的工作,但了解一些常用的方法,也将有助于你的测试日常工作:
启用数据压缩,尤其是图片; 使用优化的数据格式,比如同样信息量的JSON文件就要比XML文件小; 遇到既需要加密又需要压缩的场景,一定是先压缩再加密; 减少单次GUI操作触发的后台调用数量; 每次回传数据尽可能只包括必要的数据; 启用客户端的缓存机制;
第四,耗电量测试
耗电量也是一个移动应用能否成功的关键因素之一。
在目前的生态环境下,能提供类似服务或者功能的App往往有很多,如果在功能类似的情况下,你 的App特别耗电、让设备发热比较严重,那么你的用户一定会卸载你的App而改用其他App。最典型的 就是地图等导航类的应用,对耗电量特别敏感。
耗电量测试通常从三个方面来考量:
App运行但没有执行业务操作时的耗电量; App运行且密集执行业务操作时的耗电量; App后台运行的耗电量。
耗电量检测既有基于硬件的方法,也有基于软件的方法。我所经历过的项目都是采用软件的方 法,Android和iOS都有各自自己的方法:
Android通过adb命令“adb shell dumpsys battery”来获取应用的耗电量信息; iOS通过Apple的官方工具Sysdiagnose来收集耗电量信息,然后,可以进一步通过Instrument工具链 中的Energy Diagnostics进行耗电量分析。
第五,弱网络测试
与传统桌面应用不同,移动应用的网络环境比较多样,而且经常出现需要在不同网络之间切换的场景, 即使是在同一网络环境下,也会出现网络连接状态时好时坏的情况,比如时高时低的延迟、经常丢包、 频繁断线,在乘坐地铁、穿越隧道,和地下车库的场景下经常会发生。
所以,移动应用的测试需要保证在复杂网络环境下的质量。具体的做法就是:在测试阶段,模拟这些网 络环境,在App发布前尽可能多地发现并修复问题。
在这里,我推荐一款非常棒的开源移动网络测试工具:Facebook的Augmented Traffc Control(ATC )。
ATC 最好用的地方在于,它能够在移动终端设备上通过Web界面随时切换不同的网络环境,同时多个移 动终端设备可以连接到同一个Wif,各自模拟不同的网络环境,相互之间不会有任何影响。也就是说, 只要搭建一套ATC 就能满足你所有的网络模拟需求。
如果你对ATC 感兴趣,可以在它的官方网站找到详细的使用说明。
第六,边界测试
边界测试是指,移动App在一些临界状态下的行为功能的验证测试,基本思路是需要找出各种潜在的临 界场景,并对每一类临界场景做验证和测试。 主要的场景有:
系统内存占用大于90%的场景; 系统存储占用大于95%的场景; 飞行模式来回切换的场景; App不具有某些系统访问权限的场景,比如App由于隐私设置不能访问相册或者通讯录等; 长时间使用App,系统资源是否有异常,比如内存泄漏、过多的链接数等; 出现ANR的场景; 操作系统时间早于或者晚于标准时间的场景; 时区切换的场景;