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)，等等。

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

原文转自：http://www.uml.org.cn/Test/200609075.htm