关于BUG率的计算和它的实际意义的思考

用处有很多，需要具体情况具体分析，不过主要作用一般是来评价工作产品的质量。如果bug率较高，说明系统质量较差，需要大量的返工。项目经理就需要做好缺陷分析（缺陷的类型、分布、严重程度等），找出原因，以便做好下一阶段的缺陷预防工作。除此之外，还可以结合其它方面的信息，判断是否一些工作不充分。譬如，如果缺陷密度过低，有两个原因：可能工作产品质量确实高；也可能评审或测试不充分，更多的缺陷没有发现。在某些公司，bug率也作为项目度量考核的一项指标。

流行的公式主要以下两个：

观点一、bug率=bug数/代码行数

观点二、bug率=bug数/功能点数

网上对于这两个公式的争议比较多，这个问题上，个人觉得没必要争哪个才是正道。说句唯心主义的话，存在即是合理，每个公式都有他生存的环境和产生的根源，对于我们需要用到它的时候，只需要根据公司需要进行择优选择就好了，不是吗？

使用代码行进行计算，优点是可以通过自动统计工具计算（特别是对于大型项目，肯定会计算代码行数），比较方便，所以该方法比较普遍，是大多数公司或项目运用的计算方法。但它的缺点是受开发人能力影响大（毕竟不同开发人员的编码能力不一样），且不用编程语言差别较大。

使用功能点进行计算，优点是计算方法适用性强，不同语言之间也有可比性，但缺点是参数较多，比较复杂，而且目前还没有比较方便的工具。其次，计算功能点虽然与开发人员的代码能力无关，但是与计算功能点的人有关，对于没有根基的人而言，能准确的计算出功能点也不是一件容易的事。而且功能点涉及的内容也比较多。

网上看过有人说到“功能点与不同语言的代码行数之间有一个对应，可以在统计出代码行数后根据比例换算成功能点”， 具体对应关系是什么我没有查到，希望有知道的童鞋告知一下。

在看到上面的公式后，也许有人疑惑：

1. 能很方便的统计出新版本变化的代码行数吗？

2. 分子中的bug数是本次剩余的bug数呢，还是总共的bug数？

3. 如果代码行数为总行数，那么bug数就应该为总的bug数呢？即所有bug的和呢？而且如果是总的bug数那么对于后期的仅仅改错的阶段而言，可能代码的增加会很少，但是这时bug数会不断增加，这样一来，bug率岂不是在不断的升高？但是按常理而言是应该减少的呀，应该越到后期bug率越小才对，是不？

4. 或者bug数取剩余的bug总数（上几个版本剩余未修改的bug和本版本的新bug）呢？而代码行数仍然是总的代码行数。这样是不是有问题呢？

   解惑：

1、代码统计工很多都能做到新旧两个版本对比,很容易得到版本变化的代码行数.

2-3、那就看你用这个度量项来说明什么问题：如果是评价新增代码的质量，那不应该包括以前未解决的Bug，可以用“新增的bug数/新增+修改+删除代码行数”，如果是当前版本的整个系统的代码质量-----总的bug数/总代码行数。

4、这个就是相当于统计bug收敛率了。

是这样吗？

现在有很多项目是采用迭代的方式来进行的，每次可能添加的代码部分比较少，那如何来计算其bug率呢？是用新增的bug数/新增的代码行数？还是总的bug数/ 总的代码行数？

其实，采用何种统计策略，还要看该统计项目的，如果用于评价新开发工作的质量，那就不能把原有系统缺陷统计在内；如果不作为评价新的开发工作，那就都统计在一起（譬如有的只是跟踪版本质量）。

每一个统计项都应有它的目的，不应该机械地去做统计，还要看设计该统计项的目的是什么。

​