缺陷如何度量?缺陷度量的三大标准

851 阅读10分钟
原文链接: zhuanlan.zhihu.com

软件度量包含三个维度的内容:产品设计指标度量、过程度量和项目度量。产品设计指标度量是指从产品设计角度的一些特性指标角度度量,如规模大小、复杂程度、设计特点、性能和质量水平。过程度量主要是用于提高开发和维护的效率,如开发过程中缺陷去除的效果、测试过程中的缺陷模型和修复过程的响应时间。项目度量是从项目特点和执行的角度进行度量,如开发商数量、生命周期、成本、进度等。

一、缺陷密度度量

缺陷密度也就是平常所说的缺陷率,缺陷率看似很简单,但是如果我们不能讨论清楚缺陷率中分子与分母的值,那么就不可能很好地确定缺陷率的概念。一般缺陷率的概念是指一个特定的时间帧中缺陷出现的机会。

分母通常指的是软件的大小,通常使用千万代码(KLOC)或功能数来形容。时间帧是指产品生命期中的一系列操作,生命期少则一年,多则几年,通常95%的缺陷会在产品发布的四年之内发现,而绝大多数数据缺陷通常是在两年内被发现。

千行代码这个度量其实很简单,主要的问题是如何精确地计数实际的代码行数,在早期的汇编语言中,一行物理代码就相当于我们要计数的一行代码,但在高级语言中可能就不会这样,一行物理行并不一定是一行代码,即使同一个代码片段使用不同的计数工具计数,也可能导致结果存在差异,通常统计代码行有以下几种方法:

1)只统计可执行的行代码;

2)只统计带数据定义的可执行的行代码;

3)统计可执行行代码、数据定义和注释;

4)统计可执行行代码、数据定义、注释和控制语句;

5)统计在输入屏幕中做为物理行的代码;

6)统计做为逻辑分隔符的终止行代码;

上面是常见的关于代码行的统计方法,不同的公司可能会有着不同的统计方法,但不管使用什么方法进行统计,统计的方法只能使用一种。不同的项目使用不同的统计方法,这样数据之间没有参考价值。

通常说的代码是程序文件中的一行代码,但是注释行或空行除外,代码通常包括程序头、函数声明、可执行的语句和不可执行的语句。

在统计过程中,统计物理行代码和统计指令语句是存在差异的,有时候甚至会差得很多,如Basic、Pascal 和C 语言,在一行物理行上就可能出现多个指令。另一方面,一条指令语句和数据声明也可能跨越几条物理行代码,特别是在编程时,如果为了维护方便,写代码时就很容易出现这种问题。使用逻辑行和物理行进行统计各有优缺点,但是可能逻辑行来统计代码行会更合理一些。

例如:某个项目,通常代码行总数由逻辑行代码、可执行代码和相关数据定义的代码组成,但不包含注释代码。代码行的总数应该由产品所有的代码和新版本所新增加的或修改的代码组成。源有的代码语句称之为SSI,新增的和修改的称之为CSI,SSI 与CSI 公式如下:

SSI(当前版本)= SSI(以前的版本)+ CSI(当前版本新增或修改的代码行)

− 删除的代码(一般这个值很小)

− 修改的代码(不能在SSI 和CSI 中计算两次)

产品发布后需要对缺陷进行跟踪,在跟踪缺陷过程中可以对缺陷进行分类,通常分为用户发现和内部缺陷两类,每千行SSI 和每千行CSI 主要度量的内容如下:

(1)每千行缺陷率主要用来度量产品代码质量的。

(2)从不同类型的角度统计千行缺陷率,这主要用来度量不同类型所发现的缺陷总数。

(3)新修改或增加的每千行代码所发现的缺陷数。

(4)由客户所发现的,新新修或增加的每千行代码缺陷数。

产品发布后需要对缺陷进行跟踪,在跟踪缺陷过程中可以对缺陷进行分类,通常分为用户发现和内部缺陷两类,每千行SSI 和每千行CSI 主要度量的内容如下:

第(1)点主要度量总的已发布代码的质量,第(3)点主要度量新修改或增加的代码的质量,如果当前测试的版本就是发布的第一个版本,那么第(1)点和第(3)点表达的意思是一致的。第(1)点和第(3)点主要是针对过程进行度量的。第(2)点和第(4)点主要是从客户的角度进行分类度量。对千行CSI 率和千行SSI 率进行估计,开发工程师可以通过修复缺将对用户的影响降低到最小化。

二、客户角度

缺陷率是度量软件质量的一个基础单元,但从开发团队的角度来说,通过对缺陷率的分析可以有效地提高产品的质量。从实践的角度来说,一个好的软件质量需要从用户的角度来分析。如果以缺陷率来做产品发布时产品质量的度量,那么从客户角度,缺陷率并一定直接决定缺陷的总数。所以一个好的缺陷率应该是会让发布产品的总缺陷数下降。如果一个新发布的版本比较以前版本的代码量更大,这就说明新添加的修改的代码的缺陷率要下降,这样才能更好的降低缺陷的总数。

