对已结束项目的BUG分析

joan-lin

前一个项目结束了，现在正处于项目的空窗期，因为要开下一个类似项目，所以老板要求对已结束的项目做一个项目BUG分析，第一次写这种报告，各位大虾们，给点建议吧？
主要是不明白老板想知道什么，一般的数据，查看一下JIRA不就知道了吗？

jenery

测试报告不仅仅包含bug数量，还需要针对这些BUG以及系统本身进行总结
测试总结报告应该包括测试过程的成功与失败经验，从测试过程的管理经验，具体到某个Bug的分析总结，或者是与开发人员合作交流的经验，都可以总结出来。
    测试总结报告应该分析测试的整个过程，如是否合理安排了测试资源，测试进度是否按计划进行，如果没有其原因是什么，如何避免下次出现类似的问题？风险是如何控制的？出现了什么意外情况？下次能否预计到这些问题，等等。
测试总结报告还可以包括一些专门类型的测试经验总结。例如，性能测试采用了什么好的方法？碰到的问题是如何解决的？自动化测试脚本如何编写？应该选取哪些功能模块进行自动化测试？等等。
   测试总结报告应该包括对测试用例的分析。例如，测试用例的设计经验总结，哪些用例设计得好，能非常有效地发现Bug，总结的这些东西无论是对本项目组的测试人员，还是对其他项目组的测试人员都会大有帮助。

前面一些可以从JIRA上获取数据，图表。具体总结分析，还是需要测试人员对此进行归纳。

li_feibo

理解LZ的情况，本人也比较怕领导让进行项目的bug分析，曾经做过一些类似的统计报告：
1、肯定少不了统计一遍bug的数量；bug解决方案的分类、bug类型的分类；
2、从bug内容中，分析bug出现的原因，并提出部分bug开发可避免的建议（因为分析的报告需发予开发，目的想提高项目的开发质量，减少bug数量）；
3、从bug的解决方案中，分析无效bug存在的原因，并提出QA可避免提该bug的改进方法（因为若无效bug太多，不仅浪费我们记录bug的时间，同时也浪费开发阅读bug的时间，总的来说对项目的成本无利）
3、总的来说，先分析开发的情况，再分析QA的情况，最后针对两者的问题，再提出一些建议性的问题。

joan-lin

谢谢楼上两位大虾的建议
BUG管理做的马虎的公司真心伤不起啊
我们公司的JIRA全部功能就只有BUG的记录了
只能简单分析，然后大篇建议了

luoyear

如果没有前期的整理，只是事后的统计分析，不妨可以这样做做：
1. 如果测试人员有足够的技术能力，可以扫一下整个Buglist，大致对Bug从以下几个维度分分类：
所属模块，修复者，发现者，引入阶段（需求、设计、实现、测试），最佳发现手段（需求评审、设计评审、代码评审、单元测试、系统测试），是否Reopen/Regression。
有了这些分类，就很好进行下一步分析了。你可能马上要嫌麻烦了，不麻烦怎么能在混沌初开的情况下得出有价值的震撼性的结论让领导决策呢？哥当年就是在混沌状态下对5000个Bug用了一周逐个标注，实在自己标注不了的，请教相关人员一一补上，然后做出了比较有价值的报告引发了一系列的后续改进行动。
2.如果没有，完全需要技术人员配合，可以进行适当的抽样缩小范围。比如抽10%的Bug进行上述分析。
3.针对遗漏到客户现场的Bug，尤其要进行深入分析。是属于测试Case可以覆盖到的但没有测试Case呢？还是测试环境和生产环境有差异呢？还是怎么个原因？分门别类。

有了这些初始化好了的数据，就可以逐个做分布和趋势分析了。比如：如果大部分都是需求的问题，那就进一步调查，到底是需求调研，还是需求确认（如静态原型演示确认），抑或是需求评审的问题。总之，一层层数据钻取加相关人员访谈，最后落实到可以采取行动的措施。

pulingwang

大伙胡意见灰不错。之前工作上也有类似困惑，现在看了大伙胡意见，真的不错。我也试试去

duxiaohan0326

bug统计分析往往在上个项目的测试分析报告中就会体现，会用数字和图形的形式去表现bug数据，以及相关bug的状态等等，我觉得这一步非常重要，首先对个人来讲有助于形成一个思维方式，让你清楚类似系统或者项目一般会出现bug的区域范围。另外一般在项目结束后，领导都会对上个项目进行总结分析，其实重点在于让各位强化自己的流程思路之类，让之后的项目能从完成了的项目中吸取营养。总结分析bug报告，尤其让你讲述这份报告的时候你就会发现原来有许多东西可能没有正式的思考过，正好是个自我强化的过程。
废话太多，用图标，走势图，以及各阶段bug的统计表来总结下就行。
最重要的原因，你老板怎么可能自己去看图标？？得出报告~~