5 common software quality indicators

In software development, software quality is an important embodiment of measuring whether the software meets requirements and standards. In addition to code quality, there are many factors that affect the overall quality of software. Therefore, to ensure the overall quality of the software, it is necessary to strictly control all links.

This article lists the five most common metrics for measuring software quality.

1. SLOC (Source Lines of Code, Source Code line)

Calculating the number of lines of code may be the simplest indicator, which mainly reflects the scale of the software and provides relevant data for project growth and planning. For example, if you calculate the number of lines of code once a month, you can draw a project development overview diagram. Of course, due to factors such as project reconstruction or design stage, this method is not very reliable, but it can provide a perspective for the development of the project.

You can only count the Logical Line of Code (SLLOC) to obtain slightly accurate information. The logical code line does not contain empty lines, single parenthesis lines, and comment lines. You can use Metrics to collect statistics.

The number of lines of code should not be used to evaluate developers' efficiency. Otherwise, duplicate, unmaintainable, or unprofessional code may be generated.

2. Number of bugs in each code segment/module/time period

To achieve better testing and higher maintainability, bug tracking is essential. Bugs in each code segment, module, or time period (days, weeks, or months) can be easily measured by tools (such as Mantis ). In this way, you can discover and repair the problem as soon as possible.

The number of bugs can be used as an indicator to evaluate developers' efficiency. However, you must note that software developers and testers may become enemies if you emphasize this evaluation method too much. In production enterprises, efforts should be made to ensure the cohesion between employees.

For better implementation and evaluation, bugs can be divided into low, medium, and high levels based on the importance and resolution costs.

3. code coverage

In the unit test stage, code coverage is often used as an indicator to measure the test quality and to assess the test task completion. There are many tools available, such as Cobertura.

Code coverage does not represent the overall quality of unit tests, but it can provide information about test coverage and can be used with other test indicators.

In addition, pay attention to unit test code, integration test scenario and result when viewing code coverage.

4. Design/Development Constraints

There are many design constraints and principles in software development, including:

• Class/method Length
• Number of methods/attributes in a class
• Number of methods/constructor Parameters
• Use of magic numbers and strings in code files (magic numbers refer to specific values directly written in the code, which is hard for others to understand)
• Comment row proportion, etc.

The maintainability and readability of the Code are very important. The development team can choose one or all of the above principles and use some automation tools (such as Maven
To follow these principles, which will greatly improve the quality of software products.

5. cyclomatic complexity)

Circle complexity is used to measure the complexity of a module's judgment structure. It has become an important criterion for evaluating software quality and can help developers identify modules that are difficult to test and maintain, balance costs, progress, and performance. Sphere complexity can be automatically calculated using the PMD tool.

The number of independent paths indicates the number of independent paths, that is, the minimum number of paths required for testing to prevent errors reasonably. The large complexity indicates that the program code may be of low quality and difficult to test and maintain.

Formula: V (G) = E-N + 2 P

E: edge, representing the program stream between nodes;
N: node, minimum unit of code in the program
P: egress Node

There are eight sides and seven nodes in total, so the complexity of the circle is 8-7 + 2*1 = 3. This means that in theory, three test cases need to be written to cover all the judgment conditions.

In fact, there is a more intuitive way to calculate the complexity of the circle, because the complexity of the circle reflects the number of "judgment conditions", so the complexity of the circle is actually equal to the number of judgment nodes plus 1, that is, the number of regions in the control flow chart. The calculation formula is as follows: V (G) = number of regions = number of decision nodes + 1.

In project development, you can define the maximum number (6, 8, or 10) based on the project type ).

The above are the five most commonly used software quality metrics. Of course, you can also have a clearer understanding of the project based on other metrics.