如果把产品的诞生当作一场马拉松，那bug就是那些年我们踩过的坑。从哪儿跌倒就从哪儿爬起来，通过分析找到bug产生的根因，思考如何从各个方面去优化改进，避免以后踩到类似的“坑”，下一场比赛才能跑的更快更远。
为什么要做bug分析报告？
- 借助bug，便于测试人员对产品质量的整体把控；
- 根据bug统计分析，为决策者提供退出测试的依据；
- 追本溯源，重新审视项目过程，推动流程改进优化；
那，怎么做好bug分析？
项目整体bug统计分析
主要为制定测试策略和决策是否退出测试做数据支撑；该部分通常附在测试报告中。
1、bug的修复率
bug修复率=bug未修复数/bug总数。
这是衡量是否退出测试的指标之一，如：bug修复率＞95%。
2、模块分布
bug在各模块的分布情况。
通过分布统计，根据“出现bug的可能性，与该模块已经发现bug的数量成正比的规律”，可以得出产品风险主要集中在哪些模块。
3、bug严重程度分布
bug在各严重程度的分布情况。
是衡量是否退出测试的指标之一。如：通常退出测试指标中要求不遗留严重等级为高及以上的bug，一般和轻微等级bug在一定数量内。
4、模块-严重程度分布
bug在各模块各严重程度的分布情况。
结合模块优先级，决策是否退出测试的依据之一。
5、bug迭代版本（时间）分布
Bug在各迭代版本（时间）的分布情况。
通常结合模块、严重程度综合统计分析，反映产品测试情况，为测试负责人制定测试策略提供依据：
根据“bug迭代（时间） - 模块”分布，得出主要的风险模块，从而针对性加强做好测试；
根据“bug迭代（时间） - 严重程度”分布，可以判断当前的测试状况，如bug数随迭代版本（时间）明显减少，bug严重等级高的bug明显减少，在时间允许情况下，可以引入交叉测试、Bug Bash等测试策略。
bug收敛曲线（反映测试情况是否良好）
即使错误数量从整体上开始减少，但具体数量还会出现升降变化，因此错误收敛通常来讲只代表一种趋势，而不是一个固定的时间点。在错误收敛之后，错误的数量将持续减少直到零错误反弹。
实际项目“测试版本迭代— bug状态统计”例子：
Bug产生原因、处理等环节的综合分析
旨提高人员质量意识，针对性做过程改进，提高后续项目效率、产品质量；该部分，通常作为项目测试总结的重要组成部分。
6、人员-bug分布
开发人员bug分布统计。
通常与bug类别、严重程度结合起来统计分析。用于衡量开发人员编码质量。
7、bug往返次数分布
往返次数：即单个bug开发修复和测试重新打开的周转次数，直至确认修复并关闭。
通常与人员结合起来统计分析，能反映bug的修复效率。大于1次的bug分布越多，则效率越低。
为后续提高bug修复率，进行流程改进，人员培训提供依据。
8、bug重复率
重复提交bug的几率，即：重复bug数/bug总数。
此反映了测试任务的划分合理性，重复率越高，则越不合理。
可以为后续测试任务划分改进做数据支撑，为改进结果做衡量参考点（即改进后，bug重复率与之比较，越低则越有效）。
9、bug无效bug统计
即确认不是bug的统计。
通常与人员、原因结合起来统计分析。分析其中是否因为测试人员自身原因致使提交过多的无效bug，以便决定是否后续对其进行培训和指导。
10、bug原因分析统计
分析bug出现的原因，对bug原因进行归类整理。
根据bug原因统计，为后续过程改进提供依据。如：bug主要集中在需求上，则加强需求评审环节；如bug主要出现在开发员明显粗心犯错，那应该对其加强培训和指导。
关注小酋微信公众号 ceshibuluo （51ste软件测试部落），更多精彩内容等着你~