本文挡描述的是Logiscope——Audit中函数作用域常用度量元的具体含义。

对每个度量元的解释分为以下几部分：

首先是该度量元的原文名称，后面是该度量元的代号，跟在后面的是Audit质量模型为该度量元设的参考值（用中括号括起。当然，对于这个范围值，我们可以对它进行修改），再往下就是对该度量元含义的具体解释。

2函数度量元

下面分别介绍函数作用域中各个度量元的具体含义。注意，下面讨论的所有问题都是站在一个函数的角度上的，这一点对于我们理解这些度量元很重要。

2.1 "Cyclomatic Number" : ct_vg       [ 1   ,  10 ]      

度量元名称：函数的圈复杂度。

解释说明：

函数圈复杂度的计算方法为：将函数流程图中各节点（开始和结束结点除外）的引出边的数量减去一后的值相加，最后再在这个和的基础上加一。可见，当一个函数中条件判断的地方越多时，它的ct_vg就会越大。

如果该值过大，会增大函数的复杂性，影响我们对函数的理解。

2.2 "Number of Branches" : ct_bran    [ 0 ,   0 ]     

度量元名称：函数中非结构化语句的数量。

解释说明：

非结构化语句包括：goto语句、在循环中使用的break、continue语句。

该度量元是为了使程序编写符合结构化的要求。

2.3 "Number of Declared Variables" : dc_lvars    [  0  ,   5 ]

度量元的名称：函数中定义的变量的数量。

解释说明：

在函数体内部定义的变量的数量。函数中局部变量定义的过多，会增大代码的复杂性，影响对函数的理解。

2.4 "Number of parameters" : ic_param       [ 0   ,   5 ]

度量元的名称：函数参数的数量。

解释说明：

函数的参数过多，会使函数易于受外部（其他部分的代码）变化的影响，从而影响维护工作。

函数的参数过多也会增大测试的工作量。

2.5 "Number of Direct Calls" : dc_calls    [ 0 ,   5 ]

度量元的名称：函数中调用其它函数的数量。

解释说明：

在函数体中调用其它函数的数量，对同一函数的多次调用计为一次。

该值过大，首先是会使函数易于受外部（其他部分的代码）变化的影响，从而增加维护工作的工作量。

其次，该值过大，也会增加阅读程序的人在理解程序上的困难。

2.6 "Number of Exits" : ct_exit    [ 0  ,   1]

度量元的名称：函数出口的数量。

解释说明：

也就是函数体中退出点的数量。

在一个函数中存在一个以上的出口会增加函数出错的可能性，建议单出口。

2.7 "Number of Distinct Uses of External Attributes" : ic_varpe    [ 0 ,  2 ]

度量元的名称：函数中使用其它类的数据成员的数量。

解释说明：

所谓函数中使用的其它类的数据成员的数量，也就是在函数体中对外部类（与该函数所属的类不是同一个类）的数据成员的使用数量，对同一数据成员的多次使用计为一次。

这个度量元的用意也很好理解，就是为了尽量减少函数与其它类的耦合关系。

2.8 "Number of paths" : ct_path    [ 1  ,   60 ]

度量元的名称：函数中执行路径的数量。

解释说明：

函数中执行路径过多，会极大的增大测试的工作量。

2.9 "Number of Statement"  : lc_stat [  1 ,  20 ]

度量元的名称：函数中的可执行语句数.

解释说明：

函数中的可执行语句数过多，意味着函数的功能可能不单一，同时也会增加函数的复杂性。

2.10 "Average size of statements"    :  AVGS    [  1.00 ,   9.00 ]

度量元的名称：语句平均承载的信息量。

解释说明：

该度量元计算在一个函数中，平均每个可执行语句所包含的操作符和操作数的数量。

该度量元的计算公式为：

AVGS = (N1 + N2) / (lc_stat )

其中：

         N1 是该函数中的操作符的数量,

         N2 是该函数中的操作数的数量,

         lc_stat  是函数中可执行语句的数量.

如果平均每个可执行语句所包含的操作符和操作数的数量较多时，也就是说当程序语句比较长时，会增大阅读者理解程序的难度。应该将较长的语句分解为几个较短的语句，以此来降低程序的复杂性。

2.11 "Vocabulary frequency":  VOCF                  [  1.00   ,   4.00 ]

度量元的名称：词汇频率。

解释说明：

    该度量元表示的是在一个函数中，相同的操作符和操作数出现的频率。

该度量元的计算公式为：

VOCF = (N1+N2) / (n1+n2)

其中：

       N1 是该函数中的操作符的数量，包括重复出现的；

       N2 是该函数中的操作数的数量，包括重复出现的；

       n1 是该函数中不同的操作符的数量,

       n2 是该函数中不同的操作数的数量,

当一个函数VOCF的值较高时，说明在这个函数中可能包含重复的或类似的语句。如果确实是这种情况，建议将这些反复使用的语句分离出来，写成一个单独的函数，从而增加了程序的简明、清晰程度，也为以后修改这个函数带来了方便。

2.12 "Comments frequency": COMF [  0.20  ， +oo ]

度量元的名称：函数的注释比率。

解释说明：

    函数中的注释块的数量与函数中的可执行语句的数量之比。

该度量元的计算公式为：

COMF = (lc_bcom + lc_bcob) / (lc_stat )

其中：

       lc_bcom 是函数体中注释块的数量,

       lc_bcob 是函数体前注释块的数量（值只能为 0 或 1）,

       lc_stat  是函数中可执行语句的数量.

这个度量元能反映出程序的开发者是否对程序进行了认真的注释。如果函数的注释写的比较充分，那么在我们进行测试工作和维护工作需要理解程序代码时是非常有用的。

这个度量元检测的是注释块的数量，而不是注释行的数量，这种注释量的计算方法我认为更科学。

2.13 "Number of levels":   LEVL = ct_nest + 1          [ 1 ，4 ]

度量元的名称：函数中具有嵌套的控制结构的最大的嵌套层数再加一。

解释说明：

该度量元的计算公式为：

LEVL = ct_nest + 1

其中：ct_nest：函数中控制结构嵌套的最大嵌套层数。

函数中具有嵌套的控制结构的最大的嵌套层数再加一。该值越大，说明函数越复杂，越难于理解。

2.14 "Fan In": FAN_IN        [  0   ，4 ]

度量元的名称：扇入

解释说明：

该度量元的计算公式为：

FAN_IN = ic_usedp + ic_varpi

