前言
之前写深入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暴露,还是质量控制都需要团队成员共同努力,把交付稳定的产品作为每次迭代的最终目标。或许你意识到了这一点是一回事,而真正落实到行动上又是另一回事了,但无论如何,都要以自己业务和测试的实际需要为前提了。