测试人员做BUG分析的必要性

通常情况下，大家普遍更加关注生产上出现的问题，对于测试环境的BUG呢，解决完了也就完了，很少再去关注。自然就没有挖掘出BUG背后的有效信息。

最近小熊在着手进行质量持续改进，试着将各项目测试环境的BUG导出，整体上进行分类，归因，看看能否找出问题背后的问题。

发现啊，其实人家BUG也是一个小可爱呢? 

我们可以通过BUG暴露的信息，更好的了解自己哪里比较薄弱，哪里需要加强。

质量管理的帕累托图法表明，一般80%的问题，都是由20%的原因引起的，希望我们也能总结分析出那背后的20%原因来。

平时在测试过程中，一般发现问题，待开发解决，再回归验证，就基本结束了。

很少有人会多想想，这些BUG为什么会产生呢？什么原因引起的呢？

目前很多公司都是迭代开发模式，一个迭代，一个迭代，循环往复不停歇！

所以测试人员可能并没有过多的经历来分析过往的BUG。

BUG所暴露的基本信息都被忽略了，自然也无法被发现。

这件事是非常有意义的，如果我们能通过归因把BUG产生原因找出来，从设计和开发阶段就改进的话，那么很多情况在设计时纳入，则问题就没有必要流转到测试环节了。

下面是小熊以界面上简单的一个BUG为例，分析BUG的时间花费情况。对于流程和复杂场景要涉及多个动作，以及测试数据的准备等，所以时间花费更多些。

【BUG一次修复的情况】

【需要修复两次解决的情况】

【一次测试通过的情况】

看到上面的BUG时间成本了吧？

测试和开发的小伙伴，每天有好多时间，就这样在与BUG的缠绵中度过了

不禁想起那首《时间都去哪了》...

小熊的BUG分析工作刚刚开始，说说小熊发现了哪些问题吧！

例如小熊发现在一些问题主要是界面没有明确标准、异常方面没有考虑，SQL错误、提交并发等等。。。

当有了这些发现后，需要对每种情况制定相应的预防方法：

• 界面问题的预防：可以把相应的要求增修订到开发规范，

  
  

• 异常情况的预防，则需要在开发设计阶段引入；

  
  

• SQL错误的预防则是要求开发写完代码进行自测；

  
  

• 并发问题定为界面标准 等等。。。

每个公司的情况不同，大家都可以分析分析，定有收获！

小伙伴们如果不知道怎么开展BUG预防，大可以百度“BUG预防”，会搜索到很多场景。 事上无难事，只怕有心人，方法总比困 难多哈~~

希望大家在质量这条路上越走越远，越来越好。

另外小熊正在读《质量免费》这本书，书中的很多观念都非常棒，推荐对质量感兴趣的小伙伴看看。