自动化工具 请教下自动化失败的用例会做失败统计的原因吗？
状态
目前自动化平台基本完善，属于堆自动化用例的过程中，在跑用例的时候，总会有因各种情况导致用例失败。
思考过程
失败用例很正常，如何正视这种失败，如何避免这种失败情况呢？
结果输出
因为现在用例不多，失败也分很多种情况，那就不如先收集下失败的用例数据吧，做个整理归类。
在报告中，对于失败的用例进行选择性的收集，进行存储，在失败页面展示出来，在进行错误类型划分，备注上失败情况。
当前知道几个原因是什么造成：
1、写 case 的时候与真实的环境不同导致
2、断言数据时，对业务不熟悉，有些字段没数据忽略了
3、脚本执行时，过程中缺少等待时间，不确定性因素
效果
1、要说这样有用吗？会不会太麻烦了？
现在用例特别少，有一些作用，通过这里可以清晰的认识到失败的原因和改进的过程。但我不清楚用例量上来后，是否会有不一样的效果。
请问下做自动化的同学们，是否会思考这样的过程？
我们有非代码错误，100% 成功率的要求，其实你统计出来的问题最终，还是得归纳到用你的这个平台，如何写出高可维护性的测试用例。这个目标去前进
根据我自己的和面试时问的，大部分自动化报错原因会是如下
- 网络波动
- 用例不规范
- 环境不一致
- 测试数据问题
- 第三方服务依赖
然后如果要保证回归质量，减少不必要的排错，就跟楼上说的一样，做好高可维护的测试用例是目标，需要做到这一点就不得不提一个必要条件：充分理解业务
自动化很关键一个指标是可靠性，特别是巡检类的，经常有本应该成功的失败了，或者本应该失败的没卡住，那对业务来说这就是鸡肋，首先会让人觉得这个不可靠，一次两次会人工确认，次数多了谁还看呢
设计自动化用例的时候就要考虑是否可靠，如果是为了覆盖率硬上一些不太可靠的用例，最后会浪费更多的时间去排查自动化失败的原因。所以源头还是设计之初就要充分考虑并自测到位，适时地舍弃一些用例，放到手动回归部分
