分析崩溃
- 功能层面：代码处理问题、未做异常处理等
- 环境层面：操作系统、设备【触摸式设备、内存容量、电池耗电量、屏幕大小、分辨率】、网络、可用性
1.操作系统： 大量的设备，各种操作系统，目前使用最多的操作系统有：Android、iOS、windows、blackberry等等，它们之间的应用软件互不兼容。
2.设备：触摸式和非触摸式设备、有限的内存容量，电池耗电量，屏幕尺寸、分辨率等。
3.网络：不同的网络和运营商，目前我国的三大运营商就有电信、联通和移动，不同的网络制式，如GSM、CDMA、3G等，在不好或无网络的情况下的App行为。
4.可用性：方向，触摸，缩放，分页和导航的局限性，各种干扰，如来电，来电短信，闹钟，和低电量警报等。
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行为。
收集崩溃日志
开发埋点