全国咨询热线：136-9172-9932
缺陷密度也就是平常所说的缺陷率，缺陷率看似很简单，但是如果我们不能讨论清楚缺陷率中 分子与分母的值，那么就不可能很好地确定缺陷率的概念。一般缺陷率的概念是指一个特定的时间 帧中缺陷出现的机会。 分母通常指的是软件的大小，通常使用千万代码（KLOC）或功能数来形容。时间帧是指产品 生命期中的一系列操作，生命期少则一年，多则几年，通常 95%的缺陷会在产品发布的四年之内 发现，而绝大多数数据缺陷通常是在两年内被发现。 千行代码这个度量其实很简单，主要的问题是如何精确地计数实际的代码行数，在早期的汇编 语言中，一行物理代码就相当于我们要计数的一行代码，但在高级语言中可能就不会这样，一行物 理行并不一定是一行代码，即使同一个代码片段使用不同的计数工具计数，也可能导致结果存在差 异，通常统计代码行有以下几种方法：
只统计可执行的行代码。 只统计带数据定义的可执行的行代码。 统计可执行行代码、数据定义和注释。 统计可执行行代码、数据定义、注释和控制语句。 统计在输入屏幕中做为物理行的代码。 统计做为逻辑分隔符的终止行代码。 上面是常见的关于代码行的统计方法，不同的公司可能会有着不同的统计方法，但不管使用什 么方法进行统计，统计的方法只能使用一种。不同的项目使用不同的统计方法，这样数据之间没有 参考价值。 通常说的代码是程序文件中的一行代码，但是注释行或空行除外，代码通常包括程序头、函数 声明、可执行的语句和不可执行的语句。 在统计过程中，统计物理行代码和统计指令语句是存在差异的，有时候甚至会差得很多，如 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 个，这种情况复杂度为低。 功能点总数的公式如下： 5 3 ij ij i 1 j 1 FC w x wij 是从 5 个方面和复杂度的高、中、低三个方面进行加权的加权因子，xij 表示应用程序中组 件的数量。 接下来是确定 0～5 的范围，它受系统的以下 14 个特性影响： 数据通信；
函数分布； 性能； 使用配置； 交易率； 联机数据输入； 终端用户使用效率； 在线更新； 复杂的过程； 可重用性； 安装的易用性； 操作的易用性； 多站点访问； 改变的方便性。 这些特性的权值范围是 0～5，通过下面的公式可以对特性的因子进行调整，具体的公式如下： 14 i i 1 VAF 0.65 0.01 c 这些特性的权值范围是 0～5，通过下面的公式可以对特性的因子进行调整，具体的公式如下： 综合上面的功能点和权重因子，最后功能点的公式如下： FP FC VAF 从 CMM（能力成熟度模型）的角度来看，CMM 级别与功能缺陷率的关系见表 9-15。
