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

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

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

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

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

目前我得做法是每次执行前都清除 app 缓存，固定执行一些前置操作（封装成一个固定得脚本），后面再执行具体功能操作，这样虽然保证了每一个 case 独立，但是整体用例执行耗时很久（大部分都是下班后执行，偶尔上班得时候执行），铁子是什么思路嘞

好奇大家是怎么解决用例在批量执行得时候，因为中间用例失败了，导致后面用例执行都失败得问题呢，小菜鸡一枚！！！

这年轻人

铁子，不说了，我创业去了，自己当领导，妈蛋

希望领导早点看到，好歹也是加了好多次得班做出来得，不用可太难受