51Testing软件测试论坛

标题: BUG率的计算和它的实际意义 [打印本页]

作者: xsnzhq 时间: 2008-9-23 11:28
标题: BUG率的计算和它的实际意义
bug率的计算应该说是有一个公式的，但是很多人的观点都有所不同，可能是和他们的目的不同。
观点一、bug率=bug数/代码行数
观点二、bug率=bug数/功能点数
还有人认为分子可以为状态、严重程度、发现人、解决人、所属模块等。
对于观点一和观点二比较感兴趣，但是很想知道哪一种方法会更加有效一点。
对于观点一，计算代码行数就要交由工具来完成的，但是不能保证开发人员的代码能力一样啊。
而对于观点二，则与开发人员的代码能力无关了，但是则与计算功能点的人有关，作为没有根基的人而言，能准确地计算出功能点也不是件容易的事。而且功能点法涉及的内容也比较多。
最主要的是，我很想知道计算bug率的好处是什么。
仅仅是为了制定出bug率为多少时时符合标准吗，然后经过一段时间后在不断的改进，使bug率得到改进吗？
是不是应该还有什么别的好处呢？
请大家一起来讨论！

作者: xsnzhq 时间: 2008-9-23 11:32
现在有很多项目是采用迭代的方式来进行的，每次可能添加的代码部分比较少，那如何来计算其bug率呢？
是用新增的bug数/新增的代码行数？还是总的bug数/ 总的代码行数？

作者: zhongmg108 时间: 2008-9-23 12:03
一、缺陷密度有很多用处，要具体情况具体分析：
1、主要用于评价工作产品的质量
如果缺陷密度较高（与质量目标或过程能力基线相比），说明工作产品的质量较差，需要大量的返工。做为项目经理要认真做好缺陷分析（缺陷的类型、分布、严重程度等），找出原因，以便做好下一阶段的缺陷预防工作。
2、还可以结合其它方面的信息，判断是否一些工作不充分。譬如，如果缺陷密度过低，有两个原因：可能工作产品质量确实高；也可能评审或测试不充分，更多的缺陷没有发现，而遗留。

二、关于缺陷密度两个计算方法
使用代码行的方法比较普遍和方便，可以用自动统计工具；但是，不同的编程语言差别较大。功能点的计算方法适用性较强，不同的语言之间也有可比性，但是参数较多，比较复杂，而且目前还没有比较方便的工具。对于大型项目来说，如果不用自动统计工具，进行代码统计几乎是不可能的。所以，大多数公司或项目还是运用代码行的计算方法。而且，功能点与不同语言的代码行数之间有一个对应，可以选用代码行统计工具计算出代码行，再根据比例换算成功能点。

三、关于迭代方式开发的缺陷统计
大部分公司是采用：BUG数/新增代码行，但是这个BUG有可能原有系统的缺陷，如果统计工具支持的话，可以不把原有系统缺陷数不统计在内。
采用何种统计策略，还要看该统计项目的，如果用于评价新开发工作的质量，那就不能把原有系统缺陷统计在内；如果不作为评价新的开发工作，那就都统计在一起（譬如有的只是跟踪版本质量）。
每一个统计项都应有它的目的，不应该机械地去做统计，还要看设计该统计项的目的是什么。

作者: xsnzhq 时间: 2008-9-23 13:21

原帖由 zhongmg108 于 2008-9-23 12:03 发表
一、缺陷密度有很多用处，要具体情况具体分析：
1、主要用于评价工作产品的质量
如果缺陷密度较高（与质量目标或过程能力基线相比），说明工作产品的质量较差，需要大量的返工。做为项目经理要认真做好缺陷分析 ...

您说的很有道理哦，但是想问您一下关于bug收缩率的问题，对于迭代开发，什么时候是计算收缩率的最佳时机呢？

作者: xsnzhq 时间: 2008-9-23 14:52
想问一下，bug数是本次剩余的bug数呢，还是总共的bug数？代码行数很难计算本次的代码行数吧，那是不是如果代码行数为总行数，那么bug数就应该为总的bug数呢？即所有bug的加和呢？请大家指教。

作者: zhongmg108 时间: 2008-9-23 14:58

原帖由 xsnzhq 于 2008-9-23 13:21 发表

您说的很有道理哦，但是想问您一下关于bug收缩率的问题，对于迭代开发，什么时候是计算收缩率的最佳时机呢？