例如:

第一个版本发布时的数据如下:

KSSI=60 KLOC

由于第一个版本,KCSI 的值正好等于KSSI 的值,所以KCSI=KKSI=60 KLOC

统计出来的缺陷率为:缺陷/千行代码=2.0

总的缺陷数为120 个。

第二个版本发布时的数据如下:

假设新增加代码量为20 千行,即KCSI=20KLOC

KSSI=60(上一版本总代码数)+20(新添加或新修改的代码数)

-4(假设新添加或新修改的代码数中,假设有20%是修改原来的代码)

= 76

统计出来的缺陷率为:缺陷/千行代码=1.8(假设相对于第一个版本提高了10%)

第二个版本总增加的缺陷数为1.8×20=36。

第三个版本发布时的数据如下:

假设新增加代码量为30 千行,即KCSI=30KLOC

KSSI=76(上一版本总代码数)+30(新添加或新修改的代码数)

-6(假设新添加或新修改的代码数中,假设有20%是修改原来的代码)

= 100

第三个版本总增加的缺陷数为38

缺陷/千行代码=39/30=1/3

第一个版本发现了100 个BUG,第二个版本发现了36 个BUG,用户直观感受是缺陷下降了64%((100-36)/100),当然这主要是因为第二版本新增或修改的代码量下降了。第三个版本的缺陷又大于第二个版本的缺陷数,这是因为第三个版本新增或修改的代码量比第二个版本多出很多,但缺陷率就下降了很多,第二个版本是1.8,第三个版本是1.3,缺陷率大概为第二版本的三分之一。当然第二个版本和第三个版本缺陷率差异太大,这样可能测试中很难达到这样一个值,这种情况下必须对计划、代码进行改进。

三、功能点

上面介绍的是通过代码行的方式来度量缺陷,除了这种方式外,另外一种度量方式是通过功能点的方式来度量,这两种方式都是通过缺陷密度来表达系统出错的可能性。在近些年通过功能点来度量的方式越来越被人接受,可以从两个方面来度量:开发工程师的工作效率(如每人每年开发了多少功能点)和系统质量(如平均每个功能点所发现的缺陷数)。

一个功能是指一个可执行语句的集合,这些语句是用来执行某项工作任务的,其包括参数、本地变量和声明语句。使用功能点度量开发工程师工作效率时,只关注功能点的多少,而不需要关注代码行数。使用功能点度量缺陷,即关注每个功能点的缺陷分布情况,如果单位功能点缺陷率比较低,那么通常说明产品的质量比较高,即使这个时候KLOC 缺陷率比较高,但是如果一个功能点其实现的代码数很少,这样使用功能点去度量就可能会变得很困难。

功能度量最好是在IBM 公司开始使用,但由于当时的技术并不能很好地对功能进行准确的度量,所以使用功能进行度量时出现一个失误的地方。使用功能点解决了生产率和代码行数的问题,因为在统计代码行时,有很多不确定的因素,特别是不同的语言其统计的结果可能差异比较大。在我们定义一个应用时,应该从五个方面来加权评估:

(1)如果是外部输入(如交易类型功能),权重为4。

(2)如果是外部输出(如报告类型),权重为5。

(3)内部逻辑文件,权重为10。

(4)外部接口文件,权重为7。

(5)外部查询数,权重为4。

上面是平均加权的方式,还一种是低复杂度和高复杂度的加权,具体如下:

(1)如果是外部输入(如交易类型功能),低复杂度权重为3,高复杂度权重为6。

(2)如果是外部输出(如报告类型),低复杂度权重为4,高复杂度权重为7。

(3)内部逻辑文件,低复杂度权重为7,高复杂度权重为15。

(4)外部接口文件,低复杂度权重为5,高复杂度权重为10。

(5)外部查询数,低复杂度权重为3,高复杂度权重为6。

组件复杂度的确定也是很难的,在确定这些组件复杂度时,需要有一些标准的准则。例如,如果数据元素的类型超过20 种,涉及的文件类型超过2 个,这种情况复杂度为高;如果数据元素的类型少于5 种,涉及的文件类型超过2 个或3 个,这种情况复杂度为低。

功能点总数的公式如下:

1)数据通信;

2)函数分布;

3)性能;

4)使用配置;

5)交易率;

6)联机数据输入;

7)终端用户使用效率;

8)在线更新;

9)复杂的过程;

10)可重用性;

11)安装的易用性;

12)操作的易用性;

13)多站点访问;

14)改变的方便性。

这些特性的权值范围是0~5,通过下面的公式可以对特性的因子进行调整,具体的公式如下: