Test mechanism of static test tool logiscope

Test mechanism of static test tool logiscope

Author: Unknown Article Source: Network clicks: updated on:

1 Preface
This article describes the test mechanism of the static test tool logiscope. By understanding the logiscope test mechanism, we can better use this tool.
By reading this article, you can learn the following information:
How does logiscope analyze the quality of software products;
How does logiscope detect code encoding standards;
How does logiscope calculate the test coverage rate;
2 logiscope Overview
Logiscope has three main functions:
Software Quality Analysis Tool-audit;
Code compliance check tool-rulechecker;
Test Coverage statistical tool-testchecker.
Audit and rulechecker provide the software's static analysis function, and testchecker provides the test coverage rate statistics function.

Logiscope can analyze Code implemented in multiple languages, such as C, C ++, Java, and Ada. The following content is basically irrelevant to the specific language. However, if the specific language is involved in some places, I will take C ++ as an example.
Next, I will introduce the testing mechanisms of audit, rulechecker, and testchecker.
3 Audit test mechanism
3.1 software quality model
As mentioned above, audit reviews the quality of program code. To discuss the quality of the code, you must first describe the concept of the software quality model, because understanding the following content requires the knowledge of the software quality model.
If you have previously learned about software quality assurance, you should be impressed with the concept of software quality model. To illustrate the testing mechanism of audit, we will only give a brief introduction to the software quality model. If you are unfamiliar with the concept of software quality model, you are advised to find a book about software engineering and read the content of software quality assurance.
The software quality model is a layered structure. Its general form is shown in
The figure shows that the quality factor is at the highest level in the quality model. Software quality factors include functionality, reliability, usability, efficiency, maintainability, and portability (detailed descriptions in ISO/IEC 9126 ).
The quality factors are further subdivided into multiple quality standards.
Each quality standard is composed of multiple quality metrics. These quality metrics are at the bottom of the Quality Model hierarchy.
Quality Factors and quality standards are generally fixed, but the quality metrics are not fixed and can be changed according to different situations.
The software quality model is a process model that covers program information from the bottom layer to the top, from details to generalization. It starts with simple and measurable data, and finally analyzes and summarizes software features.
3.2 audit implementation of the software quality model
We have learned the general structure of the software quality model above. Audit also reviews the code quality in this hierarchical and quantitative way.
Audit uses a text file to define the quality model. In the process of creating an audit detection project for the tested code, one step is to require "choose a quality". This is to require us to set a quality model, which is the default one, audit provides a quality model file, which is located in "logiscopehome/logiscope/Ref/logiscope. ref ". Open this file in Notepad. We can see that the file first defines several metric elements and sets a numerical range for these metric elements, then a quality standard is formed by combining several metric elements, and finally a final quality factor is formed by combining quality standards. This process exactly corresponds to the structure from the bottom layer to the top layer, from detail to generalization in the software quality model.
Apart from the quality model file provided by audit, we can certainly define our own quality model files (99% of the cases require us to develop quality model files that meet our needs ), as long as the logiscope. the format of the ref file.
For convenience, we will discuss the quality model file provided by audit to explain how audit implements the software quality model.
Corresponding to the Quality Factor Level in the quality model, the default quality model file provided by logiscript implements the Software maintainability, and this file is used, you can use audit to evaluate the Software maintainability level.
At the quality standard level, four quality standards are defined in the quality model file: analyzability, testability, and stability) and changeability ).
For the lowest-level quality measurement element in the software quality model, the quality model file selects dozens of measurement elements from the measurement elements provided by audit to form the basic measurement element, for example, the number of function statements, lc_stat, and cl_data_publ.
How can the specific analysis results of each layer be obtained? We explain the order of quality metrics, quality standards, and quality factors from bottom to height.
Audit defines a large number of quality metrics, which are the most basic elements to test the quality of a software. In this default quality model file provided by logiscope, the selected metrics provide services for the final evaluation of maintainability. By observing the logiscope. Ref quality model file, you will find that metrics can be quantified as numbers, allowing us to set the upper and lower limits for each measurement element in the quality model file. When a certain amount of metadata exceeds the upper and lower limits, audit considers the code to be tested to be inconsistent with the requirements of this metric.
The following is an example of a metric element: lc_stat measurement. This metric element indicates the number of statements that can be executed in the function. Lc_stat is useful for measuring the complexity of a function. For example, we can set its upper limit to 30 and lower limit to 0, that is, we define: the number of statements that can be executed in a function cannot exceed 30. This is how audit processes metrics in the quality model.
Through these individual metrics, we cannot determine the maintainability of the program, because it is too one-sided. Only by organizing these metrics according to certain rules can we evaluate the maintainability of the software. Observe the logiscope. in the ref quality model file, we will find that each quality standard is composed of several metric elements by adding weights, and the quality standard finally uses numbers to represent its own values. By the size of the quality standard value, audit provides the level at which the program code complies with the quality standard. There are a total of four levels, from high to bottom are excellent (excellent), good (good), fair (qualified), poor (unqualified ). The following is an example of how to calculate quality standards:
This quality standard evaluates the stability of the function. The top line is the formula for calculating the quality standard:
Function_stability = ic_varpe + ct_exit + dc_cballs + ic_param
This formula indicates that the quality standard is determined by four metric elements, ic_varpe, ct_exit, dc_cils, and ic_param. The weight of each Metric element is 1. The highest score of this quality standard is 4 points. That is, when the values of the four metrics that constitute this quality standard are within our set range, this quality standard score is 4 points, when the values of the three metric elements are within our set range, the quality standard score is 3 points, and so on. Finally, based on the specific score, you can determine the level of the program code in the quality standard. This is how audit processes the quality standards in the quality model. We can see that the quality standards are built on the basis of the quality measurement element, which is a more comprehensive level than the quality measurement element.
Finally, the maintainability quality factors of the Code are obtained by combining multiple quality standards. The maintainability factor is calculated as follows:
Function_maintainability: Component = function_analyzability
+ Function_changeability
+ Function_stability
+ Function_testability
This is the maintainability of computing functions. The top is the calculation formula, and the maintainability of the function is obtained by adding the scores of the four quality standards (the calculation method of the quality standard score has been mentioned above ). In this example, the highest score is 12 and the lowest score is 0. Finally, based on the specific score, you can determine the maintainability level of the program code (excellent, good, fair, poor ). Through comprehensive layers, we finally get the result of quality factors of maintainability.
OK. The above uses the default quality model provided by audit to describe the evaluation methods in audit from Quality Metric elements, to quality standards, and finally to quality factors. If it is our own quality model, the principles are the same.
How is the process clear? If you are still confused, it is recommended that you take a look at the content of the "logiscopehome/logiscope/Ref/logiscope. Ref" file, which will help you understand the content.
3.3 division of scopes
When we manually analyze the code of an application, we usually first view the overall situation of the application, and then analyze various classes in the application (for the Code implemented using the object-oriented language ), then, analyze the member functions in the class.
When analyzing and displaying the results of code review, audit is also divided in this form. We call it a scope, such as the Code implemented in C ++ and Java, audit has the following scopes: Application Scope, Class scope, and function scope. Through their names, you should be able to guess the content contained in each scope. The application scope is for the entire application. The class scope is for each class in the system, and the function scope is for each function in the system.
Different scopes are independent from each other, but they all follow the quality model we mentioned earlier to analyze the code.
3.4 audit code handling process
For users who use audit, the source code is input, and the analysis result of audit is output. Audit's code processing process:
Audit's code processing process
End 3.5
Now we have finished introducing the testing machine of audit.
4 rulechecker Detection Mechanism
Now we will introduce rulechecker, another tool provided by logiscope for us. Rulechecker is also a static test tool.
Let's take a look at the encoding rules in our Organization. The coding specification specifies the comments, variable names, and writing formats of the program code. The purpose is to make the code written by developers more robust and readable. The rulechecker tool also aims to help us make the code more robust and readable.
Rulechecker implements an encoding standard set. The content in this canonicalization set is similar to the content of the encoding standard defined in our Organization, but it covers a wider range, the rules are also more detailed (for details about each encoding specification in the rulechecker encoding specification set, read another article I wrote, "rulechecker encoding specification". I will not describe it here ).
There are nearly half of the encoding standards in this standardization set. We can customize the content, which greatly increases the flexibility and enables rulechecker to better adapt to our actual needs.
In the specific test process, how does the rulechecker coding specification play a role? In the process of setting up the rulechecker project for the tested code, one step is to let us "choose a configuration file". This is to let us select an encoding Specification Description file, rulechecker provides us with a name called 'ruleschecker. CFG 'Encoding Specification Description file, of course we can modify or rewrite. cfg file to meet our requirements.
The following is an example of a centralized encoding specification for rulechecker: headercom encoding specification.
The headercom encoding specification specifies the file comments of the code file. The specific content is: "the header of each code file must contain file comments, and the comments must follow a certain format ". This format can be set by us.
I now set the format of the annotation required by the headercom specification to the same format as the file annotation stipulated in the Code specification of my company. Open the rulechecker. cfg file and use the following content to replace the original content of the file headercom.
Standard headercom on
List "Header" "[file name ]"
"[Function module and purpose ]"
"[Main functions and functions ]"
"[Main algorithms ]"
"[Interface description ]"
"[Developer and date ]"
"[Version ]"
"[Change Record]" end list
List "code" "[file name ]"
"[Function module and purpose ]"
"[Main functions and functions ]"
"[Main algorithms ]"
"[Interface description ]"
"[Developer and date ]"
"[Version ]"
"[Change Record]" end list
End Standard
After this operation, save it as another file with the suffix. cfg. When you select this file when creating the rulechecker project of the tested code, rulechecker checks the file comment format of the code file in this format. If the file does not meet the requirements, it will be detected.
OK. The test mechanism of rulechecker is well understood.
5 testchecker Detection Mechanism
Now let's take a look at the testchecker, the last tool logiscope provides for us. Testchecker is used to measure the test coverage rate of the tested program. The coverage data provided by this tool is edge coverage, or the determined coverage (DDP coverage ).
Edge coverage is the coverage of the edge in the program flowchart in the test case we run. There are some unit test tools, such as truecoverage in numbench and purecoverage in rational. They can also measure the test coverage rate of the tested program, however, the coverage data they provide is the point coverage (ib coverage), or the statement coverage. The coverage intensity is lower than the edge coverage intensity.
The test mechanism of testchecker is as follows: after the testchecker project is established, the connection code is compiled through testchecker to generate an executable file. In this process, testchecker inserts some mark statements (this process is called "plug-in") into the statements involved in control flow transfer in the program source code "). Run the executable file in testchecker. When the test case is executed, testchecker runs in the background. Because the flag statement is "inserted" in the program code, during the execution of the program, testchecker can record which branches of the program have gone and which ones have not gone, then, the coverage rate of each test case and the total coverage rate of multiple test cases are calculated.
This is basically the test mechanism of testchecker.
6. Conclusion
This article describes the logiscope testing machine. Like other computer technologies, the best way to understand and master logiscope is to use logiscope to test some projects. Well, let's get started.

This article is transferred from
Http://www.testage.net/AutoTest/Others/200608/854.htm