老实说,关于Bug收缩率我第一次听说这个概念,不知道其具体算法是什么,不过从字面理解,应该与缺陷收敛速度相关的东西。我觉得还是从对这个度量项的含义及目的入手，你是想通过这个度量项来得到什么信息。譬如，可以用收缩率来评估上一阶段工作（如测试）的效率或质量，也可以作为某一阶段测试工作结束的出口准则。
我意思是说，如果需要评价这个工作，而这时的数据又能支持这个度量项的计算，这个时候就是计算和分析的时机。但度量数据（直接度量项）的相关收集工作是一个持续过程，不能等到需要计算相关度量项（派生度量项或间接度量项）时再收集。
在实际工作中，用Relay曲线进行遗留缺陷的预测，这种用法较多（只要有三个阶段的缺陷数据，就可进行预测，但是要注意Relay曲线的使用条件，这方面的资料应该比较丰富，你可以在网上查一下）。

作者: zhongmg108 时间: 2008-9-23 15:08

原帖由 xsnzhq 于 2008-9-23 14:52 发表
想问一下，bug数是本次剩余的bug数呢，还是总共的bug数？代码行数很难计算本次的代码行数吧，那是不是如果代码行数为总行数，那么bug数就应该为总的bug数呢？即所有bug的加和呢？请大家指教。

应该是本轮测试或评审发现的Bug数，因为缺陷密度是评价当前这个时间点产品的质量。
用代码行统计工具很容易统计新增、修改、删除等的代码行数。
一般不会是把所有轮次或阶段的Bug加在一起计算缺陷密度（可能在计算评审或测试效率时，会这样用）。
还是要从度量项的含义和目的出发，不然计算出来的结果没有什么意义，或者得出错误的结论和判断。

作者: xsnzhq 时间: 2008-9-23 15:15
我现在对于bug率计算中的bug数如何取值真的很迷惑，应该取什么数呢？总的bug数吗？如果是总的bug数那么对于后期的仅仅改错的阶段而言，可能代码的增加会很少，但是这时bug数会不断增加，这样一来，bug率岂不是在不断的升高？但是按常理而言是应该减少的呀，应该越到后期bug率越小才对，是不？
我觉得是不是bug数取剩余的bug总数（上几个版本剩余未修改的bug和本版本的新bug）呢？而代码行数仍然是总的代码行数。这样理解是不是有问题呢？

作者: xsnzhq 时间: 2008-9-23 15:22

原帖由 zhongmg108 于 2008-9-23 15:08 发表

应该是本轮测试或评审发现的Bug数，因为缺陷密度是评价当前这个时间点产品的质量。
用代码行统计工具很容易统计新增、修改、删除等的代码行数。
一般不会是把所有轮次或阶段的Bug加在一起计算缺陷密度（可能在计 ...

您的回答我能理解，可是我好像不会用代码统计工具统计新增、修改、删除等的代码行数。只会计算总的代码行数。
您说bug数仅包含本版本新提交的bug数是吗？对于上几个版本中为解决的bug也不管了吗？还是一并计算呢？

作者: xsnzhq 时间: 2008-9-23 15:29

原帖由 zhongmg108 于 2008-9-23 14:58 发表

老实说,关于Bug收缩率我第一次听说这个概念,不知道其具体算法是什么,不过从字面理解,应该与缺陷收敛速度相关的东西。我觉得还是从对这个度量项的含义及目的入手，你是想通过这个度量项来得到什么信息。譬如，可 ...

对于bug收缩率，我也不是很清楚，但是好像是分析用的，如果到了后期bug还是以一种分散的形式出现的话，那就证明出现了问题，就要找原因了，好像就是干这个用的，具体的还要听听大家的理解。

作者: zhongmg108 时间: 2008-9-23 15:53

原帖由 xsnzhq 于 2008-9-23 15:22 发表

您的回答我能理解，可是我好像不会用代码统计工具统计新增、修改、删除等的代码行数。只会计算总的代码行数。
您说bug数仅包含本版本新提交的bug数是吗？对于上几个版本中为解决的bug也不管了吗？还是一并计算呢？ ...

1、你可以到网上查一下,代码统计工具应该很多的,其原理一般是通过新旧两个版本对比,很容易得到上述数据.
2、那就看你用这个度量项来说明什么问题：如果是评价新增代码的质量，那不应该包括以前未解决的Bug（不然，开发人员就太有意见了）；如果是评价当前版本整个系统的质量，那就应该一并计算。

作者: xsnzhq 时间: 2008-9-23 16:25
[quote]原帖由 zhongmg108 于 2008-9-23 15:53 发表

