About the code coverage of the search _ Software Testing

Introduction code coverage is a measure of the project source code is tested an indicator, some people think this is a very useful standard, the higher the Code coverage may represent a higher and more secure quality assurance; Some people are skeptical about code coverage, although admitting coverage is a standard for testing quality, 　　However, it is not necessarily believed that the covered code is well tested, and some people think that code coverage is useless in the project or even harmful to the project, with a high code coverage and a poor actual quality of the project, providing a false sense of security to the project members. Although the code coverage is divided into many types (function coverage, statement coverage, judgment coverage, etc.), the small series after a period of practice, or decided to focus on the statement coverage, because it is relatively simple, rules easy to make, the results of convenient visualization. 　　 This article will do some exploratory discussion on statement coverage. The measurement of code coverage for most of the projects contacted by the small, most of the project is in the form of continuous integration, through continuous integration tools for automated construction (including compilation, release, automated testing) to verify, so as soon as possible to discover integration errors. Many teams find that this process can greatly reduce integration problems and allow the team to develop cohesive software faster. 　　The current project also uses Jenkins plus coverage tools such as Gcov (C + +), Emma/jacoco (Java), and coverage.py (Python) to compute the test coverage of the source code. 　　The timing of execution of code coverage can be divided into two types: daily execution and every build execution, both independent and simultaneous. For tasks that are performed daily, you can configure a scheduled task, each execution of which is the entire project's source code. By executing the generated data from the tool, you can create dashboard to display code coverage data for daily/weekly/quarterly/yearly/per-language. 　　The dashboard can also be implemented to compare the project to the project to assess the quality of each objective. For each build task, you can hook up the task to the code review process, execute the code review process, and then perform a visual feedback of the results to the submitting engineer and review each time the build is triggered. 　　As shown in the following figure, you can design a certain color for the code review, for example, green for the new code, lines of orange pink for the test has been covered by the code, more convenient for review students to watch. 　　 Based on the experience of the small series, it is an important time to perform and feedback code coverage scans prior to submission, since it is time for the developer to be interested in the data, and the likelihood of other opportunities for research and development to increase coverage will be greatly reduced. Code Coverage results display small series collected 3Project, 5 languages, n commit code coverage data, after the statistics we found that most of the project coverage is between 40%-70%, where the Python language write the highest coverage of the project, JavaScript second, the lowest for C + +. It is analyzed that the possibility of various language coverage differences is related to the structure, paradigm and difficulty of writing, and the accuracy of code coverage data may also be affected by different measuring tools. 　　Note, however, that the above data is not enough to be used as an indicator of common project code coverage, and that this data only provides a certain amount of data reference for later promotion of code coverage. By deploying a continuous build + code Coverage scanning system, we continue to receive positive feedback from our team, with the highest praise being the ability to add coverage statistics to the code review process, which has been beneficial in increasing the focus and efficiency of the Code review, 　　It also indirectly increases the code-tested coverage (review is also a way to increase code coverage). The next work after a period of practice we found that the problem of code coverage is mainly in the Code coverage tool, because the tools of different algorithms, it is difficult to develop a unified standard. 　　Our further work may be to chew on the source code of these tools and to continuously improve the accuracy of coverage statistics through a practice-feedback-corrected loop. 　　Another problem is the coverage statistics mentioned above, most exist at the unit and interface level of testing, for large-scale integration testing, End-to-end testing, UI testing, such coverage is difficult to measure, so the current test is still dependent on the use case coverage of the control. I hope this article can play a role in your reader project, although all walks of life to the code coverage of different views, but small series firmly believe that the code coverage of the continuous improvement of the overall quality of the project has a better positive effect. If you have any questions, welcome to add QQ Group Test introduction Great God 755431660 study together ~