其中：       ic_usedp 是函数参数的个数；

        ic_varpi 是函数对本类中数据成员的使用次数。

这个度量元反映的是函数需要输入的数据量。 如果函数需要输入的数据过多，那么阅读者对函数进行理解时会变的困难，并且外部变化对函数的影响也会较大。

2.15 "Fan Out": FAN_OUT    [  0  ，     4 ]

度量元的名称：扇出

解释说明：

该度量元的计算公式为：

FAN_OUT = ic_paradd +ic_varpe

其中：       ic_paradd  是传址参数的个数；

ic_varpe   是函数对外部类数据成员的使用次数。

这个度量元反映的是函数的输出数据量。如果函数输出的数据量过多，那么对这个函数进行理解分析时会很困难。同时，函数输出的数据量越大，这样的函数对系统的影响也会越大，所以应该加以限制。

2.16 " Number of callers ": dc_calling   [  0  ， 7 ]

度量元的名称：被调用次数

解释说明：

该项度量元表示的是：调用了该函数的函数的个数。

一个函数，调用它的函数越多，则对该函数的可靠性要求的越高，它一旦发生问题，引发的后果就越严重。系统中这样的函数越多，出现问题的可能性就越大，所以应该加以限制。

2.17 "Number of relative call graph levels": cg_levels   [  1  ， 12 ]

度量元的名称：调用层次数

解释说明：

该项度量元表示的是：在该函数的调用关系图中，函数调用关系的层次数。

比如图2-1的这个的函数调用关系图中，函数Fun2( )的cg_levels的值为3。

图 2-1 函数调用关系图

2.18 "Relative call graph Hierarchical complexity": cg_hiercpx   [  1.0  ， 5.0 ]

度量元的名称：每层平均函数个数

解释说明：

该项度量元表示的是：在该函数的调用关系图中，平均每一层上的函数个数。

比如图2-1的函数调用关系图中，函数Fun2( )的cg_hiercpx的值为4 / 3 = 1.3。

2.19 " Relative call graph Structural complexity ": cg_strucpx   [  0.0  ， 3.0 ]

度量元的名称：函数平均调用数量

解释说明：

该项度量元表示的是：在函数的调用关系图中，每个函数的平均调用数量。

比如图2-1的函数调用关系图中，函数Fun2( )的cg_strucpx的值为3 / 4 = 0.75。

2.20 "Number of relative call graph call-paths":IND_CALLS   [  1  ， 30 ]

度量元的名称：调用路径数量

解释说明：

该项度量元表示的是：在该函数的调用关系图中，从该函数到每个叶子函数的不同路径数量之和。

比如图2-1的函数调用关系图中，函数Fun2( )的IND_CALLS的值为2。

2.21 "Relative call graph System testability":cg_testab   [  0.0  ， 1.0 ]

度量元的名称：函数调用关系的易测性

解释说明：

该项度量元表示的是：对该函数的函数调用关系进行测试时的工作量。

本文挡描述的是Logiscope——Audit中常用的系统度量元的具体含义。

对每个度量元的解释分为以下几部分：

首先是该度量元的原文名称，后面是该度量元的代号，跟在后面的是Audit质量模型为该度量元设的参考值（用中括号括起。对于这个范围值，我们可以对它进行修改），再往下就是对该度量元含义的具体解释。

2系统度量元

下面介绍系统作用域中各个度量元的具体含义。注意，下面讨论的所有问题都是站在整个系统（或子系统）的角度上的，这一点对于我们理解这些度量元很重要。

2.1 "Coupling Factor" : ap_cof     [0.03 ,   0.18]

度量元名称：类耦合因素。

解释说明：

该度量元的计算方法为：

                   类的总数

ap_cof = （∑ Ci与其他的类发生耦合关系的数量）/ 类的总数*（类的总数 — 1）

                     i = 1

( 注：Ci表示第i个类 )

当某一个类有以下情形之一时，该类与其他类的耦合关系的数量加一：

       1 在该类的类函数中调用了另一个类的成员函数。

       2 该类通过友员的方法调用另一个类中的可见或不可见的函数。

       3 在该类中调用了另一个类的构造/析构函数。

       4 该类中将另一个类作为数据成员或作为类函数中的参数。

2.2 "Method Inheritance Factor" : ap_mif  [ 0.6 ,   0.8]

度量元名称：类函数继承的比率。

解释说明：该度量元是一个比值。

分子为：在系统所有类的成员函数中，由父类继承来的成员函数的数量总和。

分母为：系统所有类的成员函数的总和（包括自己定义的和从父类继承而来的）。

2.3 "Attribute Inheritance Factor" : ap_aif  [0.3 ,  0.6]

度量元名称：类数据成员继承的比率。

解释说明：  该度量元是一个比值。

分子为：在系统所有类的数据成员中，由父类继承来的数据成员的数量总和。

分母为：系统所有类的数据成员的总和（包括自己定义的和从父类继承而来的）。

2.4 "Polymorphism Factor" : ap_pof     [ 0.3 ,   1.0 ]

度量元名称：类的多态性因素。

解释说明：该度量元是一个比值。

分子为：在系统所有类的成员函数中，重载的函数的数量总和。

分母为：

                系统中类的总数

∑（Ci中未被重载的成员函数的数量* Ci子类的个数）

                  i = 1

( 注：Ci表示第i个类 )

2.5  "Attribute Hiding Factor" : ap_ahf [0.7 1.0 ]

度量元名称：类对其数据成员的保护程度。

解释说明：该度量元是一个比值。

分子为：在系统所有类的数据成员中，属于Private型数据成员的总数。

分母为：系统所有类的数据成员的总和。

2.6 "Average coupling between objects": AVG_CBO           [0.0 , 10.0 ]

度量元名称：系统中类耦合的平均值。

解释说明：

计算公式为：

AVG_CBO = ap_cbo / ap_clas

其中：ap_cbo 的值由以下两部分组成：

1在一个类的成员函数中调用不属于该类的函数，在系统中，这种情况出现一次，ap_cbo的值加一。

            2类中类类型数据成员的数量。在系统中，这种情况出现一次，ap_cbo的值加一。

         ap_clas：系统中类的数量。

如果该值过高，则说明系统中类与类之间的耦合较强，这会使对系统进行更改工作时变的非常困难。

2.7 "Number of Levels in the Inheritance Graph" : ap_inhg_levl     [ 1 ,  4 ]

度量元名称：类继承图的深度。

解释说明：在系统中所有的类继承图中，最大继承层次的数量。

