这几天找了一些资料，查看了一些关于BUG率的资料，把自己的的理解记录下来，先放着，看在以后的使用中，是否是这样。
1、什么是BUG率？
2、BUG率的计算
目前来说在公司的动作过程中，BUG率现有两种计算方式：
A：BUG率=BUG数/功能点
B：BUG率=BUG数/代码行数（每千行代码）
当然这两种计算方式，只是针对于一个软件的某一个阶段，比如XX集团招聘系统在需求到开发结束这么一个过程中，发现BUG：需求阶段发现50个；设计阶段发现80个；编码阶段发现100个；UT阶段发现30个；IT阶段发现20个；ST阶段发现20个，分为这么几个阶段（也有可能为其它的阶段，但是前提必须是开发过程中的）。
还有人认为BUG率还要分状态、严重程度、发现人、解决人、所属模块等来分，但是这种的会是很复杂。
对于A、B两个BUG率的计算公式哪一种最方便，或者说是最有效一点。
对于A计算代码行数，应该由工具来统计，谁能保证开发人员的开发代码能力是一致的
对于B则与开发人员的代码能力无关了，但是则与计算功能点的人有关，作为没有根基的人而言，能准确地计算出功能点也不是件容易的事，而且功能点法涉及的内容也比较多，非常的不容易。难度有些大！
3、BUG率的用处
在资料中看到有两种：
A：主要用于评价工作产品的质量
如果缺陷密度较高（与质量目标或过程能力基线相比），说明工作产品的质量较差，需要大量的返工。做为项目经理要认真做好缺陷分析（缺陷的类型、分布、严重程度等），找出原因，以便做好下一阶段的缺陷预防工作。
B：还可以结合其它方面的信息，判断是否一些工作不充分。譬如，如果缺陷密度过低，有两个原因：可能工作产品质量确实高；也可能评审或测试不充分，更多的缺陷没有发现，而遗留。
如果缺陷密度较高（与质量目标或过程能力基线相比），说明工作产品的质量较差，需要大量的返工。做为项目经理要认真做好缺陷分析（缺陷的类型、分布、严重程度等），找出原因，以便做好下一阶段的缺陷预防工作。
B：还可以结合其它方面的信息，判断是否一些工作不充分。譬如，如果缺陷密度过低，有两个原因：可能工作产品质量确实高；也可能评审或测试不充分，更多的缺陷没有发现，而遗留。
4、BUG率的好处
5、BUG率计算的时间段与结束段
应该是本轮测试或评审发现的Bug数，因为缺陷密度是评价当前这个时间点产品的质量。在某段时间有某段时间的BUG率计划，这样，从第一个阶段到最后开发完成、上线，这应该是一个收敛曲线，这个收敛曲线的最终点也就是结束段应该是0，即软件已经没有BUG可寻了。
其实BUG率的计算，要看你在开发的过程了，比如：需求阶段、设计阶段、编码阶段、UT阶段、IT阶段、ST阶段；各个阶段的BUG率为多少，在此过程中以曲线形式表示，查看软件在开发过程中的质量。
每一个阶段的BUG率应该统计的是单独的一个阶段，比如：需求阶段发现BUG为A，行数为B，那就是A/B
第二个阶段是抛开第一个阶段的BUG数与代码行数的
以此类推！
