20 浅谈移动应用测试方法与思路-笔记3
当移动应用被大量用户安装和使用时，就会暴露出很多问题，比如：
流量使用过多；
耗电量过大；
在某些设备终端上出现崩溃或者闪退的现象；
多个移动应用相互切换后，行为异常；
在某些设备终端上无法顺利安装或卸载；
弱网络环境下，无法正常使用；
Android 环境下，经常出现 ANR(Application Not Responding)；
…
所以移动应用除了进行常规的功能测试外，还需要进行很多移动应用所特有的专项测试。
一、 6 个最主要的专项测试
交叉事件测试、兼容性测试、流量测试、耗电量测试、弱网络测试、边界测试。
1.交叉事件测试
交叉事件测试也叫中断测试，指 App 执行过程中，有其他事件或者应用中断当前应用执行的测试。
比如，App 在前台运行过程中，突然有电话打进来，或者收到短信，再或者是系统闹钟等等情况。
所以在 App 测试时，要把这些中断情况考虑在内，并进行相关的测试。
注意，此类测试目前基本还都是采用手工测试的方式，并且都是在真机上进行，不会使用模拟器。
原因：
①呼入电话、接收短信等事件很难通过自动化的方式来模拟，所以采用手工测试。
②很多问题只会在真机上才能重现，采用模拟器测试没有意义，所以采用真机测试。
交叉事件测试，需要覆盖的场景主要包括：
①多个 App 同时在后台运行，并交替切换至前台是否影响正常功能；
②要求相同系统资源的多个 App 前后台交替切换是否影响正常功能，比如两个 App 都需要播放音乐，那么两者在交替切换的过程中，播放音乐功能是否正常；
③App 运行时接听电话；
④App 运行时接收信息；
⑤App 运行时提示系统升级；
⑥App 运行时发生系统闹钟事件；
⑦App 运行时进入低电量模式；
⑧App 运行时第三方安全软件弹出告警；---这个要怎么做到？感觉是针对安卓系统的...
⑨App 运行时发生网络切换，比如，由 Wifi 切换到移动 4G 网络，或者从 4G 网络切换到 3G 网络等；
…
可以发现，这些需要覆盖的场景，也是我们今后测试的测试用例集，每一场景都是一个测试用例的集合。
2.兼容性测试
兼容性测试，就是要确保 App 在各种终端设备、各种操作系统版本、各种屏幕分辨率、各种网络环境下，功能的正确性。
常见的 App 兼容性测试往往需要覆盖以下的测试场景：
①不同操作系统的兼容性，包括主流的 Andoird 和 iOS 版本；
②主流的设备分辨率下的兼容性；
③主流移动终端机型的兼容性； --现在有了全面屏、曲面屏、双面屏等异形屏
④同一操作系统中，不同语言设置时的兼容性；
⑤不同网络连接下的兼容性，比如 Wifi、GPRS、EDGE、CDMA200 等；
⑤在单一设备上，与主流热门 App 的兼容性，比如微信、淘宝、支付宝等；
…
兼容性测试，通常都需要在各种真机上执行相同或者类似的测试用例，所以往往采用自动化测试的手段。 由于需要覆盖大量的真实设备，除了大公司会基于 Appium + Selenium Grid + OpenSTF 去搭建自己的移动设备私有云平台外，其他公司一般都会使用第三方的移动设备云测平台完成兼容性测试。
第三方的移动设备云测平台，国外最知名的是 SauceLab，国内主流的是 Testin。
3.流量测试
由于 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 消耗的流量不是测试工程师的工作，但需要了解一些常用的方法：
①启用数据压缩，尤其是图片；
②使用优化的数据格式，比如同样信息量的 JSON 文件就要比 XML 文件小；
③遇到既需要加密又需要压缩的场景，一定是先压缩再加密；
④减少单次 GUI 操作触发的后台调用数量；
⑤每次回传数据尽可能只包括必要的数据；
⑥启用客户端的缓存机制；
…
4.耗电量测试
耗电量也是一个移动应用能否成功的关键因素之一。
在目前的生态环境下，能提供类似服务或者功能的 App 往往有很多，如果在功能类似的情况下，你的 App 特别耗电、让设备发热比较严重，那么你的用户一定会卸载你的 App 而改用其他 App。最典型的就是地图等导航类的应用，对耗电量特别敏感。
耗电量测试通常从三个方面来考量：
①App 运行但没有执行业务操作时的耗电量；
②App 运行且密集执行业务操作时的耗电量；
③App 后台运行的耗电量。
耗电量检测既有基于硬件的方法，也有基于软件的方法。
其中Android 与 iOS 各自的软件方法是：
Android 通过 adb 命令“adb shell dumpsys battery”来获取应用的耗电量信息；
iOS 通过 Apple 的官方工具 Sysdiagnose 来收集耗电量信息，然后，可以进一步通过 Instrument 工具链中的 Energy Diagnostics 进行耗电量分析。
5.弱网络测试
移动应用的网络环境比较多样，而且经常出现需要在不同网络之间切换的场景，即使是在同一网络环境下，也会出现网络连接状态时好时坏的情况。
比如时高时低的延迟、经常丢包、频繁断线这些情况，在乘坐地铁、穿越隧道，和地下车库的场景下经常会发生。
所以，移动应用的测试需要保证在复杂网络环境下的质量。具体的做法就是：在测试阶段，模拟这些网络环境，在 App 发布前尽可能多地发现并修复问题。
推荐一款非常棒的开源移动网络测试工具：Facebook 的 Augmented Traffic Control（ATC）。
ATC 最好用的地方在于，它能够在移动终端设备上通过 Web 界面随时切换不同的网络环境，同时多个移动终端设备可以连接到同一个 Wifi，各自模拟不同的网络环境，相互之间不会有任何影响。也就是说，只要搭建一套 ATC 就能满足你所有的网络模拟需求。
6.边界测试
边界测试是指，移动 App 在一些临界状态下的行为功能的验证测试，基本思路是需要找出各种潜在的临界场景，并对每一类临界场景做验证和测试。
主要的场景有：
①系统内存占用大于 90% 的场景；
②系统存储占用大于 95% 的场景；
③飞行模式来回切换的场景；
④App 不具有某些系统访问权限的场景，比如 App 由于隐私设置不能访问相册或者通讯录等；
⑤长时间使用 App，系统资源是否有异常，比如内存泄漏、过多的链接数等；
⑥出现 ANR 的场景；--Android 环境下，经常出现 ANR(Application Not Responding)
⑦操作系统时间早于或者晚于标准时间的场景；
⑧时区切换的场景
…
本文内容为极客时间《软件测试52讲》的学习笔记，内容摘抄自该课程文稿。
其他参考文章：解读移动app和web app测试侧重点的区别