2.8 "Method Hiding Factor" : ap_mhf [ 0.1 ， 0.4 ]

度量元名称：类成员函数的私有情况。

解释说明：

该度量元的计算公式为：

                               类总数 类i中函数个数

ap_mhf =（∑ [ ∑（ 1 – V( m ) ）]）/ （系统中类成员函数数量的总和）

                                     i = 1  m=1

其中V( m )的值为：

    当该函数为 public型时，V( m ) = 1

    当该函数为 private型时，V( m ) = 0

    当该函数为 protected型时，V( m ) = ( 由该类派生的类的个数 ) /（类总数 – 1 ）

2.9 "Hierarchical Complexity of the Inheritance Graph" : ap_inhg_cpx    [ 1.0 ,  2.0 ]

度量元名称：类继承图的层次复杂性。

解释说明：

它的计算公式为：

ap_inhg_cpx == SUM( N * I ) / SUM( N )

其中：SUM表示取和，       I为类继承图中的层次序号（1，2，3…），N 为继承图中第I层中的结点个数。例如下面这样的一个继承关系：

 

则 ap_inhg_cpx = （ 1* 1 + 2*3 + 3*1 ）/ （1 +  3  +  1 ）= 2.0。由计算公式可以看出，多继承很影响该度量元的得分，所以尽量避免多重继承。

该度量元是类继承关系的图形结构的表示，它的目的是测量类继承关系的复杂性。如果改值大于二，则表明类的继承关系过于复杂。

2.10 "Ratio of repeated inheritances in the application": URI_Ratio       [ 0.0 ,  10.0 ]

度量元名称：重复继承的类的数量占系统中类继承关系数量的比率。

解释说明：重复继承的类的数量占系统中类继承关系数量的比率。

该度量元的计算公式为：

URI_Ratio = (ap_inhg_uri * 100) / ap_inhg_edge

其中：ap_inhg_uri ：系统中重复继承的“类对”的数量。

          ap_inhg_edge：系统中类的继承关系图中边的数量。

那么，何为重复继承呢？重复继承指某一个类对同一个类继承两次。下面举一个例子。

比如：

 
在这个例子中, 类E通过类对 (B,C)、(C,D)、(B,D)对类A重复继承。则ap_inhg_uri的值为3。ap_inhg_edge的值为6。所以URI_Ratio = (3 * 100) / 6 = 50.0

过多的重复继承会导致程序变的复杂，还可能发生函数命名冲突（ 类E中的函数就可能会有命名冲突）。所以在组织程序时，提倡单继承，避免使用多继承类。

2.11 "Percentage of non-member functions": NMM_Ratio    [ 0.0 ,  10.0 ]

度量元名称：独立于类的函数的比率。

解释说明：

系统中非成员函数（独立于类的函数）占系统中函数总数的比率。

该度量元的计算公式为：

NMM_Ratio =( ( ap_func - ap_nmm )  /  ap_func) * 100

其中：ap_func：系统中总的函数数量（包括游离于类之外的全局函数）。

          ap_nmm ：系统中各个类的成员函数的数量之和。

如果该度量元的值过大的话，说明该程序设计不符合面向对象的思想。

2.12  "Average of the VG of the application's functions":  AVG_VG     [ 1.0 ,  5.0 ]

度量元名称：系统中每个函数的平均圈复杂度。

解释说明：

该度量元的计算公式为：

AVG_VG = ap_vg / ap_func

其中：ap_vg  ：系统中各函数的圈复杂度的总和（关于函数的圈复杂度的计算方法请参见〈〈Logiscope函数度量元〉〉文挡）。

      ap_func：系统中函数的数量（包括成员函数和非成员函数）

如果该值过高，则说明系统中有大量函数的圈复杂度的值过高，也就是说系统中有大量过于复杂的函数。由于函数的复杂性过高，对于系统的维护工作是很不利的。

2.13  " Ratio of recursive edges on the call graph ":  RECU_Ratio     [ 0.0 ,  5.0 ]

度量元名称： 递归调用的百分比。

解释说明：

该度量元的计算公式为：

RECU_Ratio = (ap_cg_cycle * 100) / ap_cg_edge

其中：

ap_cg_cycle  ：函数调用流程图中递归调用的数量。

    ap_cg_edge  ：函数调用流程图中边的数量。

2.14  " Number of Levels in the Call Graph ":  ap_cg_levl     [ 2 ,  9 ]

度量元名称： 函数调用流程图的最大层次数。

解释说明：

在系统所有的函数调用流程图中，最大的层次数。

本文挡描述的是Logiscope——Audit中常用的类度量元的具体含义。

对每个度量元的解释分为以下几部分：

首先是该度量元的原文名称，后面是该度量元的代号，跟在后面的是Audit质量模型为该度量元设的参考值（用中括号括起。当然，对于这个范围值，我们可以对它进行修改），再往下就是对该度量元含义的具体解释。

2类度量元

下面分别介绍类作用域中中各个度量元的具体含义，注意，下面讨论的所有问题都是站在一个类的角度上的，这一点对于我们理解这些度量元很重要。

2.1 "Class Comments Frequency": COMFclass      [ 0.2,  +oo ]

度量元的名称：类注释频度

解释说明：

该度量元表示类中注释的频度。所谓类的注释，只限于类定义的中的注释，不包括类实现中的注释。

该度量元的计算公式为：

COMFclass =

(cl_bcom + cl_bcob) / (cl_func_publ + cl_func_prot + cl_data_prot + cl_data_publ)

其中：

cl_bcom：     类前的注释数量（只能为1或0）

cl_bcob：     类定义中的注释数量

cl_func_publ：类中public成员函数的数量

cl_func_prot：类中protected成员函数的数量

cl_data_prot：类中protected数据成员的数量

cl_data_publ：类中public数据成员的数量

2.2 "Fan out value of a class":   FAN_OUTclass   [ 0,  20 ]

度量元的名称：类的扇出值。

解释说明：

该度量元的计算公式为：

FAN_OUTclass = cl_data_prot + cl_data_publ +cl_usedp + cl_data_vare

其中：cl_data_prot： 类中protected数据成员的数量之和，

          cl_data_publ： 类中public数据成员的数量之和,

          cl_usedp：    类函数所使用的参数的数量之和，

cl_data_vare   类函数中使用的外部类的数据成员的数量之和。

   这个度量元反映了类对外的数据输出量，其值越大，就说明这个类对整个系统的影响越大。

2.3 "Fan in of a class":   FAN_INclass       [ 0,  15 ]

