静态测试工具Logiscope的测试机理

 　1前言
介绍了静态测试工具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评价软件的可维护性水平。
　　在质量标准级，在质量模型文件中定义了四个质量标准，分别是：易于分析性（ANALYZABILITY）、易于测试性（TESTABILITY）、稳定性（STABILITY）和适应变化性（CHANGEABILITY）。对于软件质量模型中最底层的质量度量元级，质量模型文件从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的分析结果。
　　3．5 结束
　　好了，Audit的测试机理到此就介绍完了。