关于缺陷密度和代码缺陷收敛速度的相关问题

luming

我这里看到一份CMMI3的文档，关于度量方面的。
里面有缺陷密度的概念，缺陷密度=缺陷数/代码行数。这个没有什么问题。

但是有一些附加的概念，总觉得无法确认，谁有相关的经验，解答我的疑惑。

1.文档原文：每轮测试缺陷密度=各轮测试BUG数/每轮测试时的实际代码行规模。（个/代码行）。

我的疑惑：去网上找找了，关于缺陷密度说的并不太多，但有一种看法是，每轮缺陷密度是指：当轮所发现的缺陷/变更的代码行数。
但是度量认为，这里的实际代码行数是总的规模行数。这里用哪个概念比较好。或者每轮测试缺陷密度有其他更好的说法。
文档原文并没有很明确的说明。

2.文档原文：在测试中及项目结束后总的缺陷密度=BUG总数/实际代码行规模。（个/代码行）

我的疑惑：这里的bug总数，是仅仅统计系统测试的缺陷数，还是包含整个项目，从需求开始，发现的文档缺陷、单元测试缺陷等等的所有bug？
度量倾向于这里仅仅指系统测试的bug。

3.文档原文：代码缺陷收敛速度=（第一轮测试缺陷数-统计日期最新一轮测试缺陷数）/（最新一轮测试完成日期-第一轮测试完成日期）

我的疑惑：这个概念真的比较诡异，因为指明了第一轮测试的统计数据和其他轮次的差。我一直在想是否这里写错了。
这个指标的概念我也不是很理解，感觉像是考量开发人员修复的速度。

文档中相应的指标考察说明如下，大家可以参考一下。
每轮测试缺陷密度分析：每轮测试缺陷密度>30%，预警,项目缺陷过多,可能导致项目进度问题。
代码缺陷收敛速度分析：代码缺陷收敛速度<50%，修改的速度过慢,可能影响项目。

ppent

对于CMMI我并不十分熟悉，这里只从测试人员的角色说说我对以上概念的理解。理解有错的请各位指正。
先说一下缺陷密度，这是针对某种特定角度进行持续的度量分析，观察其变化情况，是一个动态值。这里我自己给它起一个名字--缺陷密度变化曲线。

1、每轮测试缺陷密度
既然缺陷密度是一个持续变化的动态值，那么每轮测试缺陷密度则是缺陷密度变化曲线上的一个具体的坐标值，代表某次的缺陷情况。因此在概念上应该和整体上保持一致，否则就没有比较意义了。因此，我倾向于理解为测试当时的实际代码行数。

2、总缺陷密度
总缺陷密度与缺陷密度变化曲线是相关的。我理解为总缺陷密度是缺陷密度变化曲线在时间上的面积。
至于缺陷包括了哪些测试类型，这里并没有绝对的说法，还是与你的度量范围有关。
比如在A项目缺陷密度变化曲线是只度量软件测试生命周期的系统测试，在B项目却包括各种测试类型的缺陷。

3、缺陷收敛速度
应该理解为类似斜率的东东吧。这也是一个动态值。

yangxiaowen0622

缺陷收敛度这个概念我有点清楚，但是不保证我说的是正确的。

我认为缺陷收敛度是指缺陷数的一个增长趋势。

在测试过程中，缺陷数达到一个顶峰值后，应该趋于下降状态，不再继续增长。

如若说缺陷说一直处于增长状态的话，按80－20的理论来说的话，其未发现的缺陷数就更多。品质就更差。

只有不增长了，才有那种将代码越改越好的趋势。

zte_boy

可以在excel中建立BUG趋势图来关注这些信息

chengxq

1.文档原文：每轮测试缺陷密度=各轮测试BUG数/每轮测试时的实际代码行规模。（个/代码行）。

我的疑惑：去网上找找了，关于缺陷密度说的并不太多，但有一种看法是，每轮缺陷密度是指：当轮所发现的缺陷/变更的代码行数。
但是度量认为，这里的实际代码行数是总的规模行数。这里用哪个概念比较好。或者每轮测试缺陷密度有其他更好的说法。
文档原文并没有很明确的说明。
我认为，应该是 各轮的bug 数/实际的代码行数
1.通过每轮的测试的缺陷密度，如果在几轮的测试中发现的bug，如果统计出来的缺陷密度是收敛的话，那么就能说明，我们的品质越来越好，项目是正常的，但是如果是修改的代码行数来看，那是想说明，修改代码时新注入的bug ，从这个角度考虑，虽然有一定的统计意义，但是和常规的品质要求有出入。

chengxq

2.文档原文：在测试中及项目结束后总的缺陷密度=BUG总数/实际代码行规模。（个/代码行）

我的疑惑：这里的bug总数，是仅仅统计系统测试的缺陷数，还是包含整个项目，从需求开始，发现的文档缺陷、单元测试缺陷等等的所有bug？
度量倾向于这里仅仅指系统测试的bug。
这个一般情况是要分阶段统计的，就是说，在什么阶段，出现多少bug ，这样一，可以作为资产为下一项目进行考虑，二，能够说明各个阶段的品质要求。这个和生产性的定义是一致的，即在什么阶段，生性性时多少，如果要统计整个项目周期，整个生产性，那时根本无法统计的。

chengxq

3.文档原文：代码缺陷收敛速度=（第一轮测试缺陷数-统计日期最新一轮测试缺陷数）/（最新一轮测试完成日期-第一轮测试完成日期）

我的疑惑：这个概念真的比较诡异，因为指明了第一轮测试的统计数据和其他轮次的差。我一直在想是否这里写错了。
这个指标的概念我也不是很理解，感觉像是考量开发人员修复的速度。
解答为：代码缺陷收敛速度分析：代码缺陷收敛速度<50%，修改的速度过慢,可能影响项目。
不过好像用的不多，我好像在什么书上看到过。