度量元的名称：类的扇入值。

解释说明：

该度量元的计算公式为：

FAN_INclass = cl_data_prot + cl_data_publ + cl_usedp + cl_data_vari

其中：

cl_data_prot： 类中protected数据成员的数量，

      cl_data_publ： 类中public数据成员的数量,

      cl_usedp：    类函数所使用的参数的数量之和，

cl_data_vari： 类函数中使用本类的属性的次数之和

    这个度量元反映了类通过其数据成员和成员函数参数而引进的数据输入量，其值越大，该类日后需要频繁修改的可能性就越大。

2.4 "Number of Dependent Methods" : cl_dep_meth  [0,  6 ]

度量元的名称：类对其他模块的依赖性。

解释说明：

该度量元表示，在一个类中，要依赖于本类之外的其他模块才能实现功能的类函数的个数。符合这样的条件的函数包括：

1 在该函数中调用了其它类的类函数。

         2 在该函数中使用了其它类的数据成员。

         3 在该函数的参数中有其它类的类类型的参数。

         4 在该函数中有一个其它类的类类型的变量。

该度量元的目的是控制类与类之间的耦合程度。

2.5 "Number of Base Classes" : in_bases    [ 0,  3 ]

度量元的名称：基类的数量

解释说明：

该类基类的数量，基类包括其类继承图中所有的父类。当MFC类库中的类作为父类时，则该MFC类的基类的数量不再计入其中。在下图中，class 4的in_bases为4。

2.6 "Weighted Methods Per Class" : cl_wmc  [ 0,   25 ]

度量元的名称：类的圈复杂度。

解释说明：

类中各个成员函数的圈复杂度的总和（关于函数的圈复杂度的计算方法请参见〈〈Logiscope函数度量元〉〉文挡）。

2.7 "Specializability":SPECIAL [ 0,  25 ]

度量元的名称：类功能的专一性。

解释说明：

该度量元的计算公式为：

SPECIAL =  

2 * ( cl_data_publ + cl_data_prot )  +  cl_func_publ + cl_func_prot + 10 *in_bases

其中：cl_data_publ：类中public型的数据成员的数量。

          cl_data_prot：类中protected型的数据成员的数量。

          cl_func_publ：类中public型的成员函数的数量。

          cl_func_prot  类中protected型的成员函数的数量。

          in_bases：    该类的基类的数量（包括直接基类的基类）。

2.8 "Usability": USABLE      [ 0,  10 ]

度量元的名称：类的易用性。

解释说明：

该度量元的计算公式为：

USABLE = (2 * cl_data_publ) + cl_func_publ

其中：

cl_data_publ：      类中public型的数据成员的数量

cl_func_publ：     类中public型的成员函数的数量

该度量元表示了类对外的接口情况，类对外的接口越多，掌握、使用这个类就越困难。

2.9 "Encapsulation rules":   ENCAP       [ 0,  5 ]

度量元的名称：类的封装性。

解释说明：

该度量元的计算公式为：

ENCAP = cl_data_publ + cl_data_vare

其中：cl_data_publ：类中public型的数据成员的数量

          cl_data_vare：在类成员函数中使用的外部类的数据成员的次数之和

2.10 "Number of Direct Users Classes" : cu_cdusers [  0  ,    4  ]

度量元的名称：被其他类使用的次数。

解释说明：

该类被其他类使用的次数 (被同一个类多次使用计为一次).

2.11 "Class Coupling" : cl_cobc    [ 0,  12 ]

度量元的名称：类耦合

解释说明：

该度量元的值，包括以下几种情况之和：

        1 该类直接基类的数量

        2 该类中类类型的数据成员的数量

        3 调用了静态成员函数的成员函数的数量的二倍。

        4有类类型参数的类成员函数的数量的二倍。

        5有类类型变量的类函数数量的三倍。

2.12 "Number of Children" : in_noc     [ 0,  2 ]

度量元的名称：派生类数量。

解释说明：从该类派生的类的数量。只计直接派生类的数量，间接派生不算在内。

2.13 "Rate of class autonomy ": AUTONOM  [30.0,  100.0 ]

度量元的名称：类自治的程度。

解释说明：

该度量元的计算方法为：与其它的类没有牵扯关系的类函数和类数据成员的数量之和，再除以类函数和类数据成员的数量之和的百分比。

该度量元的计算公式为：

AUTONOM =

  100 * ((cl_func_priv + cl_func_prot + cl_func_publ - cl_dep_meth) +

  (cl_data_prot + cl_data_publ + cl_data_priv - cl_data_class))  /

  (cl_func_priv + cl_func_prot + cl_func_publ + cl_data_priv + cl_data_prot + cl_data_publ)

其中：

cl_func_priv ：        类中private型的成员函数的数量。

      cl_func_prot ：        类中protected型的成员函数的数量。

      cl_func_publ ：        类中public型的成员函数的数量。

      cl_data_prot ：         类中protected型的数据成员的数量。

      cl_data_publ ：         类中public型的数据成员的数量。

      cl_data_priv ：         类中private型的数据成员的数量。

      cl_data_class：         类中类类型数据成员的个数.

      cl_dep_meth：          类函数中要依赖本类之外的函数的个数， 这样的函数是指：

                                1 该函数使用了其他类的数据成员

                                2 在该函数中调用了其他类的函数

                                3 该函数有一个其他类类型的实体对象的参数

                                4 该函数中有一个其他类的类类型的变量

2.14  "Number of used Classes" : cu_cdused      [ 0,  4 ]

度量元的名称：使用其它类的数量

解释说明：

在该类中直接使用的其它类的数量。多次使用同一个类计为一次。

2.15 "Testability": TESTAB    [ 0,  100 ]

度量元的名称：易于测试性。

解释说明：

该度量元的计算公式为：

TESTAB =

    cl_fprot_path + cl_fpriv_path + cl_fpubl_path + cl_data_vare + cl_func_calle

其中：

cl_fprot_path：  类中所有的protected型函数的执行路径总和，

cl_fpriv_path：  类中所有的private型函数的执行路径总和，

cl_fpubl_path：  类中所有的public型函数的执行路径总和。

cl_data_vare ：  类函数中使用的外部类的数据成员的次数之和，

      cl_func_calle：  类函数中对类外部的函数的调用次数之和，

通过观察该度量元的各个组成元素，我们会发现这些都是会对我们需要制定测试用例的数量产生重要影响的数据。

