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

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

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

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

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

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

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

这年轻人

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

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

嗯嗯，是的，感觉你们这个用自动化就太省事了

你是懂领导得

可能公司还是更需要我们手动点点点吧，苦涩

嗯呢，我觉得还是有点用的吧，起码前期投入了一部分时间，项目也跑起来了

雀氏，我当时说可以节约一点回归的时间；然后后期是可以尝试替换手动接口测试，开发单测可以，感觉还是能省时间的

我们根据客户提供的信息，在指定设备上，还是复现不出来；好在沟通之后，客户还是同意了，先上线，不知道大佬有没有好的方案，针对于这类问题的解决方式

情况是在弱网情况下，就一个列表页面加载不出来，正常网络没啥问题，反正后面反馈给项目经理，项目经理跟客户进行了沟通，还是上线了；但是我想的是，万一遇到客户不讲理，就说一定要解决，有没有好的预案来专门处理

我后面也是这样打算得，把单模块中有关联的用例组合在一起，形成一个完整的业务场景用例

嗯嗯。了解了

确实，其实后面我们也会交叉测，按照这种方式只是提前交叉了，也挺好。

前辈说到的第三点中提到数据流和业务流，我可不可以这样理解呢，业务流就是评论中有提到模拟客户业务场景，而数据流其实更多体现在接口之间的交互，数据的传递，这个我觉得在接口测试的时候做会不会更好呢。

今天跟我们公司大佬沟通了一下，后面计划我们把不同模块有关联的用例，抽离出来，单独形成一个完整的业务流程用例，这样到时候我们回归和开发自测都可以用到。后面我私下跟开发也沟通了一下，他们想要的就是这种，完整的业务流程用例。那个业务用到的就是埋点，跟你讲的一样。埋点是在其他模块写的用例，展示的地方也有很多，我写的客户模块就包含。当时我对我写的客户模块进行评审，开发就说流程不完整。

前辈，你的意思是说你们会写两份用例么，一份是单独的功能模块的，一份是整个流程的么？那人员是怎么安排的呢，是单独安排一个人去做，还是说，你们做完单模块之后去做。

嗯嗯，我最近也在思考，针对业务完整流程的功能测试用例是不是也需要写一下，因为我习惯在接口测试的时候，通过接口对某一个业务走完全流程，包含数据的流向，落地到数据库，业务逻辑等

谢谢推荐