1、你可以到网上查一下,代码统计工具应该很多的,其原理一般是通过新旧两个版本对比,很容易得到上述数据.
2、那就看你用这个度量项来说明什么问题：如果是评价新增代码的质量，那不应该包括以前未解决的Bug（不然， ...
您的意思是说如果是评价新增的代码质量那么就是---新增的bug数/新增+修改+删除代码行数
如果是当前版本的整个系统的代码质量-----总的bug数/总代码行数
是这样吗？

作者: xsnzhq 时间: 2008-9-23 16:26
[quote]原帖由 zhongmg108 于 2008-9-23 15:53 发表

作者: xsnzhq 时间: 2008-9-23 16:29
还有，就是如果是想得到当前版本整个系统的质量那个bug率就应该为---本版本的新bug+以前版本未解决的bug/总的代码行数，对吗？
还是怎么计算呢？

作者: xsnzhq 时间: 2008-9-23 16:59
大家有可以统计到新增、删除、修改的代码行数的工具吗？
我找了一下午还是没有找到，linecount和scounter好像都只能计算出总的代码行数。
要不就是我不会使用。有知道的朋友希望告知。
如果大家又可以统计到新增、删除、修改的代码行数的工具希望可以发给我一份
邮箱是xsnzhq@sina.com.cn
先谢谢了！

作者: chengxq 时间: 2008-9-23 17:12
标题: 回复 1# 的帖子
首先关于bug率统计的方法，个人感觉无论是根据功能点还是根据代码行数，我感觉各有各的用处，而且我也很讨厌“学院派”那种的无味的争论，张三说这个好，李四说那个好，这个个人感觉是没有意义的，因为每种统计方法都有各自的优势，说一句唯心主义的话，就是“存在即合理”其实我们这些品质管理人员最重要的是选择出适合自己项目，适合自己公司的统计方法，总之适合自己才是最好的！
其次，回答你提出的统计bug率的好处，3楼的说的很明白了，他说的比我想的还仔细透彻，不过在这里我想补充一下下自己的观点，就是这些所谓的高，所谓的低，是根据公司以前项目的历史数据来的，参考历史数据，制定出合适的bug率的上下限，来作为评判自己工作产品的，并要求作分析，当然你可能认为历史数据不好用，那么也可以根据本项目的前阶段的bug率，来制定下一阶段的bug率，这里再说明一点，无论是以前，还是现在，还是将来，统计的标准必须一致！否则将失去意义！

作者: chengxq 时间: 2008-9-23 17:18

原帖由 xsnzhq 于 2008-9-23 11:32 发表
现在有很多项目是采用迭代的方式来进行的，每次可能添加的代码部分比较少，那如何来计算其bug率呢？
是用新增的bug数/新增的代码行数？还是总的bug数/ 总的代码行数？

这个其实主要看公司制定的标准，公司要求是总的，还是新添加的，那我们统计的时候就按照公司的标准去执行
如果公司没有这方面的标准，那争取建立这方面的标准
个人观点，统计总的代码行数，因为在在迭代1中的bug，可能在迭代2中被发现，那这个bug如何计算呢？所以单纯的
统计新的代码行数是没有意义的，因为上一阶段遗留bug将没有对应。
不过我在网上看到有些公司将新的代码行数，总的代码行数，bug建立之间的关系，理论性很强，做起来比较难，特别
是刚建质量标准的公司，不过你需要可以和你沟通一下

作者: chengxq 时间: 2008-9-23 17:28

原帖由 xsnzhq 于 2008-9-23 14:52 发表
想问一下，bug数是本次剩余的bug数呢，还是总共的bug数？代码行数很难计算本次的代码行数吧，那是不是如果代码行数为总行数，那么bug数就应该为总的bug数呢？即所有bug的加和呢？请大家指教。

这个问题我没有读明白，但是我想，首先你统计bug的目的是什么，你打算干什么，如果你目的明确了，那问题就基本上解决了，你首先想清楚，你统计这个值是什么用的，我想你应该知道怎么去做了

作者: xsnzhq 时间: 2008-9-23 17:32

原帖由 chengxq 于 2008-9-23 17:18 发表

这个其实主要看公司制定的标准，公司要求是总的，还是新添加的，那我们统计的时候就按照公司的标准去执行
如果公司没有这方面的标准，那争取建立这方面的标准
个人观点，统计总的代码行数，因为在在迭代1中的bug ...