本文介绍了Logiscope——Audit对应于软件质量模型，在质量因素级、质量标准级上的具体实现。需要说明的是，文档中描述的质量模型只涉及了可维护性这个质量因素。根据情况，我们可以制做出不同的质量模型。这篇文档的目的是为了能让大家更好的了解Audit对软件质量模型的实现。

2 质量因素

我们先说质量因素这一级。每个质量因素都由若干个质量标准按权重相加组成。关于这些质量标准的含义，请看本文档第三部分的内容。

2．1 函数作用域

2.1.1函数的可维护性质量因素

该质量因素表示：对函数进行修改时，为防止引发错误，所需要做的工作的难度。其计算公式为：

function_MAINTAINABILITY  =    function_ANALYZABILITY

                                + function_CHANGEABILITY

                                + function_STABILITY

                                + function_TESTABILITY

2.1.2 函数调用复杂性质量因素

该质量因素表示：对函数进行修改时，为防止引发错误，所需要做的工作的难度。其计算公式为：

relativeCall_MAINTAINABILITY  =   relativeCall_ANALYZABILITY

                                      + relativeCall_STABILITY

                                      + relativeCall_TESTABILITY

2．2 类作用域

2.2.1 类的可维护性质量因素

该质量因素表示：对类进行修改时，为防止引发错误，所需要做的工作的难度。其计算公式为：

class_MAINTAINABILITY  =   class_ANALYZABILITY

                            + class_CHANGEABILITY

                            + class_STABILITY

                            + class_TESTABILITY

2.2.2 类的可复用性质量因素

可复用性是指类是否能够被比较容易的复用。其计算公式为：

class_REUSABILITY  =   class_USABILITY

                           + class_SPECIALIZABILITY

                           + class_ANALYZABILITY

2．3 系统作用域

2.3.1系统的可维护性质量因素

该质量因素表示：对程序代码进行修改时，为防止引发错误，所需要做的工作的难度。其计算公式为：

application_MAINTAINABILITY  =  application_ANALYZABILITY

                                    + application_CHANGEABILITY

                                    + application_STABILITY

                                    + application_TESTABILITY

3 质量标准

下面我们讨论软件质量模型中质量标准这一级。质量标准组成了我们上面说到的质量因素。每个质量标准都是由若干个质量度量元按权重相加组成的。关于组成各个质量标准的度量元的含义，请看《Logiscope-Audit函数度量元》、《Logiscope-Audit类度量元》、《Logiscope-Audit系统度量元》这3篇文章的内容。

3．1 函数的质量标准

3.1.1 函数易于测试性质量标准

该质量标准表示：函数被修改后，为保证系统不发生错误，需进行测试的工作量。计算公式为：

function_TESTABILITY  =  dc_calls  +  LEVL  +  ct_path  +  ic_param

3.1.2 函数稳定性质量标准

该质量标准表示：函数之外的代码发生变化之后，导致函数发生错误的可能性。计算公式为：

function_STABILITY  =  dc_calling  +  ic_varpe  +  ct_exit  

+  dc_calls + ic_param

3.1.3 函数适应变化性质量标准

该质量标准表示：当需要更改函数代码、修正函数代码缺陷时，需做的工作量。计算公式为：

function_CHANGEABILITY  =  ic_param  +  dc_lvars  + VOCF  +  ct_bran

3.1.4 函数易于分析性质量标准

该质量标准表示：理解函数所需花费的脑力劳动量，也就是函数的复杂程度。计算公式为：

function_ANALYZABILITY  =  ct_vg  +  lc_stat  +  AVGS  +  COMF

3.1.5 函数调用可分析性质量标准

该质量标准表示：理解函数的相互调用关系所需花费的脑力劳动量。计算公式为：

relativeCall_ANALYZABILITY  =  cg_strucpx  +  cg_levels

3.1.6函数调用稳定性质量标准

该质量标准表示：对程序（包括本函数体中的代码以及其他函数体中的代码）进行修改时，导致引发意想不到的错误的可能性。其计算公式为：

relativeCall_STABILITY  =  IND_CALLS  +  cg_hiercpx

3.1.7函数调用易于测试性质量标准

该质量标准表示：为了验证程序的正确性，所需测试工作的工作量。其计算公式为：

relativeCall_TESTABILITY  =  cg_testab  +  IND_CALLS

3．2 类的质量标准

3.2.1类可分析性质量标准

该质量标准表示：为了理解类的功能，所需付出的脑力劳动量。其计算公式为：

class_ANALYZABILITY  =  cl_wmc  +  in_bases  +  cl_dep_meth 

+  FAN_Inclass  +  FAN_OUTclass  +  COMFclass

3.2.2 类适应变化性质量标准

该质量标准表示：当需要对类进行修改时，所需付出的工作量。其计算公式为：

class_CHANGEABILITY  =  ENCAP  +  USABLE  +  SPECIAL

3.2.3 类稳定性质量标准

该质量标准表示：当需要对程序进行修改时，为了防止发生错误所需付出的工作量。其计算公式为：

class_STABILITY  =  AUTONOM  +  in_noc  +  cl_cobc  +  cu_cdusers

减少类与类之间的耦合，提高类的封装程度，会提高类的稳定性。

3.2.4 类易于测试性质量标准

该质量标准表示：为了验证程序的正确性，所需测试工作的工作量。其计算公式为：

class_TESTABILITY  =  in_bases  +  TESTAB  +  cu_cdused

3.2.5 类易于使用性质量标准

该质量标准表示：类是否能被使用者容易的理解和方便、安全的使用。其计算公式为：

class_USABILITY  =  USABLE  +  ENCAP  +  AUTONOM

3.2.6  类功能专一性质量标准

该质量标准用于检验类的可复用性。其计算公式为：

class_SPECIALIZABILITY  =  SPECIAL  +  ENCAP  +  AUTONOM

3．3 系统的质量标准

3.3.1 系统可分析性质量标准

该质量标准表示：系统的复杂程度，即系统是否能被较容易的理解。其计算公式为：

application_ANALYZABILITY  =  ap_inhg_levl  +  AVG_CBO  +  ap_aif  

+  ap_mif  +  ap_cof  +  RECU_Ratio

3.3.2 系统适应变化性质量标准

该质量标准表示：当需要对程序进行修改时，为了防止发生错误所需付出的工作量。其计算公式为：

application_CHANGEABILITY  =  ap_inhg_levl  + URI_Ratio + NMM_Ratio

+  ap_pof  +  ap_mif

3.3.3  系统稳定性质量标准

