前言
之前写深入bug产生原因分析(一)，这里主要从实际的项目bug中，总结出了实际bug的根源的几个方面。这些问题的解决不但没有对最终交付的产品有所裨益，反而耽误了不少测试时间。现在就简要做下梳理，并汇总自己在处理这些问题时的一些经验。
无效bug： 是针对有效bug来说的。无效bug是指需要花时间修复，但修复后又不会给即将交付的产品带来用户价值的bug。
那些耽误了测试时间的无效bug来源
一、第三方问题
- 第三方的测试环境查数据时断时续的
- 接口返回时有时无
- 第三方的敏感词审核服务的问题
- 短信平台发送验证码问题
- 第三方机制问题。例如：xxx组件的界面代码更新机制
- 消息出现积压时，消费过慢时处理机制
- 接口/服务调用超时
- 权限控制-组织架构调整；
- 第三方数据随着时间的推移数据变少，例如，1周前有数据A--利用数据A新建了信息；现在没有了数据A，导致系统获取数据A有关信息时异常；
- 基础数据-线下与线上存在差异，例如： 线下-长沙市的商圈与线上不一致；
二、本身环境问题
服务偶尔出现超时(例如：访问10次，2次出现超时)
测试数据存在脏数据(例如：之前测试的脏数据没有及时删除，导致测试时发现异常，不得不花时间排查问题)
测试环境不稳定，不能随时ready(例如：一个紧急需求要上线，却发现环境不能使用，此时不得不花时间重新搭建环境了)
三、技术本身限制
例如：OPPO+ UC浏览器，页面下拉滑动不刷新数据
四、与需求不符合
- 页面跳转
- 无结果时显示
- 列表与详情页 时间信息显示 与需求不符合
- 多个端之间操作/交互行为不一致
五、违反了开发/实现规范
- xxx场景下，接口重复调用；
- 多端直接公用数据，导致一端登录信息失效，另一端的异常；
- API不打印日志了；
- 实现异常未考虑；
不规范问题带来的严重问题：日常迭代中的开发人员不断反复重构/修改
如何有效避开无效bug,提升测试效率
遵循的核心原则：采用各种手段，尽可能减少测试被block/测试被干扰
这里的各种手段有：
1、针对第三方问题。 这里是非自己可100%控制的问题，可以结合自己的需要考虑以下方案：
- mock掉第三方服务
- 对第三方监控，一旦发现问题，反馈给第三方
- 测试时，有意识将“和第三方密切交互的实现” 放到每轮的测试后半段进行。 这有点像答题，先易后难的套路了。
2、针对本身环境问题。这里基本可以自己100%控制的问题了，可以参考使用如下方案：
- 测试环境由QA100%控制，并做统一的管理和清理
- 脏数据产生后，及时清理(属于规范类了)
- 对测试数据进行检测，一旦发现“不合格”数据，马上清理
- 一套完整的随时可用的测试环境，100%不耽误测试需求
3、针对技术本身限制问题。这里非人为因素可控制了，所以为了尽可能减少对测试进度的干扰，一旦发现与需求期望、用户使用习惯不符，立即与开发人员确认，并对已经确认为此类问题的bug专门文档记录，并对团队成员一一周知到位，避免对此问题过度纠结。
4、针对与需求不符合问题。此类问题属于产品需求对开发人员周知不到位，可以考虑采取：
- 周知团队产品人员、开发人员此问题，协商方案
- 测试用例评审时强调
5、针对违反了开发/实现规范问题。此类问题属于开发人员虽然对需求实现了，但由于规范没有遵守，可能给后续产品带来隐患，或增加后续技术的重构需求。此类问题，最好由开发人员制定相应的规范，并统一执行，可以考虑：
- 测试人员与开发人员共同商定规范，并落实到执行
- 对发现违反规范的问题，由具体人对原因进行分享
总结
固定的测试周期内，无效bug占据的时间越多，留给真正的bug暴露的时间就越少。这里又回到了统一的质量控制问题了，无论bug暴露，还是质量控制都需要团队成员共同努力，把交付稳定的产品作为每次迭代的最终目标。或许你意识到了这一点是一回事，而真正落实到行动上又是另一回事了，但无论如何，都要以自己业务和测试的实际需要为前提了。