移动App测试一些崩溃原因及触发崩溃的场景

移动App测试与传统台式机测试相比有一定的复杂性。这些复杂性可以被分类为：
　　环境（大量的设备，各种移动OSs，适应频繁OSs变化） 。
　　设备（触摸式和非触摸式设备，有限的内存容量，电池耗电量） 。
　　网络（不同的网络和运营商，在不好或无网络的情况下的App行为，离线支持） 。
　　可用性（方向，触摸，多触摸，缩放，分页和导航的局限性，各种干扰，如来电，来电短信，闹钟，和低电量警报） 。
　　所有这些手机专有的复杂性需要新的针对移动App测试的测试用例设计方案。

　　最常见的移动App Bug

　　为了确定最常见的移动App Bug，进行了一次研究，其结果发表在国际测试会议上[ 1 ] 。
　　为了这个目的，准备了一次在线调查思考参与者的移动测试经验并发表在移动App开发和测试相关的专业社会团体内。
　　有针对性的参加本次调查的主要有移动App测试人员和开发人员。结合几个结果，最常见的移动App Bug在对调查结果进行统计分析后确定。
　　根据调查的结果，移动App崩溃是最常见的移动App Bug ，这是预料中的结果，因为很容易发现一个移动App崩溃。Android OS上一个写着“强制关闭错误”的弹出窗口跳上屏幕；当发生崩溃时，iOS中App屏幕突然消失消失。最坏的情况下，App崩溃可能会导致系统故障，操作系统崩溃。

移动App崩溃原因
　　为什么移动App经常崩溃？App崩溃有几个原因：从平台或环境到开发问题。
　　一些崩溃原因（排名不分先后） ：
　　设备碎片化：由于设备极具多样性，App在不同的设备上可能有表现不同。
　　带宽限制：带宽不佳的网络对App所需的快速响应时间可能不够。
　　网络的变化：不同网络间的切换可能会影响App的稳定性。
　　内存管理：可用内存过低，或非授权的内存位置的使用可能会导致App失败。
　　用户过多：连接数量过多可能会导致App崩溃。
　　代码错误：没有经过测试的新功能，可能会导致App在生产环境中失败。
　　第三方服务：广告或弹出屏幕可能会导致App崩溃。

　　移动App崩溃的测试用例设计
　　测试用例是移动测试最重要部分之一。
　　准备和执行预先定义的针对移动App崩溃的测试用例将简化和加速移动App崩溃的测试。
　　一些通用的触发移动App崩溃的测试场景，如下：
　　1 验证在有不同的屏幕分辨率，操作系统和运营商的多个设备上的App行为。
　　2 用新发布的操作系统版本验证App的行为。
　　3 验证在如隧道，电梯等网络质量突然改变的环境中的App行为。
　　4 通过手动网络从蜂窝更改到Wi-Fi ，或反过来，验证App行为。
　　5 验证在没有网络的环境中的App行为。
　　6 验证来电/短信和设备特定的警报（如警报和通知）时的App行为。
　　7 通过改变设备的方向，以不同的视图模式，验证App行为。
　　8 验证设备内存不足时的App行为。
　　9 通过用测试工具施加载荷验证App行为。
　　10 用不同的支持语言验证App行为。
　　显然，还会有更多的导致App崩溃的App特定场景。

————————————————
版权声明：本文为CSDN博主「玉萱」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/u012938881/article/details/46004041

===========================分割线=================================

在测试的过程中还遇到了一些其他的情况，正常来说这些情况是不应该出现的，但是测试的过程中下面这些问题出现的频率是比较多的：

1. 没有做空指针防御造成的闪退；

2. 接口返回的数据不是预期值，解析数据失败导致闪退，（边界值的测试还是比较重要的，可能设计也存在一些问题，接口返回的值是否返回单位，从而导致解析出错）；

3. APP如果可以使用百度地图或者高德地图，切换地图出现ANR，遇到过是因为实现方式：重新创建新MapView，并且移除旧MapView，从而导致anr（最后是改为二者共用同一个MapView，解决了此问题）

虽然有很多时候是因为接口返回数据的问题导致的闪退，但是对于这种情况APP也不应该完全依赖接口的正确，任何情况下APP都应该保证不会闪退，崩溃。