该质量标准表示：当需要对对系统进行修改时，系统发生错误的可能性。其计算公式为：

   application_STABILITY  =  AVG_CBO  +  ap_inhg_cpx  +  ap_mhf 

   +  ap_ahf  +  ap_cof

系统中的各模块之间的耦合越少，则系统的稳定性越好。

3.3.4  系统易于测试性质量标准

该质量标准表示：为了验证系统功能的正确性，所需测试工作的工作量。其计算公式为：

application_TESTABILITY  =  AVG_VG  +  NMM_Ratio  +  ap_mhf  

       +  ap_ahf  +  ap_cg_levl

依照《xx公司编码规范》的要求，测试中心对[被测系统或模块的名称]编码的规范性进行检查。对于编码中不符合《xx公司编码规范》要求的地方，进行报告。

表1-1 背景说明

2检测结果

    下面以表格的形式分别列出各个程序文件中违反《xx公司编码规范》的代码。其中，“编码规范编号”、“编码规范名”指的是该规范在《xx公司编码规范》中的编号和名称，“行号”指违反规范的代码在程序文件中的行号。

2.1文件1

表2-1 文件1中违反编码规范之处

2.2文件2

表2-2 文件2中违反编码规范之处

2.3... ...

… …

… …

附录

为了让大家在使用Logiscope测试实际的项目时，能够有所依据和参考，进而提高该工具的使用效率，制定了本应用方案。

本应用方案描述了使用Audit和RuleChecker的过程，并给出了最后提交的测试报告的模版供参考。

2 关于Audit的应用

    通过Audit对软件进行质量监控，能确实的提高软件质量，但这项工作比较耗费时间和精力，所以如果决定要做，就要认真对待。如果匆忙、潦草的进行，会感觉既浪费时间，又没有明显的效果。

2.1 Audit的功能

    Audit有两项功能——质量监控和程序分析。

2.1.1质量监控

    对于Audit质量监控这项功能，现在还不能使其最充分的发挥作用。我们现在可以做的是：依照Audit自身提供的质量模型，对软件的质量进行监控。

2.1.2程序分析

    除了进行质量监控外，Audit还可以提供程序的内部实现信息，包括每个函数（成员函数和非成员函数）的控制流程图、调用关系图，每个类的继承关系图、使用关系图。通过这些信息，可以帮助我们了解程序的内部实现。

        Audit的这项功能，对于进行单元测试阶段的代码审查能发挥比较好的作用。可以先通过Audit定位那些较为复杂的函数、类，然后进行小组形式的代码人工走查，重点检查这一部分的代码，因为通常情况下这样的代码容易出现问题。

2.2实际应用

    下面说一下Audit在实际中的应用。分三种不同的情况：

2.2.1对于跟踪全过程的项目

    对于这样的项目，Audit可以发挥比较好的作用。工作阶段如下：
 
        1 在项目初期，提出对该项目的质量要求，决定选用Audit作为检测工具。

    2 在概要设计之前，对开发人员做软件质量方面的培训，告知对该项目的质量要求。

        3 在编码的过程中，测试人员通过Audit来检验函数、类等模块是否达到质量要求。如果与质量要求相差较大，开发人员进行修改。

        4  当组装成子系统时，给出子系统的质量报告，如果与质量要求相差较大，开发人员进行修改。

        5  对于那些最后质量评价仍然很低的函数、类等模块，可对其进行小组形式的人工代码走查，确定这些代码的正确性。

        6 在确认阶段，通过Audit来评价产品的质量，给出整个系统的质量报告。根据质量评价的结果、修改的难度，权衡是否需要进行修改。

    严格的说，只有3、4才完全是测试人员的任务，在其他的阶段，我们只是参与者之一。但由于公司目前的情况，可能其中大部分的工作都要由我们来做。

    下面给出在这个过程中，需要提交的测试报告的模板：

    第3阶段需提交的测试报告的模板——《模块质量检测报告模板》；
 
    第4阶段需提交的测试报告的模板——《模块质量检测报告模板》或《系统质量检测报告模板》。

    第6阶段需提交的测试报告的模板——《系统质量检测报告模板》；

2.2.2对于只做最后的确认测试的项目

首先要说明的是，对于只做确认测试的项目，用Audit的意义不是很大，唯一的作用是通过Audit对系统做一下质量评价。但无论评价的结果是好是坏，进行修改的可能性已经不是很大了。

    在这个过程中，需要提交的测试报告的模板——《系统质量检测报告模板》。

2.2.3对于进行维护的项目

    如果是对原有项目进行维护：可以通过Audit来检测被维护软件的质量，估算出进行维护工作的难度，从而更好的计划维护工作。

    对于那些质量已经得到保证的产品，可以通过Audit来监督项目的维护工作，使其质量不致后退。

2.3其他

    在使用Audit对项目进行质量监控时，不要忘了为被测项目制作Audit质量模型文件(Logiscope.ref)。

3 关于RuleChecker的应用

RuleChecker应用过程：

    1 在项目开始之初，要求开发人员、测试人员遵从《北京许继编码规范》中对编码的规范要求。

    2 按编码规范要求，从RuleChecker 的编码规则/规范集中挑选出适和的规则/规范，编写RuleChecker规则文件（RuleChecker.cfg）和对应的Audit质量模型文件(Logiscope.ref)。

    3 编写出RuleChecker可用规则列表，列出RuleChecker规则与《北京许继编码规范》中各条规范的对应关系。

    4 在开发过程中，测试人员通过RuleChecker对代码进行编码规范的自动化检查，报告不符合规范的地方，开发人员进行修改。（报告格式请参见《编码规范检测报告模板》）

4 关于TestChecker

    RuleChecker现在存在问题，用其他覆盖率统计工具代替。

5 结束

Logiscope的使用过程并不局限于此文档中描述的内容。大家在实际应用Logiscope的过程中，当有特殊的需要时，可对该使用方案进行裁剪。如果发现某些情况比较普遍，可以补充到该方案中。

本文介绍了静态测试工具Logiscope的测试机理。通过对Logiscope测试机理的了解，能帮助我们更好的使用这个工具。

通过阅读本文，你可以了解到以下信息：

 Logiscope是如何分析软件产品质量的；

 Logiscope是如何检测代码的编码规范的；

 Logiscope是如何统计测试覆盖率的；

2 Logiscope总览

Logiscope有三项主要功能，以三个独立工具的形式出现，分别是：

软件质量分析工具——Audit；

代码规范性检测工具——Rulechecker；

