测试基础 求问各位大佬，对于偶现的崩溃有什么好的解决方案吗，平时测试测不出来，一上线崩溃率就不断增大？
移动端测试，平时测试测不出来一上线崩溃率就不断上升，对于偶现的崩溃有什么解决方案吗，如何管理这类问题？求各位大佬不吝赐教。
我抛个砖，楼主有没有收集线上反馈的崩溃的原因，都是哪些原因呢，是因为机型还是某些怪异的操作？
黑山老妖
回复
线上是有监控的，日志是能够收集的，原因自然也能知道。但是测试的时候这些偶现的 crash 并不能暴露出来，所以造成测试的时候测不出来，一上线 crash 概率就有可能增大。所以我想问的是，能够通过一些手段或者方案，在测试阶段就把这些偶现的崩溃暴露出来？
- 自动收集和上报闪退信息，便于后期分析处理。
- 测试阶段，跑跑 monkey 和云测，可以帮助重现问题
就没有人考虑过为什么移动端，尤其是 native，那么容易 crash 吗
我觉得要么操作系统垃圾要么就是编程语言/编译器垃圾啊，没有有志气的大厂想着从根本上解决问题的么……
出点 NPE 就 crash，出点小意外就 crash，试问 PC 上或者 Web 上哪来这么脆弱的~~~
移动端这操性，放在系统架构的概念里面来说就是可用性极差，No Availability~想想就恶心~
APP 的 monkey 不要断，坚持每个版本多个机型试试，线上的机型多且杂乱，不可能每个机型都涉及到，但是主流机型要看看
有没有分析过具体原因？后端返回缺少字段？索引越界？NPE？弱网？框架问题？
分析出原因后就增加用例，针对性的测试；崩溃率很高只能说明测试覆盖率还不够。
测试机型不够嘛。还是特定机型特定版本？
上线前找云测测一轮。覆盖会全点。
日志啥的都监控上。
不可能完全覆盖的，有发现异常或者用户反馈就重点处理呗。
是某个操作有一定概率崩溃，测试有覆盖到只是崩溃的概率低，还是没有覆盖到，属于场景没有考虑到没测到的崩溃
1、先把问题归类。bugly 之类的平台已经会自动按出现次数排序了。
2、寻根问底是什么原因导致的问题。可以参考 5 why 原则，了解到根本原因，再从根本上解决。
假设占比最大的问题，从崩溃平台上看到原因是空指针，可以按照类似下面的套路询问：
- 这个空指针具体是哪个值为空导致的？——xx 属性
- 为啥这个值会为 null ? ——坑爹的服务端没返回这个值
- 为啥服务端没返回这个值？——因为服务端本身存储的数据里就没这个值
- 为啥服务端存储的数据里没有这个值？——因为前面的流程这个值不是必填的，刚好用户没填，所以没有
- 为何对于这个本身服务端就可以不返回的值，客户端没有进行兼容？——当时不知道这个字段是非必填的
- 为何当时不知道？——接口文档没写
- 为何接口文档没写？——以前就是这样的，一直都不会写
- 如果要加上，会有什么困难吗？——接口老是调整，改完代码又得该文档，维护接口文档成本太高了
那问题的原因就比较清晰了：接口文档的维护成本太高，导致客户端没考虑到这个场景，最终导致这个空指针。那解决的方法，可以考虑用 swagger 之类的自动生成接口文档工具生成接口文档，免除接口文档的额外维护成本。当然，也可以更进一步，了解为何接口总是要调整，是否团队人员经验太缺乏导致设计没做好，还是需求改动太频繁导致系统必须配合调整。
同时，也补充一个，使用前判空是一个很关键的编程习惯，可以团队内分享下各种遗漏判空导致的损失，以及形成什么样的习惯来避免空指针异常（调用这个对象的子方法/子属性前，都先判空）。
其实对于 NPE 来说，只从编码角度来说，改改习惯，配合代码扫描就能解决，关键有没有这个意识，最近刚学的杜绝 NPE 的一种方法，后端的 Java 为例，方法有很多，比如善用 Lambda 表达式和 Guava 工具包等等：
List<CodeMissionStatus> sts = baseQueryDAO.codeMissionStatus();
String oldStatusName = sts.stream().filter(f -> Objects.equals(f.getStatusId(), mission.getStatus())).findFirst().orElse(new CodeMissionStatus()).getStatusName();
String newStatusName = sts.stream().filter(f -> Objects.equals(f.getStatusId(), statusId)).findFirst().orElse(new CodeMissionStatus()).getStatusName();
app 崩溃；
这 第一印象就是空指针之类的问题； 其实也可以逆向思考； 这个版本的 app 质量如何，检查版本代码质量 看看 编写方式引起的 异常；
也可以通过 虚拟模拟手机 抓取 app 运行的 dump 进行对比和分析；
其实就是将单元测试纳入测试范畴；是最好的防范措施； 也可以通过市场上 一些 监控数据流的 平台，监控；
监控 + 单元测试 + 应用 app dump + 埋点 多方式的去思考；
题外话哦 ，其实最直接的 就是找一个 android 架构师 看看当前应用 app 架构，应用是否合理，架构会帮你看 开发代码质量的问题；
感觉和我这边服务端某个版本会出现 1-2 台机器 core 一样，测不出来
提供一个蠢办法.
拉研发一起分析线上崩溃的主要场景.把这些场景结合你们的主功能编写对应的自动化用例.【该部分作为每次必过自动化用例】
对于新增功能可以结合自己和研发的建议，选择性的执行对应场景的自动化稳定性.
在每个版本测试期间执行个几万次机型选你们 APP 支持的手机系统版本 [例如 5.X~9.X].大体上是可以跑出一些线上较高崩溃率的 BUG 来.
最简单的方式就是 airtest,uiautomator2 啥的选个顺手的自己工作机搭个环境就可以跑起来了.
还是要先找到奔溃的原因先
我觉得，
难道不应该写代码的好好想一下为啥会 crash 么？为啥 PC 或者 Web 的没有 crash 么？
系统都是一样的系统，只不过代码不是一样的代码，写代码的人更参差不齐。
web 上的，浏览器他家写的么？异常他家捕捉的么？内存他代码去管理的么？crash 表现不一样而已，你 web crash 相当于脚本 crash 没了交互，页面还是正常显示，感知没这么明显而已，浏览器子进程处理，没卡死主进程而已。
写 web 就写一下业务代码，内存泄漏不知道就说别人家电脑卡，浏览器卡的时候考虑过电脑的感受么。
写 PC 的不 catch 致命异常，他正常运行给我看看。
11111
11