基于Testin大数据发现，APP崩溃是最常见的Bug，这直接的影响就是用户体验，是造成用户流失的根本原因，也是咱们测试同学非常头疼的问题，如果上线前不能讲这些问题发现……

 

在这里笔者为大家整理了一些通用可能触发崩溃的使用以及操作场景，希望可以帮助大家补充完善基础用例库！

一些通用的触发移动APP崩溃的测试场景，如下：

•   验证在有不同的屏幕分辨率，操作系统和运营商的多个设备上的app行为。

•   在新发布的操作系统版本验证app的行为。

•   验证在如隧道，电梯等网络质量突然改变的环境中的app行为。

•   通过手动网络从蜂网更改到wifi，或反过来，验证app行为。

•   验证在没有网络的环境中的app行为。

•   验证来电/短信和设备特定的警报（如警报和通知）时的app行为。

•   通过改变设备的方向，以不同的视图模式，验证app行为。

•   验证设备内存不足时的app行为。

•   通过用测试工具施加载荷验证app行为。

•   用不同的支持语言验证app行为。

 

当然还有些崩溃主要来自于移动设备本身较为复杂的环境比如：

•   环境（大量的设备，各种移动OSs，适应频繁OSs变化）。

•   设备（触摸式和非触摸式设备，有限的内存容量，电池耗电量）。

•   网络（不同的网络和运营商，在不好或无网络的情况下的app行为，离线支持）。

•   可用性（方向，触摸，多触摸，缩放，分页和导航的局限性，各种干扰，如来电，来电短信，闹钟，和低电量警报）。

 

为大家总结了出现崩溃最主要的原因：

•   设备碎片化：由于设备极具多样性，App在不同的设备上可能有表现不同。

•   带宽限制：带宽不佳的网络对app所需的快速响应时间可能不够。

•   网络的变化：不同的网络间的切换可能会影响app的稳定性。

•   内存管理：可用内存过低，或非授权的内存位置的使用可能会导致App失败。

•   用户过多：连接数量过多可能会导致app崩溃。

•   代码错误：没有经过测试的新功能，可能会导致app在生产环境中失败

•   第三方服务：广告或弹出屏幕可能会导致app崩溃。

 

结语：上述总结的内容仅算抛砖引玉制作，同学们还是需要尽可能多的去积累以及更新迭代贵司的用力库，最好在开发周期中就可以发现可能发现崩溃的bug，将用户体验发挥到极致！