Logiscope测试机理(3)

　　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 总结

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