上线前打个测试包先进行测试

通过云测平台提前进行大规模批量的稳定性测试，提前发现问题

1. 如果奔溃是功能性产生的，可以考虑跑个 monkey 测试之类的， 多覆盖一些随机的操作
2. 如果奔溃是跟设备兼容性相关的， 检查一下兼容性的测试策略， 还有找云测平台跑一下不同的设备。
3. 做好奔溃日志收集，定期检查分析，找出可能存在的问题。

测试前跑一下 fastboot，可以多跑一下机型

如果是功能导致的话 上线前回归用例整理好 多留些时间做好上线前回归

没有灰度吗？ 灰度完之后看下崩溃率，崩溃率高了就让研发排查修复，继续灰度，崩溃率达标在上线。

上线前有做这个操作得，但是测试环境没有那么大用户量，很难发现问题

有考虑得，但是出于成本考虑（降本增效），应该不会采用这种方案

大部分时候都是由于开发新功能，开发那边影响面没有评估全，影响到其他老功能了；那些老功能不是常用得，所以也不在回归用例里面，有时候是在灰度得时候线上监控就发现了，有时候是全量才发现；后面也复盘过，崩溃出现得位置都很随机，如果都放回归用例里面，感觉没必要；monkey 也跑过，实施下来，没有太多作用；云测平台出于成本考虑，暂时不会考虑

如果是新功能影响到的老功能，说明你们的回归测试策略不完整。
有没有必要都放到回归测试里面，是基于风险去评估的， 很明显你们现在的情况就是需要加上。

想问下，所以崩溃率大概是多高？百分之多少？

老功能不常用，所以没回归，但灰度或全量时用户会遇到，而且遇到得还不少导致你们崩溃率高。“不常用” 和 “崩溃率高” 两个有点矛盾。

目前是没有去做精准测试得，所有影响面全考经验评估；回归测试主要是对当前版本新增得功能及影响面 + 历史重要功能回归；基于最近几次出现崩溃得点，很多功能都是几年没动得功能且功能非重要功能，出现位置很随机，把这些加入回归，感觉意义不大；

你的分析是什么，说了一个问题，然后让我们大家猜想 贴合你的情况？提供的信息也太少了，给不了什么建议

第一点：为了保证用户体验，部门内部定的是崩溃率达到万五，就要考虑换包了；
第二点：是我表述的有问题，不能说不常用，只是没有归到回归点里面；所以我们回归的时候都不会点到，但实际用户还是会用的

笨办法，每次出现的位置都加入回归里，也加不了多少吧，只增加回归崩溃的场景工作量也不多，这是必要的对于崩溃来说；而且出现那么多次总有个原因吧，既然能影响到其他老功能说明这块代码有关联性或者通用了，那每次开发就应该找全影响点提供给测试覆盖，或者可能的范围也行啊。

这其实是你们的策略制定的出发点是什么， 如果说纯粹从技术角度来看， 没问题；
但是从质量管理的角度来看， 已经有客户会在实际使用的时候遇到这种奔溃的问题，而且从你的描述来看，不是随机的小概率事件，而是某些功能你们选择性地不去回归，没有发现问题。

既然能统计到崩溃率应该是有接入第三方或者公司自己有日志回收的。回收的信息里面都是有具体的报错的，按照占比高低着重分析出现的问题是什么。
根据过往的经验（多年前，不确定现在是否适用），最多的应该是空指针，其次是数组越界，再次是 OOM。
首先最简单的，OOM 可以通过 adb 调用具体的页面类重复加载对比数据看出来是否有；
然后数组越界比空指针好处理一点，测试的时候自己 mock 数据多测试一下边界值；
最后空指针这个跟接口数据有关系的直接可以 mock，还有一些是页面之间的数据流转与依赖导致的本质上也是可以通过自己控制接口数据返回有效降低的。以上是技术方法。
非技术方法：分析开发人员的特性，针对开发人员设防进行针对性的测试。大部分的这种崩溃实际上都是个别开发人员代码习惯不好导致的。

是功能性的必现崩溃还是部分机型兼容性问题，还是新版本的功能影响旧功能，且没测导致的崩溃，你说清楚

又要不测试，又要质量好，的确很难办

那看来应该和开发去一起商讨下问题，修改涉及到旧功能开发应该给出测试范围的，频繁出现这种问题是需要开发也去反思的，毕竟敏捷迭代不可能要求测试全量回归

同意啊， 已经很明显出现了奔溃的现象， 还在想着没必要加入回归测试，我没办法理解。
所谓回归测试，就是即使没有任何改动，也要去回归一遍， 保证功能正常。 因为就算没有代码的改动，也不能保证所有的依赖（服务器，操作系统，浏览器等等）可能的变化对功能的影响。

之前项目遇到的类似的情况，测试环境只有部分机型，每次回归测试都不会出现崩溃的情况，但是线上会出现。解决方案是开发加个奔溃时上传日志的功能，上传 bugly 然后进行分析异常，然后开发改 bug，测试回归，直到线上奔溃率降低到一定程度。 注：这个过程响应要高效...不然线上用户会爆炸的