浅谈Logiscope在雷达软件测试中的应用

杨明明 项利萍

摘 要 Logiscope是一款用于软件质量保证和软件测试的产品。其主要功能是对软件做质量分析和测试，用以保证软件的可靠性，特别针对要求高可靠性和高安全性的软件项目和工程。本文介绍了Logiscope的主要功能与测试原理等，并通过一个具体的测试实例，说明如何使用Logiscope进行雷达软件的测试工作。

关键词 雷达软件;静态分析;软件测试;自动化测试;Logiscope

引言

随着我国国防实力的快速提升以及对雷达设备质量要求的提高，对于雷达软件的要求也越来越高，雷达软件的安全性和可靠性也呈现越来越重要的趋势。在软件的生命周期内，软件测试是必不可少的一个重要环节，通过软件测试，才能充分排除和修正软件设计以及开发过程中的不合理、不可靠因素。

1 静态测试

静态测试是对软件的源代码进行分析研究，以验证程序语法、结构、编码规则等方面的准确性。静态测试可通过手动进行，也可通过测试工具进行分析。对于雷达软件来说，源代码量巨大，人工代码审查的效率较低，因此引入代码审查测试工具尤为重要，在雷达软件代码审查过程中测试工具的使用大大降低了测试时间，节约了测试成本，本文主要针对静态测试工具Logiscope在雷达软件测试中的应用进行简单介绍[1]。

2 Logiscope简介

Logiscope贯穿于软件开发、代码审查、单元测试、系统测试以及软件维护的各个阶段，是面向源代码的测试工具，并且主要适用于软件测试阶段，包括静态测试阶段的代码审查和动态覆盖测试，它可从软件的编程规则、静态特征和动态测试等多个方面量化质量模型，评估软件质量。

Logiscope主要有3个功能模块，包括RuleChecker：自动化的编码规范检查、Audit（QualityChecker）：质量评估和图形化代码视图、TestChecker：基于结构的测试与动态覆盖率测试。

2.1 Rulechecker（編码规范检测）

Rulechecker是代码白盒测试的分析工具，用于检验代码书写的规范性，在代码审查中可使用该工具将代码与已有标准或规范比较，将编码习惯标准化，从而改进代码的可读性、可维护性，使软件资源的使用更加有效，更有活力。

Rulechecker提供了根据业界标准和经验所制定的编码规则与命名检验，从而避免了开发人员因为自我不良的编程习惯所导致的彼此不相容的困扰。同时Rulechecker还提供了规则的裁剪和编辑功能，用户可使用TCL脚本和编程语言自定义新的规则。

2.2 Audit（质量分析）

Audit用于审查代码的质量，主要包括以下功能：①检查代码错误，定位错误模块;②根据质量模型评估软件质量和软件复杂度;③图形化整个软件的框架结构以及模块调用图和控制流图;④自动生成评估报告。

2.3 Testchecker（动态测试分析）

Testchecker是统计被测试程序测试覆盖率的工具，重点统计的覆盖率是边覆盖率，也称之为判定到判定的覆盖[2]。

3 Logiscope工作原理

本章节针对Rulechecker、Audit和Testchecker的工作原理进行介绍。

3.1 Rulechecker工作原理

RuleChecker实现了一个编码规范集，在该编码集中大部分编码规范可以自定义，因此大大增加了编码检测的灵活性，使RuleChecker可以更好地适应实际工作需求。在具体的测试过程中，首先进行编码规范文件的选择，Rulechecker向用户提供了‘RuleChecker.cfg的编码规范描述文件，此外用户也可使用TCL语言修改或重新编写.cfg文件，来适应具体情况。

TCL（Tool Command Language）是一种解释执行的脚本语言（Scripting Language）。 它提供了通用的编程能力：支持变量、过程和控制结构;同时TCL还拥有一个功能强大的固有核心命令集。用户可以针对某一特定应用领域对TCL语言的核心命令集进行扩展，加入适合于自己的应用领域的扩展命令。并且，扩展后的TCL语言将可以继承TCL 核心部分的所有功能，包括核心命令、控制结构、数据类型、对过程的支持等。

3.2 Audit工作原理

