Logiscope测试机理(2)

发表于:2011-11-17来源:未知作者:领测软件测试网采编点击数: 标签:logiscope
最后,综合多个质量标准,得出代码的可维护性质量因素。可维护性因素的计算方法如下: function_MAINTAINABILITY: component? =? function_ANALYZABILITY function_CHANGEA

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

  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能记录下程序中哪些分支走到了,哪些分支没有走到,进而统计出每个测试用例的覆盖率,以及多个测试用例覆盖率的总和。

原文转自:http://www.ltesting.net