移动App测试与传统台式机 测试相比有一定的复杂性。这些复杂性可以被分类为：
环境（大量的设备，各种移动OSs，适应频繁OSs变化） 。
设备（触摸式和非触摸式设备，有限的内存容量，电池耗电量） 。
网络（不同的网络和运营商，在不好或无网络的情况下的App行为，离线支持） 。
可用性（方向，触摸，多触摸，缩放，分页和导航的局限性，各种干扰，如来电，来电短信，闹钟，和低电量警报） 。
所有这些手机专有的复杂性需要新的针对移动App测试的测试用例设计方案。
根据调查的结果，移动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特定场景
几种常见的类型设计方法
1. 网络异常
通常在网络异常的情况下，客户端发出的请求，没有在一定时间内得到恢复，但是一般都会有一个超时的概念，如果程序在没有处理好的情况下，超时之后无法处理程序的逻辑，则经常会出现Crash。这种问题在网络差的情况下，经常出现，比如浏览论坛的时候，正常网络下访问无问题，在网络极其差的情况下，经常性的崩溃就是属于这个问题。所以，测试的过程中，我会通过拔路由器的网线的方式来进行测试，提交一个接口请求之后，立即拔去路由器的线。这样数据无法正常返回到客户端，等待超时之后，看前端的处理方式。如果处理不好的情况下，就会出现崩溃发生。
2. 内存问题
通常在开发程序的时候，内存的泄露或者没有正常回收，造成程序随着操作越来越多，占用的内存越来越大，最终导致崩溃的发生。
测试的过程中，这类问题会比较麻烦，总的来说，一款内存小的手机在测试的过程中是必须的，我会选择一款256M内存，Android 2.3的机器来进行测试。同时会使用Emmagee的小软件进行检测，当然有一个合理的测试用例也是必须的。根据测试用例来正常跑软件，测试结束之后得到一张关于内存使用的图标，慢慢进行分析，对照测试用力进行分析查看是否能发现内存泄露的操作，如果有可疑的操作就要对其进行重复性测试，还是使用Emmagee的软件，不断的检测一个点。知道确认内存泄露的功能模块。高级的测试还会使用DDMS进行查看，原理基本相同，具体方法可以查看网上写的逻辑。
总的来说，内存泄露对于测试人员，特别是手动测试人员比较困难，但是不是没有方法来进行。
3. 接口返回值错误
通常会遇到接口返回值和预期返回值不相同的问题，如果App前端处理不太周全的情况下，会出现程序崩溃。
在遇到这样的问题的时候，一般会采用协调前台和后台之间的信息来处理。根据公司的经验，一般后台传输数据都需要自己的检测程序来查看具体的接口传输数据，有了合理的工具合理的分析平台才能处理的更好，在此感谢Don， Jason的努力，在能查看接口传输数据之后，确实对测试的工作产生了正面的影响。
4. 手机特定类型错误
因为安卓手机毕竟有着众多的品牌和类型，软件在运行的过程中难免会出现功能和某些测试机器，或者不同UI上出现崩溃的问题。
目前没有太好的方案来解决，一般会采用Testin自动化平台运行App，从测试中发现的问题进行判定是否出现的问题时固定可以重现的。汇总的说，其实Umeng平台还是提供了良好的方式来处理这些崩溃问题，在友盟捕捉到的错误日志中分析，可以不断的提升产品质量。不是做广告，只是告诉大家明智的敏捷开发团队一定会采用这样轻量级的平台来提升品质。
5. 渲染图片出现的问题
因为在Android系统在渲染图片的时候需要加载到内存中，所以App上的一些图如果过大，可以造成崩溃事件的发生。
在系统版本为2.3 一下的手机上容易出现，其实这也是与手机的性能相关的，在2.3以下的时候，通常手机的内存都比较小 256兆 和 512的内存上经常会出现类似的情况。