在测试完成一个特性模块后，对测试过的进行总结分析，可以有效帮助我们总体掌握软件的质量情况，产出后续工作的思路和重点。

　　针对一个模块特性的质量分析，个人有几点心得：

　　1、测试用例覆盖

　　主要看无覆盖的用例主要分布，当前发现的bug是不是通过用例测试出来的，有多少不是通过用例测试出来的。

　　这些通过用例测试不出来，需要分析是不是测试用例质量问题？需求遗漏？历史遗留问题？其他等等

　　通过用例的覆盖程度，分析是不是用例存在较大的问题，是否需要补充评审分析用例的覆盖和添加用例，以及后续是否需要加强测试。

　　2、bug缺陷分析

　　通过发现的bug分析，缺陷分布在哪一方面。

　　一方面分析得软件处理比较薄弱的地方，进行加强测试；一方面通过分析得出一些缺陷预防的思路，避免以后也会犯同样的错误。

　　最后看看，bug的产生原因。（低级问题？应该在那个阶段被发现？）可以从另一个侧面反映开发的水平。

　　3、测试人员的执行质量（执行力）

　　测试人员的业务知识（行业知识：如金融，通讯设备，互联网等都有各自的业务知识）和软件的设计原理有没有理解清楚；

　　如果是新手那么需要相应的措施（检查，考评等）确保是否能达到期望。

　　4、改动大小，改动引发bug，bug回归

　　这个主要是后期需求变更或者修复bug改动引起的风险。如果有自动化的话，这个就比较简单。

　　虽然在回归bug的时候，会对改动的地方进行验证和测试，但是bug改动较多的时候难免会有可能引人风险。

　　5、代码覆盖率

　　代码覆盖率跟用例覆盖率关联比较大，用例覆盖的全面代码覆盖的也就全面。当然单单从黑盒角度的用例在覆盖全部代码，多数情况是覆盖不全面的。

　　这个时候需要开发参与，分析当前测试过的点是否还要那些地方没有覆盖到，通过白盒灰盒角度考虑进行补充覆盖。

　　代码覆盖率也可以通过工具帮助分析，这些方法我暂时还不清楚实现原理。

　　6、与历史数据的对比

　　一般对比下历史的数据，比如说bug数量，可以有一定的参考性。如历史版本一般能发现100个左右bug，而当前版本只发现50个，

　　那么就需要全面分析这到底是还有较多bug没有测试出来，还是版本质量稳定。

　　7、代码检视

　　这个我没有做过，但是往往代码检视做的好的话往往能发现一些隐患。这些隐患可能不会立即带来bug，但是可能对于后续扩展性后续维护不利等，这些一般是有经验的开发进行代码检视。测试跟踪代码检视后续修改的地方，进行补充测试。以防止改出问题。