每当我们完成一个版本测试时，总会在测试报告中添加一些分析bug的指标 ，主要用于分析在测试过程中存在的问题 。但是在分析的过程中你就可能遇到如下的问题 ：
我应该分析那些指标呢 ？每一个具体的指标该如何分析 ？它能说明什么问题 ？
你若想要答案 ，不妨从以下三个问题入手 ，能回答了以下的三个问题，答案就呼之欲出了 。
为什么要进行bug分析 ？ 它对我们工作有什么帮助 ？
bug分析具体要分析什么 ？ 即它有那些指标 ？
该如何进行bug分析 ，它们能说明什么问题 ？
1.为什么要进行bug分析 ？
通过bug分析，对我们测试工作有两个好处：
通过bug分析 ，能发现在测试过程中存在的一些问题，这些问题主要产品质量和测试效率上的问题 。
通过长时间bug的分析 ，建立bug分析数据库 ，从而在批量数据下找到规律，从而为后续版本测试提供一些可靠建议 。
bug分析发现问题
在测试过程中，最常见的一个bug分析指标就是 ，时间和bug数量的折线图 。通过这个指标我们就可以看出bug是否收敛，从而判断出项目是否已经稳定，从而决定能进行上线了 。那如果这个折线图一直是上下抖动 ，说明目前产品质量还不稳定 ，需要再继续测试 。
当然，通过一个指标是不能说明整个测试过程的问题的，需要将一些有效的指标都结合起来分析，才有可能得出比较可靠的结论 。
bug分析建立数据库
偶然只去分析一个版本，不足以去发现一些规律性的问题 ，而且也不容易积累经验 。所以 ，我们将每一个版本的数据都要搜集起来，进行纵向比较，就会发现一些固定的影响因素 ，即长期潜在的问题 。如若它是相对固定的问题 ，你再拿着这些问题也同样预测到后续版本也会出现这样的问题 。 通常情况下，一旦此类型的问题被解决，改善效果就会很明显 。最后就可以拿着这个指标去监控当前测试状态是否健康 ，与预期的曲线相符合，说明测试状态健康 ，反之就不健康 。
2.bug要分析什么 ？ 具体它有那些指标 ？
在上面我们只列出了一个指标 ？ 那么一个迭代测试中，我们到底要分析那些指标呢 ？第一是对产品质量评估的指标，即产品质量在测试过程中是否健康 ？ 是否已经达到上线标准 ，都需要通过这些指标查看 。第二就是对工作效率的评估的指标 ，主要包括测试效率和开发效率 ，写开发效率是因为它会影响到测试 。评估它们是否对测试进度产生影响 ，从而影响整个上线工期 。
bug趋势图 ：就是上面的那个截图 ，主要是查看随着时间的推移，bug数量的变化 。通过此图我们主要关注产品质量是否稳定，是否具备了上线条件 。
bug修复情况 ：在最后一轮测试是否出现二级及以上bug ；必修bug是否已修复 。通过这两个问题主要关注重点问题是否已被修复 ，不会导致影响产品质量。
bug修复和关闭的及时性 ：即bug修复的快慢速度 ，bug被关闭的快慢速度 。 这两个及时性主要关注的是测试过程中流程执行的是否正常 ，是否因速度慢导致质量或进度产生偏差。
用例执行和非用例测试产出bug比 ： 即通过用例发现的bug数和非用例发现的bug数的比率值 ，这个值一把是维持在一个固定的范围值内 ，太高或太低都说明用例写的有问题 或者 其它测试方法使用的有问题 。
bug有效率 ：就是提交已修复的bug占总bug数的比率 ，通过这个比率我们来判断测试人员的业务水平
bug激活率 ： 就是通过回归测试重新激活的bug占总bug的比率 ，通过这个比率我们来判断开发人员的开发效率 。
3.该如何分析bug ？
具体指标知道了 ，在实际的版本测试中该如何进行分析呢 ？
bug趋势图分析 ：
该指标主要关注的是中间的波动和最后的收敛情况 。
曲线上升可能产生的原因有：合入或修改了新功能 ，使用了新方法 ，功能未完成一轮测试 ，随着业务的熟悉测试出前期遗漏的bug ；若曲线下降很可能是测试方法已经失效 ，功能已经完成一轮测试 。
最后的曲线一定要收敛才行 ，否则说明产品质量不稳定，不具备上线条件，考虑进行延期测试。
bug修复情况：
在探索式测试里曾有这样的说法 ，在最后回归测试期间 ，要谨慎的测试(即不能随意的测试) 。如若这样测试，还是在最后一轮测试中发现了一二级bug，那只能说明前面的测试没有做好 ，同时该bug也可能影响产品上线质量，因为它是最后期发现重要的bug的，不修改不行，修改的话又可能引入新的bug 。这也是为什么我们要关注这个指标：'在最后一轮测试是否出现二级及以上bug' .
当然 ，我们也要关注主要bug是否在本次上线前已经修复 ，因为它影响产品质量 ，所以重点bug也要进行关注 。
bug修复和关闭的及时性：
一般bug被提出后1~2天能是应该被修复的 ，如若该时间拉长了 ，它不仅仅是延长了我们的修复时间，更主要的是它很有可能产生新bug而影响产品质量的稳定性 。
bug回归的及时性也同样如此 ，如若回归的太晚 ，就可能会导致回归出新bug而导致的产品后期不稳定。
用例执行和非用例测试产出bug比
此指标已经在‘如何进行测试用例的分析’一文有详细说明，这里不在赘述 。
bug有效率和bug激活率
bug有效率主要关注测试人员提交效率，如果这个值很低 ，说明测试人员对业务理解上有问题 ，或者理解能力比较差，亦或者是业务准备时间上不足 。同时如果这个值很低说明我们的测试效率也低 ，拉长整个改的生命周期 。
bug激活率主要关注的是开发人员修复效率 ，如果这个值很低 ，说明开发人员修复bug逻辑上有问题 ，或者技术水平存在问题 ，或者是态度可能有问题 。同时这个值很低也会影响测试和开发的配合效率，拉长整个改的生命周期 。