那您的意见是bug率=总的bug数/总的代码行数是吗？
还是bug 率=新增加的bug数+ 未解决的bug数/总的代码行数呢？

作者: chengxq 时间: 2008-9-23 17:33
关于bug收敛率，主要是从测试过程来考虑的，如果我进行一轮测试发现了bug率，然后修改，在进行测试，发现的bug率来进行几次的统计，不过表现形式，到目前为止我看到2种表现方式，一种是只统计每次发现的bug，图表的表现形式是涿渐降低的，最后收敛于0，一种就是每次统计全部的bug，那是慢慢升高的，收敛于一个值，不过这只是形式的问题，就像我刚才说的，你的目的是什么。然后就好办多了

作者: chengxq 时间: 2008-9-23 17:35

那您的意见是bug率=总的bug数/总的代码行数是吗？
还是bug 率=新增加的bug数+ 未解决的bug数/总的代码行数呢？

你好，请问总的bug 数不等于新增加的bug数加未解决的bug数吗？不好意思，你能说清楚点吗？

作者: xsnzhq 时间: 2008-9-23 17:41

原帖由 chengxq 于 2008-9-23 17:33 发表
关于bug收敛率，主要是从测试过程来考虑的，如果我进行一轮测试发现了bug率，然后修改，在进行测试，发现的bug率来进行几次的统计，不过表现形式，到目前为止我看到2种表现方式，一种是只统计每次发现的bug，图表的表 ...

您说的这个很容易理解，其实两种方式只是表现形式不相同。但是我想问一下，对于迭代开发模式下的项目什么时候是统计收敛率的好时机呢？
是要等到全部功能都实现了吗？还是以开始做项目的时候就可以了呢？

作者: xsnzhq 时间: 2008-9-23 17:44

原帖由 chengxq 于 2008-9-23 17:35 发表

你好，请问总的bug 数不等于新增加的bug数加未解决的bug数吗？不好意思，你能说清楚点吗？

恩，是这样的，我所说的总的bug是指截止到目前版本的所有bug书，其中包含新增的+未解决+已解决。
就是由始至终的一个bug总数。
呵呵

作者: chengxq 时间: 2008-9-23 17:52

原帖由 xsnzhq 于 2008-9-23 17:41 发表

您说的这个很容易理解，其实两种方式只是表现形式不相同。但是我想问一下，对于迭代开发模式下的项目什么时候是统计收敛率的好时机呢？
是要等到全部功能都实现了吗？还是以开始做项目的时候就可以了呢？

其实这个bug收敛率在小项目中是很难运用的，它一般运用在评测阶段或项目生命周期的软件质量
主要是对应于对每次测试时的bug数，如单体测试阶段分为测试1.测试2.测试3.那我统计bug数，看是否收敛
如果是那证明我质量越来越好，如果不是那就要分析。

作者: xsnzhq 时间: 2008-9-24 10:01
经过昨天一天大家的讨论，我也渐渐明白了bug率的计算。首先要明确要做bug率的目的，然后根据目的去选择方法。如果想得到本版本的质量那么bug率=（新提交的bug数+上几个版本未解决的bug数）/总的代码行数。我觉得大多数公司可能更加关注的就是在这个数据吧。如果您关注的是本阶段的质量bug率=新提交的bug数/新编写的代码行数。其中包括新增、删除、修改的代码行数。（尽管我还不清楚这个代码行数用什么统计工具可以计算）。
至于bug收敛率也是一样，像上面的朋友说的，可以使本版本的bug数，也可以是总的bug数。然后通过出图就会很直观。但是还是统计本版本的bug数会比较直观，因为正常来说它会逐渐趋近于0。
以上是我向大家学到的，还有不对之处，请指出！

作者: junlingliu 时间: 2008-9-27 13:26
bug率主要评估什么用？有什么实际意义？

作者: xsnzhq 时间: 2008-9-28 11:10

原帖由 junlingliu 于 2008-9-27 13:26 发表
bug率主要评估什么用？有什么实际意义？

bug率主要是用来评估系统或版本是否符合要求，其bug率是否在指定的范围内。
首先自然要进行一段时间的数据累计，然后掌握规律，制定出合适的标准，bug率为多少(应该为一个范围)的时候是在标准内。不在标准内，不论是低于还是高于都要找原因，查找问题所在，并改进。

作者: shunfyu 时间: 2008-10-15 17:32

在这里顶一下。。慢慢看。。我们Tester正在做这个

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)