从bug中能得到什么-简述缺陷分析

之前写的一篇文章，欢迎测试交流：

正文：

每一轮测试结束进行缺陷分析是必不可少的，关于缺陷分析和预防的一些方法可以参考：http://www.cnblogs.com/Jackc/archive/2009/02/18/1392657.html；链接中的一些方法讲的有些笼统和理论化，下面主要结合自己的项目测试经验做下简单的总结。

《软件质量管理实践--软件缺陷预防、清除、管理实用方法》这本书中介绍的缺陷度量元感觉很有用处，可以结合一下度量目标以及实际的项目确定适当的度量元。例如，可以按照如下表所示的思路确定组织整体或者项目组个体使用哪些缺陷度量元。

在我们给出的测试报告中可以结合以上各度量元给出相应的缺陷分析，以此来判断被测产品的质量情况以及缺陷趋势。

作为测试人员也应该在分析指标、统计数据的基础上，对软件缺陷状况进行定性分析，发现问题，并向项目负责人和测试负责人汇报相关情况，以此优化测试流程。

如下图是我根据一个实际项目进行的一次简单的缺陷分析过程：

上面的统计结果只是个参考，因为有些bug不好分类，有些bug是交叉测试后发现同事以前测试的模块发现的等等。

通过上面的统计大概可以看出bug主要集中在测试用例未覆盖到，这时最主要进行的就应该是测试用例的完善更新，确定是不是测试用例的有效性出现了问题（关于测试用例有效性可以参考我写的上一篇文章），当然这里面不只是测试用例设计问题，也应该有自己执行测试用例没有多去思考、增加新的观察点的原因。

对于概率性出现的bug，要分析测试用例是否覆盖到，如果没有同上一条；如果有，之前执行测试用例没有发现，就不太好解决，对于测试人员来说只能尽可能重复测试场景，并总结经验，分析原因，是不是其它模块也存在潜在的概率性bug。

回归测试中发现开发人员修改bug引进的新bug，针对这个问题要引起测试人员的重视，如果是开发人员技术和态度问题，那么一个项目多轮次测试时只进行主要功能测试和验证性测试是存在一定的风险。针对测试过程中发现开发人员所犯的一些低级错误，如打包错误，缺陷reopen等等，对于这些问题每轮测试结束时要收集上报给项目经理和测试负责人，力求开发人员作出相应的改进。

通过缺陷分析也可以发现一些其它的问题：测试用例执行情况、测试人员态度、缺陷遗漏、测试方法改进等等。

这里举个简单的例子，一个项目多Build测试，我们分析缺陷：

是否有些缺陷执行测试用例本应该在前期发现，但是实际在后几轮才发现？（当然，这个可能与测试策略也有一定的关系，这个也有可能是有些测试人员本没有执行测试用例，但是测试报告上填写执行）

是否存在Not  A  Bug的缺陷？（分析是开发人员问题，还是测试人员问题）

是否有些缺陷一个人执行测试用例时没有发现但是另一个人执行却发现了（可能与测试用例编写不明确有关系）

是否有些缺陷是在交叉测试时发现的，而这些缺陷测试用例又覆盖不到？

是否有些缺陷是有些同事不断的引入新的测试方法，测试技术以及测试工具发现的？

分析其它组的缺陷，是否有好的测试方法和测试思路引进？

----------------------------