昨天手工整理了bug的相关维度，其实都谈不上什么分析。
bug分布，即每个大模块在总bug数中的占比，能分析出哪些模块bug最多，哪个模块bug最少，但是模块自身也有大小之分，所以从数据上看bug多的模块，子模块也最多，功能点更多，bug多也是理所当然，当然某些模块因为业务复杂度高，且没有子模块，但是还是看出它存在的问题比较多。
严重程度分布，即从严重程度的角度来看bug的数量分布，我们的bug严重程度分为：致命、严重、一般、闪退。致命一般为APP闪退这种情况，但是受限于测试机数量型号的问题，并不能优先解决；严重，表示该bug影响用户正常使用，需要优先解决；一般，则为项目组自行安排修复时间进行修复；优化，即为建议，虽然说没有强制要求修复，但是希望项目组在后期功能迭代中考虑这些优化点。数量上来看，致命最少，严重最多，一般和优化分别次之。
最后，把每个模块单独按严重程度做了个饼状图，从模块内部去观察bug的分布情况，提醒负责的小组在平时开发中有意识的规避问题，不让问题重复出现。
以上，其实只是比较粗浅的数据统计，并谈不上什么分析。要说bug分析能分析什么，最有价值的应该还有风险的预估。因为bug已经发生了，解决以后就不存在了，但是对未来是否有影响，是否会存在风险影响后续产品，是否需要产品人员重新整理功能需求，并纳入下一个迭代周期，这些才是bug分析的重点。
如果有看官在这方面比较有想法，或者有比较成熟的实施方案，欢迎在留言里和我交流，谢谢。
END.
