[Zz] a preliminary understanding of the value of code coverage

AboutCodeCoverage rate, which has been barely heard of in the past six years. I have never paid attention to this indicator in my previous organization. I just used nunit for unit testing for some time, mainly to test whether some key methods are normal, the impression of code coverage has always been on the page. Khan!

Some time ago, some people mentioned code coverage in the discussion about automated testing, which aroused my curiosity. What is code coverage? What is the most important value for testing? Today, I spent some time investigating and getting a preliminary understanding. It is roughly summarized as follows:

I. Basic Concepts

Code coverage is one of the unit test activity tasks;

Coverage is divided into statement coverage (that is, the row coverage) and branch coverage.

II. Value

Code coverage analysis can judge code quality to a certain extent. Generally, code errors with high coverage are less likely. However, the high coverage rate only indicates that a lot of code is executed, which does not mean that the code is executed well. Therefore, it seems that the coverage test results do not help me evaluate the code quality accurately. So why do we need to test coverage? How can we bring value to us?

1. Evaluate the code quality as soon as possible.

For example, during the development process, you can regularly check the code coverage of the entire project. The monitoring coverage report can help the development team quickly find the growing but not tested code. For example, when a coverage report is run at the beginning of a week, the coverage rate of a key software package in the project is 70%. If the coverage rate drops to 60% in a few days, you can infer that the code line of the software package has increased, however, no tests are written for the new Code (or the newly added test cannot effectively overwrite the new Code ). It is undoubtedly a good thing to be able to monitor the development of things. Regular access to reports makes it easier to set goals (for example, to obtain coverage, to maintain the ratio of test cases in the code line) and monitor things. If you find that the test is not written as scheduled, you can take some actions in advance, such as training, guiding, or helping developers.
2. provide intelligence for functional testing considerations

If the coverage report is very effective in identifying the code that has not been tested, the QA personnel can use the data to assess the areas of interest related to functional testing, tests in these areas can be enhanced in a more targeted manner, because the areas not covered by the test code have a higher chance of errors.

3. Estimated time required to modify existing code
For a development team, writing test cases for code can naturally increase the collective confidence. Compared with codes without corresponding test cases, tested codes are easier to refactor, maintain, and enhance. The test case implies how the code works in the test, so it can also act as an expert document. On the other hand, it is more difficult to understand and modify the code that has not passed the test. Therefore, knowing whether the code has been tested and looking at the actual test coverage value allows developers and managers to more accurately predict the time required to modify the existing code.

-----

Of course, this understanding is still relatively simple. I think in addition to the above three points, another important task is to improve the quality of the test code to better reflect the value of code coverage.

Source: http://www.51testing.com /? Uid-101957-action-viewspace-itemid-70695