Logiscope测试机理[2] 软件测试
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
文章来源于领测软件测试网 https://www.ltesting.net/