测试覆盖率统计工具——TestChecker。

Audit和Rulechecker提供了对软件进行静态分析的功能，TestChecker提供了测试覆盖率统计的功能。
    
    Logiscope可以对多种语言实现的代码进行分析，比如C、C++、Java、Ada，等等。下面的内容与具体的语言基本是没有关系的，但如果某些地方确实要涉及具体的语言，则我都是以C++为例。

    下面，我对Audit、Rulechecker和TestChecker的测试机理，分别进行介绍。

3 Audit测试机理

3．1软件质量模型

前面已经说过，Audit是审查程序代码质量的。要讨论代码的质量，就需要先说明一下软件质量模型的概念，因为理解下面的内容需要软件质量模型的相关知识。

如果你原来学习过软件质量保证的相关知识，那么应该会对软件质量模型这个概念有印象。为了说明Audit的测试机理，在这里只对软件质量模型做个简单的介绍。如果你对软件质量模型的概念比较陌生，建议找一本讲述软件工程方面的书，阅读一下软件质量保证部分的内容。

软件质量模型是一个分层结构，它的一般形式如下图所示：

由图可以看出，质量因素处于质量模型中最高一级。软件的质量因素包括功能性、可靠性、易用性、效率、可维护性、可移植性这六个方面（在ISO/IEC 9126中有详细的描述）。

在质量因素之下，又细分成多个质量标准。

每个质量标准又由多个质量度量元组成。这些质量度量元处于质量模型分层结构中的最底层。

    质量因素、质量标准一般是固定的，就是这几类，但质量度量元不是固定的，可以根据不同的情况发生变化。

软件质量模型就是一个将程序信息由底层到高层、由细节到概括的一个过程模型，它由简单、可测量的数据入手，最后分析概括出软件的特征。

3．2 Audit对软件质量模型的实现

上面我们了解了软件质量模型的大体结构，Audit也是按照这种分层、量化的方式来审查代码质量的。

Audit通过一个文本文件来定义质量模型。在为被测代码建立Audit检测项目的过程中，有一步是要求我们“choose a quality”，这就是在要求我们设定一个质量模型，默认的，Audit会提供一个质量模型文件，它的位置在“LogiscopeHOME\Logiscope\Ref\Logiscope.ref”。用记事本打开这个文件，通过观察我们会发现，文件中首先定义了若干个度量元，并为这些度量元设定了数值范围，接着通过组合若干个度量元形成质量标准，最后又通过组合质量标准，形成最后的质量因素。这个过程与软件质量模型中由底层到高层、由细节到概括的结构恰好对应。

除了使用Audit提供的这个质量模型文件外，我们当然可以定义自己的质量模型文件（99%的情况下都需要我们制定符合我们需要的质量模型文件），只要符合Logiscope.ref这个文件的格式即可。

为了方便起见，我们下面就以Audit提供的这个质量模型文件展开讨论，讲解Audit对软件质量模型的实现。

对应于质量模型中质量因素这一级，Logiscope提供的默认的质量模型文件对软件的可维护性这个质量因素进行了实现，使用这个文件，可以通过Audit评价软件的可维护性水平。

对于软件质量模型中最底层的质量度量元级，质量模型文件从Audit提供的度量元中选择了几十个度量元构成了基本度量元，比如函数语句数度量元（lc_stat）、类公共数据成员数度量元（cl_data_publ），等等。

那么各层具体的分析结果是如何得出来的呢？我们按照质量度量元、质量标准、质量因素的顺序由底到高，依次解释。

在Audit的内部定义了大量的质量度量元，度量元是检验一个软件质量好坏的最基本元素。在Logiscope提供的这个默认质量模型文件中，选取的度量元都是为最后评价可维护性提供服务的。通过观察Logiscope.ref质量模型文件，你会发现，度量元都可以量化为数字，允许我们在质量模型文件中为每个度量元设定上限值和下限值。当某一度量元超出我们设定的上限值和下限值的范围时，Audit就认为被检测的代码在该项度量元上不符和要求。

    下面举一个度量元的例子：lc_stat度量。该度量元表示函数中可执行语句的数量。lc_stat度量元对于衡量函数的复杂性是很有用的，比如我们可以设定它的上限值为30，下限值为0，即我们规定了：一个函数中可执行的语句数不能超过30条。这就是Audit对质量模型中度量元级的处理方法。

通过这一个个单独的度量元，我们还不能判断程序的可维护性如何，因为过于片面，只有将这些度量元按某种规则组织起来，才能对软件的可维护性作出评价。通过观察Logiscope.ref这个质量模型文件我们会发现，每个质量标准都是由若干个度量元按权相加组成的，质量标准最后也用数字来表示它自己的值。通过质量标准值的大小，Audit给出程序代码遵守该项质量标准的级别。级别共有四个，由高到底依次是EXCELLENT（优秀）、GOOD（良好）、FAIR（合格）、POOR（不合格）。下面从Logiscope.ref文件中摘录一段，作为如何计算质量标准的例子：

这个质量标准是评价函数的稳定性的。最上面一行是这个质量标准的计算公式：

function_STABILITY = ic_varpe + ct_exit + dc_calls + ic_param

该公式表明，该质量标准由四个度量元所决定，即ic_varpe 、ct_exit、dc_calls、ic_param，每个度量元的权重均为1。该质量标准的最高得分为4分，即当构成该质量标准的四个度量元的值均在我们设定的范围内时，该项质量标准得分为4分，当有三个度量元的值均在我们设定的范围内时，该项质量标准得分为3分，以此类推。最后根据具体的得分，可以判定程序代码在该项质量标准上所处的等级。这就是Audit对质量模型中质量准则级的处理方法，可以看出，质量准则是建立在质量度量元的基础之上的，是比质量度量元更加综合的一级。

最后，综合多个质量标准，得出代码的可维护性质量因素。可维护性因素的计算方法如下：

function_MAINTAINABILITY: component  =  function_ANALYZABILITY

+  function_CHANGEABILITY

+  function_STABILITY

+  function_TESTABILITY

这是在计算函数的可维护性。最上面是计算公式，函数的可维护性由四个质量标准的得分相加得出（质量标准得分的计算方法上面已经说过了）。对于这个例子来说，它的最高得分为12分，最低得分为0分。最后根据具体的得分，可以判定程序代码在可维护性上所处的等级（EXCELLENT、GOOD、FAIR、POOR）。通过层层综合，最后终于得到了可维护性质量因素的结果。

