The previous article wrote about the installation and use of SonarQube8.6. This article briefly explains the basic use of SonarQube and some indicators.
Menu and home page description
- Item: The scanned item Problem: The scanned item problem
- Code rules: Code inspection rules
- Quality configuration: Quality configuration is a collection of rules used in analysis. Certain rules can be enabled or disabled.
- Quality threshold: normal/error. You can specify some indicator conditions as an error, such as an error when the number of bugs is greater than a certain value.
- Configuration: permissions, users, etc. configuration
- + Sign: new item
Project overview and statistics
1. Indicator description: Generally, the indicator description will be displayed by placing the mouse on the icon.
2.
Bugs: the number of bugs 3. Vulnerabilities: the number of vulnerabilities
4. Odor: the number of irregular codes
5. Coverage: unit test Coverage of the code
6. Repeat: the proportion of the number of repeated code lines to the total number of code lines
7. Size: the number of code lines
8. Programming language: the programming language for project testing
9. Level description: 5 levels from ABCDE, from A From green to E to red indicate severity
Project overview
Description:
1. Support branch detection
2. Display the main index situation
3. Display the detection configuration information of the project
Question overview
Description:
1. Type: The type defined by a rule, there are 4 types: bug, loophole, odor, security hotspots individually
2. Severity: There are 5 types: blocking, serious, important, minor, prompt
3. Status: 5 Type: open, solve, reopen, close, confirm
4. Person in charge: who is assigned to
5. Estimated repair time: Estimated repair time given by the system
6. Comment: Can comment
index
The indicators are:
1. Reliability
Calculation method of reliability ratio)
A = 0 Bug The highest level A, which means the code has no bugs.
B = at least 1 Minor Bug. As long as the code has a minor bug, the level is B
C = at least 1 Major Bug As long as it contains a major bug, the level will be C
D = At least 1 Critical Bug As long as there is a serious bug, the grade is evaluated as D
E = at least 1 Blocker Bug As long as there is a bug with the highest blocking level, the reliability is evaluated as E, the lowest level.
The size of the bubble in the figure changes according to the number of bugs, the larger the number of bugs, the larger the bubble. The vision is more intuitive.
2. Security
Safety index calculation method
A = 0 Vulnerability When there is no vulnerability, the project is evaluated as the highest level A
B = at least 1 Minor Vulnerability As long as it contains a minor vulnerability, the project is evaluated as level B
C = at least 1 Major Vulnerability As long as it contains a major vulnerability, the project is evaluated as level C
D = at least 1 Critical Vulnerability As long as it contains a serious vulnerability, it is evaluated as D
E = at least 1 Blocker Vulnerability As long as it contains a blocking vulnerability, the project is evaluated as the lowest level
. The bubble size in the graph changes according to the number of vulnerabilities, the larger the number of vulnerabilities The bigger the bubble. Visually intuitive display.
3、Maintainability
Technical debt: Technical Debt, the current non-standard code will affect the cost of future product modifications.
Development cost: the cost of developing a line of code (LOC). Example: If the cost of developing 1 LOC is estimated to be 30 minutes, the value of this attribute is 30. Currently we are using the system default value of 30. Note that the cost here refers to the cost of rewriting the code from scratch.
Maintainability: Maintainability levels range from A (very good) to E (very poor). The rating is determined by the value of the technical debt ratio, which compares the technical debt of the project with the cost of rewriting the code from scratch. The default values from A to D are 0.05, 0.1, 0.2, 0.5. Anything over 0.5 rating is E.
For example: assuming that the development cost is 30 minutes, a project with a technical debt of 2,500 LOC of 24,000 minutes will have a technical debt ratio of 24000 / (30 * 2,500) = 0.32. Therefore, the maintainability rating of the project is D.
4. Coverage coverage
A mix of Coverage line coverage and conditional coverage. How much source code is covered by the unit test. Coverage = (CT + CF + LC)/(2*B + EL), where:
CT = conditions that have been evaluated to'true' at least once The number of
conditions that have been evaluated as true at least once CF = conditions that have been evaluated to'false' at least once The number of conditions that have been evaluated as false at least once
LC = covered lines = lines_to_cover uncovered_lines Number of lines covered
B = total number of conditions
EL = total number of executable lines (lines_to_cover) Total number of executable lines of code
Line coverage
5. Unit test coverage line number density
Line coverage = LC / EL
LC = covered lines (lines_to_cover-uncovered_lines)
Number of lines covered EL = total number of executable lines (lines_to_cover) Total number of executable lines of code
Condition coverage
Condition Coverage=（CT+CF）/(2*B)
CT = the number of conditions that
use'true' at least once CF = the number of conditions that use'false' at least once
B = the total number of conditions
Unit test success density (%)
Test success density = (total unit tests-(unit test errors + unit test failures)) / unit tests * 100
6. Duplications
Duplication
SonarQube uses its own copy/paste detection engine, which can detect duplicates:
In the source file,
across multiple files in the
project, each module of the project,
across multiple projects
Duplicated Lines(%)
Repeat rate = number of repeated rows / total number of rows * 100
Duplicated blocks: Number of repeated code block lines
Duplicated files: Number of repeated files
Duplicated lines: Number of repeated lines
Size
7. Complexity
The following keywords add complexity: if, for, while, case, catch, throw, return (not the last statement of the method), &&, ||,?
else, default, finally does not increase complexity
Too much code complexity will be difficult to understand and difficult to maintain.
8. Issues
New Violation
Violation
Open the problem
Reopen the problem
Confirm the problem
Misjudgment problem The problem that is
not repaired
Configuration
Permissions apply permission templates to grant and revoke project-level permissions. Permissions can be granted to groups or individual users
Problem finding
Troubleshooting varies from project team to project team, and changes are made according to different rules.
Example:
an obvious bug problem. .
At this point, the approximate analysis is over, welcome guidance. .