移动app测试与传统台式机测试相比有一定的复杂性。这些复杂性可以被分类为：
环境(大量的设备，各种移动oss，适应频繁oss变化) 。
设备(触摸式和非触摸式设备，有限的内存容量，电池耗电量) 。
网络(不同的网络和运营商，在不好或无网络的情况下的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特定场景。
结论
在这项研究中，展示了针对移动app崩溃的通用测试案例。
如果移动测试团队在他们的测试场景中准备并执行这些测试用例，那么早在开发周期就可以找到崩溃相关的bug。然后，开发团队将阐明崩溃原因，并找出一个解决所有bug的通用方法。 后，app质量和用户满意度就会增加。