Original article published on 22:35:43
In the previous article Article We introduced For example, we will reveal the issues of requirement coverage, statement coverage, and conditional coverage of branch coverage. In this article, we will mainly explain why we should try every means to find "test coverage ". (For more information about the previous article, see Test Coverage Rate-test coverage rate Classification )
The most important thing about test coverage should be the test stop standard. In the test stop standard, such a statement "the test coverage rate reaches or exceeds 95%" is often used. In fact, if you read the test coverage classification mentioned in my previous article, you will know that this is an inaccurate description. For a more accurate description, I think it should be" Performance Testing The requirement coverage rate reaches 100%, the functional requirement test coverage rate reaches 100%, and the statement coverage rate reaches 85%. "Test Coverage" originally contains many sub-parts, so it is unwise to raise the test coverage rate. The statement coverage rate 85% I mentioned is more difficult to obtain accurate values than the performance test requirement coverage rate data. However, many tools are available to test the statement coverage rate ", instead of having to compute the executed test cases, we can cover tens of thousands or more.Code There are also some tools to help us get the "branch coverage" in code coverage. Others Data. I will introduce the coverage detection tool in subsequent articles in this series.
Test Coverage is part of the test end standard, which is clearly not the focus of our discussion today-what is the purpose of test coverage? Intuitively, we can understand it as follows:
-> If the performance test coverage rate does not reach 100%, it indicates that some of our performance test points are not covered, which is obviously unavailable in a system that requires performance, this means that we should add use cases to cover the required performance test points.
-> Statement coverage and condition coverage of important modules are very low, which means that we have too few test cases. We should add use cases. If we have already written many use cases (compared to the number of lines of code ), however, the two data items are still very low. We have to check whether there are repeated use cases? Should I redesign the use case structure?
We have a simple formula for testing coverage. If the conditional coverage rate of module A is 80%, Module B is 80%, and Module C is 80%, then our total coverage rate is 51.2%, rather than 80%. I will not explain why. Therefore, when we review the coverage report, we focus on the modules with low coverage. We need to check why it is low, how to improve it, and where it is low, is there an equivalence class we ignored?
The significance of the test coverage rate may not be so important in the waterfall development mode, but if we do not control the test coverage rate in the previous iteration in the spiral development mode, when a version or version is accumulated, it is difficult for you to determine which modules have not been tested in the development process. In the recent wave of continuous integration, because short iterations are required (one iteration is recommended for 3-5 days), it is difficult to ensure the quality of testing in such a fast code change without good test coverage guarantee. Continuous Integration Work The code is frequently submitted. We can use the test coverage rate to quickly correspond to newly written code without corresponding testing code.
In short, the test coverage rate can be provided to us in two aspects: the test coverage rate of the modules with low test coverage and important modules. These data can help us quickly locate the modules that require more tests and help us understand the testing status of important modules to measure the quality of our test cases and even the testing quality.
Personal opinion, for reference only ~~ (If you have any questions, please contact unique.wuchaodong@hotmail.com) in the next article ( Test Coverage rate 3-problems related to test coverage rate 100% ), I will introduce the data about the test coverage rate to be achieved. Does it need 100%? Test Coverage