OK，以上通过Audit为我们提供的默认质量模型，讲述了在Audit中由质量度量元、到质量准则、最后到质量因素的逐级评价方法。如果是我们自己制定的质量模型，其原理是完全一样的。

怎么样，这个过程清楚了吗？如果还是有些迷惑，建议你看一看“LogiscopeHOME\Logiscope\Ref\Logiscope.ref”这个文件的内容，那会对你理解这些内容有所帮助。

3．3 作用域的划分

我们在人工分析一个应用程序的代码时，通常先会查看应用程序的总体情况，然后分析应用程序中的各个类(对于使用面向对象这类语言实现的代码来说)，进而再分析类中的成员函数。

Audit在分析、显示对代码的审查结果时，也按这种形式进行划分，我们称它为作用域，比如对于C++、Java语言实现的代码，Audit划分的作用域有：应用程序作用域、类作用域、函数作用域。通过它们的名字，你应该可以猜出各个作用域所包含的内容。应用程序作用域针对整个应用程序，类作用域针对系统中的各个类，函数作用域针对系统中的各个函数。

不同作用域之间是彼此独立的，但它们都是遵照我们前面提到的那个质量模型对代码进行分析。

3．4 Audit对代码的处理过程

对于使用Audit的用户来说，输入的是源程序代码，输出的是Audit的分析结果。Audit对代码的处理过程如图所示：

3．5 结束

好了，Audit的测试机理到此就介绍完了。

4 Rulechecker检测机理

现在来介绍一下Logiscope为我们提供的另外一个工具——Rulechecker。Rulechecker也是一个静态测试工具。

先回想一下我们组织内部的编码规范。编码规范中会对程序代码的注释、变量命名、书写格式等各个方面做出规定，其目的，是为了让开发人员书写的代码更健壮，可读性更好。Rulechecker这个工具也是为了协助我们实现使代码更健壮，可读性更好这个目的的。

Rulechecker实现了一个编码规范集。在这个规范集中的内容，与我们组织内部定义的编码规范的内容类似，但覆盖的范围要更广，规定的也更细（关于Rulechecker编码规范集中各条编码规范的详细内容，可以阅读我写的另一篇文章《RuleChecker编码规范》，在这里就不做描述了）。

在这个规范集中，有将近一半左右的编码规范，我们可以对其内容进行定制，这就大大增加了灵活性，使Rulechecker能更好的适应我们实际情况的需要。

在具体的测试过程中，Rulechecker的编码规范是如何发挥作用的呢？在我们为被测代码建立Rulechecker项目的过程中，有一步是让我们“Choose a configuration file”，这就是让我们选择一个编码规范描述文件，Rulechecker为我们提供了一个叫做‘RuleChecker.cfg’的编码规范描述文件，我们当然可以修改或重新编写一个.cfg文件，来适应我们的要求。

下面举Rulechecker编码规范集中一个编码规范的例子：Headercom编码规范

    Headercom编码规范对代码文件的文件注释做出了规定，具体内容为：“每个代码文件的头部必须有文件注释，且注释要遵照一定的格式”。这个格式可由我们来设定。

我现在将Headercom规范要求的注释格式，设置成与我所在公司的编码规范中规定的文件注释相同的格式。



    
    打开RuleChecker.cfg文件，用下面的内容代替文件Headercom原来的内容。

STANDARD Headercom ON

LIST "HEADER"                "【文件名】"

                                        "【功能模块和目的】"

                                        "【主要函数及其功能】"

                                        "【主要算法】"

                                        "【接口说明】"

                                        "【开发者及日期】"

                                        "【版本】"

                                        "【更改记录】" END LIST

LIST "CODE"                    "【文件名】"

                                        "【功能模块和目的】"

                                        "【主要函数及其功能】"

                                        "【主要算法】"

                                        "【接口说明】"

                                        "【开发者及日期】"

                                        "【版本】"

                                        "【更改记录】" END LIST

END STANDARD

做完这个操作后，保存成另一个文件，以.cfg为后缀名。在建立被测代码的RuleChecker项目时，选中这个文件，则RuleChecker会以该格式检查代码文件的文件注释格式，如果哪个文件不符合要求，就会被检测出来。

OK，RuleChecker的测试机理介绍完了，应该是很好理解的。

5 TestChecker检测机理

现在来介绍一下Logiscope为我们提供的最后一个工具——TestChecker。TestChecker是用来统计被测试程序的测试覆盖率的。它提供的覆盖率数据是边覆盖率，或者叫判定到判定的覆盖(DDP覆盖)。

所谓边覆盖率，也就是我们执行的测试用例对程序流程图中的边的覆盖情况。有一些单元测试工具，比如Numega中的TrueCoverage，Rational的Purecoverage等，它们也可以统计被测试程序的测试覆盖率，但它们所提供的覆盖率数据是点覆盖率（IB覆盖率），或者叫做语句覆盖率，这个覆盖率的覆盖强度要低于边覆盖的覆盖强度。

TestChecker 的测试机理是这样：建立起TestChecker项目后，通过TestChecker编译连接代码，生成可执行文件，在这个过程中，TestChecker会向程序源代码中涉及到控制流转移的语句处，插入一些标志语句（这个过程叫做“插装”）。在TestChecker中运行起被这个可执行文件，执行测试用例的时候，TestChecker会在后台运行。由于在程序代码中“插装”了标志语句，所以在程序的执行过程中，TestChecker能记录下程序中哪些分支走到了，哪些分支没有走到，进而统计出每个测试用例的覆盖率，以及多个测试用例覆盖率的总和。

TestChecker的测试机理基本就是这样。

6 总结

为什么要进行静态分析呢？一个软件产品可能实现了所要求的功能，但如果它的内部结构组织的很复杂，很混乱，代码的编写也没有规范的话，这时软件中往往会隐藏一些不易被察觉的错误，这是其一。其次，即使这个软件基本满足了用户目前的要求，但到了日后对该产品进行维护升级工作的时候，会发现维护工作相当困难。所以，如果能对软件进行科学、细致的静态分析，使系统的设计符合模块化、结构化、面向对象的要求，使开发人员编写的代码符合规定的编码规范，就能够避免软件中大部分的错误，同时为日后的维护工作节约大量的人力、物力。这就是对软件进行静态分析的价值所在。

统计测试覆盖率就属于动态测试的范畴了。覆盖率对于分析测试用例对被测程序的覆盖情况，进而修改、增加测试用例，提高测试覆盖，保证测试质量，是很有用处的。