定期做Bug的分析和汇总

   由于公司计划年底进行CMMI4的过级预评审，最近天天在进行“中国式”的CMMI工作：大量的准备更新文档。在四级中有一个比较重要的方面就是度量与分析。工时，项目规模，劳动生产率。。。bug分析也是一个很重要的方面，一般在里程碑点的时候需要做着方面的工作。

   一般来说我们对于bug有不少分类的方法。

   按照功能区域，模块来分。

   按照严重程度来分，一般情况下bug的严重程度分为4等，1-Low，2-Medium，3-High，4-Catastrophic。

   按语言来分，这种bug发生在那些语言上面。按目前bug的状态来分，open, fixed/resolved,closed。

   按bug被处理的方式来分. code change, not a defect, will never fix, specification change

   不管大家用什么方法来分，定期的对之前报过的bug进行分析汇总，对我们的测试会有很大的帮助。将收集的数据生成相应的chart,柱状图，饼图随你选择。

   比如我们按照bug被处理的方式来分，发现近一个月之内上报的很多bug，都被开发人员标为not a defect.这个时候我们需要考虑分析一下了，为什么有这莫多的not a defect的bug。这里面的原因有很多: 开发人员对于需求文档的理解不透澈，有歧义.测试人员对需球的理解有问题，测试执行过程出现了问题。对于这些进行了分析之后得出原因，可以就此对下阶段的工作进行相应的调整。

  如果我们按照功能区域来进行分析。可以清晰地看到各个功能区域存在的bug现状。对于发现bug少的区域，我们可以在下阶段的测试中侧重对该区域的测试安排，在这区域做更多的ad hoc测试，发现没有覆盖到问题。对于bug多的区域还可以进行“嵌套”式的分析，从另外一种方向进行分类。

  做这些数据分析，可能会花费一定的时间，但是回报绝对是大于付出的，呵呵！