实际工作中,大家如何测试 APP Crash 场景的?
已经收集到的资料,一些崩溃原因 (排名不分先后) ：
设备碎片化：由于设备极具多样性，App 在不同的设备上可能有表现不同。
带宽限制：带宽不佳的网络对 App 所需的快速响应时间可能不够。
网络的变化：不同网络间的切换可能会影响 App 的稳定性。
内存管理：可用内存过低，或非授权的内存位置的使用可能会导致 App 失败。
用户过多：连接数量过多可能会导致 App 崩溃。
代码错误：没有经过测试的新功能，可能会导致 App 在生产环境中失败。
第三方服务：广告或弹出屏幕可能会导致 App 崩溃。
实际上大家如何去测试崩溃场景的呢？设计测试用例的呢？
Hu
回复
额，有些原因造成的崩溃本身就没有稳定复现步骤的，比如内存占用过大导致被系统强制 kill 掉这类。
你们没有接入 bugly 之类的崩溃自动采集上报平台么？一般崩溃的处理主要通过分析错误堆栈信息来处理，而不是要你绞尽脑汁去想办法稳定复现。。。有不少崩溃是多种综合因素引起的（比如涉及此时内存数据的状态、服务端返回的值内容、多线程下的锁管理等），不是你固定做一样的 app 操作步骤就可以复现的。
另外，除了 monkey ，像 fastbot 这类智能遍历工具也可以拿来用，这样页面覆盖率更有保证。
crash 吧？
额，个人觉得，你这个分类层级太高，场景太多，会导致测的成本很高。有好几种其实背后都是一个原因（比如带宽限制、网络变化、用户过多，本质上都是网络库处理相关的逻辑处理不够完善，导致极端情况下会出现未被捕获的异常引起 crash ）
一般比较少专门测 crash ，真的测更多是针对第一点，用云真机平台的 monkey 或遍历这方面的能力去跑。其他的更多通过日常功能测试中的异常路径测试 + 部分特定场景专项测试（如弱网）+ 线上崩溃监控预警 来发现。
陈恒捷
回复
有简单的用 monkey 在本地跑，但比如这次复现了，但下一次又没有复现？实际的工作环境又没有提供云真机平台，由于安全问题或者费用问题，都是用固定的手机去测试的情况下，去测试。
而且 monkey 测试命令那么多，用哪个命令较好呢，比较苦恼。
下面是实际跑 monkey 命令跑出来的崩溃，但第二次没能复现，感觉出现概率比较随机。
Hu
回复
额，有些原因造成的崩溃本身就没有稳定复现步骤的，比如内存占用过大导致被系统强制 kill 掉这类。
你们没有接入 bugly 之类的崩溃自动采集上报平台么？一般崩溃的处理主要通过分析错误堆栈信息来处理，而不是要你绞尽脑汁去想办法稳定复现。。。有不少崩溃是多种综合因素引起的（比如涉及此时内存数据的状态、服务端返回的值内容、多线程下的锁管理等），不是你固定做一样的 app 操作步骤就可以复现的。
另外，除了 monkey ，像 fastbot 这类智能遍历工具也可以拿来用，这样页面覆盖率更有保证。