测试人员做BUG分析的必要性
- 2018-05-23 20:30:00
- 小熊 原创
- 5542
通常情况下,大家普遍更加关注生产上出现的问题,对于测试环境的BUG呢,解决完了也就完了,很少再去关注。自然就没有挖掘出BUG背后的有效信息。
最近小熊在着手进行质量持续改进,试着将各项目测试环境的BUG导出,整体上进行分类,归因,看看能否找出问题背后的问题。
发现啊,其实人家BUG也是一个小可爱呢?
我们可以通过BUG暴露的信息,更好的了解自己哪里比较薄弱,哪里需要加强。
质量管理的帕累托图法表明,一般80%的问题,都是由20%的原因引起的,希望我们也能总结分析出那背后的20%原因来。
平时在测试过程中,一般发现问题,待开发解决,再回归验证,就基本结束了。
很少有人会多想想,这些BUG为什么会产生呢?什么原因引起的呢?
目前很多公司都是迭代开发模式,一个迭代,一个迭代,循环往复不停歇!
所以测试人员可能并没有过多的经历来分析过往的BUG。
BUG所暴露的基本信息都被忽略了,自然也无法被发现。
这件事是非常有意义的,如果我们能通过归因把BUG产生原因找出来,从设计和开发阶段就改进的话,那么很多情况在设计时纳入,则问题就没有必要流转到测试环节了。
下面是小熊以界面上简单的一个BUG为例,分析BUG的时间花费情况。对于流程和复杂场景要涉及多个动作,以及测试数据的准备等,所以时间花费更多些。
【BUG一次修复的情况】
【需要修复两次解决的情况】
【一次测试通过的情况】
看到上面的BUG时间成本了吧?
测试和开发的小伙伴,每天有好多时间,就这样在与BUG的缠绵中度过了
不禁想起那首《时间都去哪了》...
小熊的BUG分析工作刚刚开始,说说小熊发现了哪些问题吧!
例如小熊发现在一些问题主要是界面没有明确标准、异常方面没有考虑,SQL错误、提交并发等等。。。
当有了这些发现后,需要对每种情况制定相应的预防方法:
界面问题的预防:可以把相应的要求增修订到开发规范,
异常情况的预防,则需要在开发设计阶段引入;
SQL错误的预防则是要求开发写完代码进行自测;
并发问题定为界面标准 等等。。。
每个公司的情况不同,大家都可以分析分析,定有收获!
小伙伴们如果不知道怎么开展BUG预防,大可以百度“BUG预防”,会搜索到很多场景。 事上无难事,只怕有心人,方法总比困 难多哈~~
希望大家在质量这条路上越走越远,越来越好。
另外小熊正在读《质量免费》这本书,书中的很多观念都非常棒,推荐对质量感兴趣的小伙伴看看。
本站文章以及相关内容除注明 转贴外,均为本站 原创或 翻译。
如果本站转载的文章涉嫌侵犯了您的权益,请在评论区留言或是邮件联系管理员及时删除 【admin@luckyframe.cn】
本站原创或是翻译的文章欢迎任何形式转载,但请务必 注明出处以及链接,尊重他人劳动成果,拒绝剽窃从你做起。