Audit是按照ISO9126质量模型分层、量化的方式进行静态测试。其内部定义了大量的质量度量元，度量元是检验一个软件质量好坏的最基本元素。Audit通过文本文件定义质量模型，通常Audit会提供质量模型文件，其位置在“LogiscopeHOME/Logiscope/Ref/Logiscope.ref”，在该质量模型中定义了四个质量标准，分别是：易于分析性（ANALYZABILITY）、易于测试性（TESTABILITY）、稳定性（STABILITY）和适应变化性（CHANGEABILITY）。对于最底层的质量度量元，该模型文件从Audit的度量元中选择几十个度量元构成基本度量元，比如函数语句数度量元（lc_stat）、类公共数据成员数度量元（cl_data_publ），等等。这些度量元都被量化为数字，当某一度量元超出设定的上限值和下限值范围时，Audit就认为被检测的代码在该项度量元上不符合要求。质量标准在Audit中也被量化为数字，由若干个度量元按权重相加组成的。通过质量标准值的大小，Audit给出程序代码遵守该项质量标准的级别，由高到低依次是EXCELLENT（优秀）、GOOD（良好）、FAIR（合格）、POOR（不合格）。Audit中评价函数稳定性的质量标准计算方法如下：

该公式中表明function_STABILITY由函数与其他类耦合度度量元（ic_varpe） 、函数出口数量度量元（ct_exit）、函数中调用其他函数数量度量元（dc_calls）、函数参数数量度量元（ic_param）这四个度量元组成，每个度量元的权重均为1。可根据具体的得分，判定程序代码在该项质量标准上所处的等级。这就是Audit对质量模型中质量准则级的处理方法。

综合四个不同的质量标准，可以得到代码的可维护性质量因素，具体计算公式如下：

上述公式表明，函数的可维护性由四个质量标准的得分相加得出，通过层层综合，得到了可维护性质量因素的结果。

3.3 Testchecker工作原理

Testchecker运行过程中会在程序源代码的控制流转移语句中插入标志位，在执行测试用例时，若运行至此标志位，Testchecker会在后台记录，进而统计出每个测试用例的覆盖率，以及多个测试用例覆盖率总和。

4 Logiscope应用实例

本文针对一个雷达软件，使用Logiscope工具TCL自定义编码规则，来进行雷达软件的编码规则检查。

（1）针对新建好的Logiscope项目，根据需要对编码规则进行修改，本实例中，选取以下八条编码规则进行自定义。

①Ansi，函数参数列表不能为空，函数参数列表中参数应指定类型

②Asscal，在函数的参数列表中不要使用赋值操作符。

③Brkcont，在控制语句 （for， do， while） 块中，禁止使用Break和continue。

④Globinit，全局变量必须在定义的时候赋予初始值。

⑤MISRA_0_1_1，項目中不应包含不能到达的代码。

⑥MISRA_0_1_3，项目中不应定义未被使用的变量。

⑦MISRA_0_1_4，项目中不应包含只使用一次的全局变量。

⑧MISRA_6_4_8，每个switch语句应该至少有一个case语句。

（2）编译完成后，运行RuleChecker，生成测试报告，选择Browse-Rule-Rule Violations Report或者Logiscope单元栏上Rule Violations Report按钮，查看规则违背情况报告。报告是以网页的形式提供的，方便测试人员查看。报告主要是由两部分组成，第一部分是以源文件为单位和以编码规则为单位，将检测结果以列表的形式展示出来，第二部分，给出了编码规范的详细说明，如下图1所示。

（3）点击详细信息进行查看，发现以上报告说明改该项目存在以下几个方面的缺陷：filter.cpp违反了“MISRA_0_1_1，项目中不应包含不能到达的代码”的规则;auto.cpp文件中1173行、1175行、1320行违反了“MISRA_0_1_3，项目中不应定义未被使用的变量”;kalman.cpp文件中的315行、316行、319行违反了“MISRA_0_1_4，项目中不应包含只使用一次的全局变量”;Kalman.cpp文件中的11行、25行、34行等违反了“Ansi，函数参数列表不能为空，函数参数列表中参数应指定类型”规则。

根据RuleChecker的检测结果，选择源程序进行修改，重新编译之后，再次生成统计报告，会发现原来违反规则的地方都已经修改完成。

5 结束语

Logiscope在针对要求高可靠性和高安全性的雷达软件测试中有着非常重要及有效的应用，可对雷达软件进行质量分析和测试以保证雷达软件的质量，并在后期雷达软件的维护过程中大大提高效率，但是Audit的分析结果比较依赖底层函数度量元，若底层度量元不可测时，将会导致上层函数标准级也不具备可测性。Rulechecker在针对雷达软件进行代码规则检查时，能够方便有效的将源代码中不符合编码规范的部分准确定位，这大大提高了测试人员代码审查的效率，同时Logiscope中可自定义规范集，可针对雷达软件定制规则集来约束设计人员的编码习惯，这对后期雷达软件编码规范化及代码可维护性、可读性方面有着积极的推动作用。

参考文献

[1] 杜庆峰.高级软件测试技术[M] . 北京：清华大学出版社，2011：73.

[2] 梅磊，石晓宁.军用软件探索式测试方法的研究[J].电子质量， 2016，（2）：5-10.