Test Coverage rate 3-topics related to test coverage rate 100%

Original article published on 21:39:48

In the previous article . Test Coverage rate can help us check test quality and test case efficiency. If you are interested, read Test Coverage 2-what is the purpose of test coverage?

I personally think that the test coverage rate is more and less useful. I recently saw an article on the Internet discussing the question "does the test require 100% coverage ?" QuiltReprintedMany times, interested peers can look for it. Indeed, when we think of test coverage, there will immediately be perfectionists jumping out to say 100%. What are the advantages of 100% testing coverage?
1,100% coverage indicates that our test overwrites all statements, branches, and conditions.
The 2,100% coverage rate indicates that we have considered the test completely. We can go back to sleep ~~
The test seems to be less predictable here, but we have missed at least two important points: how to reach 100% of the test coverage rate or whether it can reach 100% of the test coverage rate, the other is what the 100% test coverage rate can tell us.
First, can we achieve a 100% test coverage rate? If we simply understand the test coverage rate as requirement coverage rate and code coverage rate, I think this can be achieved. As long as we have enough time, our test covers every requirement point, our test covers every statement, every condition, and every branch. It seems that there is no problem. However, we also need to consider another question: Is it because we have not included the requirements in the demand analysis? This situation exists, if we calculate the requirement coverage rate based on feature SPEC (in fact, if we need to calculate it, it is generally calculated in this way ), so when we have the need not to write the feature spec and we have not considered the relevant tests in the test, then our actual "requirement coverage" is not 100%. In the actual development process, it is impossible to list all the requirements in the feature spec. Therefore, the 100% requirement coverage rate we get has moisture.
In addition, for an application (except some extremely simple programs), it is necessary to overwrite all the statements. Conditions and branches are extremely difficult, or even impossible. I spent a whole day writing a module in a projectUnit TestAfter I have been busy for a day and run all the use cases, I found that my code coverage only increased by 2%, from 35% to 37%, not to mention 100%, even 80% I thought it was a luxury.
For the second question, what does the 100% test coverage rate mean? As mentioned above, 100% of the test coverage rate indicates that all statements, branches, and conditions are covered. What does this mean? Does this mean that we have completely tested a software? Sorry, the answer is no. The following code is provided:

Private int add (int A, int B)
{
Return A + B;
}

A piece of code is simple enough. We can easily reach 100% coverage. For example, we can overwrite all statements and branches by using the add (3, 4) case, condition (of course, there is no branch or condition here, so you only need to overwrite the statement to reach the code coverage rate of 100%), but you will surely find that our test is far from enough: if the input is add (2147483647,2), this application will be faulty. If we only meet the code coverage rate of 100%, we cannot guarantee the quality of our software.
There is an interesting phenomenon about code coverage: high coverage is sometimes "useless" than low coverage ". Note that "useless" is enclosed in quotation marks. I mean, high coverage does not mean that we have conducted a complete test. Low coverage does not mean that our test is far from enough. In this regard, low Coverage seems more meaningful. Of course, I am not talking about how to pursue high coverage. I mean, instead of increasing the coverage rate of module A from 85% to 90%, it is better to increase the coverage of Modules B from 30% to 50%. In a large circle, the high coverage rate is better than the low coverage rate at any time, but as a software, we have to consider the overall testing quality of the software, and we have to estimate the cost, time, and many other issues.
I have mentioned a lot above, And I will summarize my points at last:
1. testing coverage of 100% is an ideal situation and is hard to achieve;
2. The test coverage rate of 100% does not indicate that we have performed a complete test;
3. The low test coverage rate indicates that our test is not enough. Otherwise, the test is not valid. Refer to article 2;
4. Compared with low coverage, the high coverage rate of the same module indicates that more tests are conducted;
5. The overall software coverage and project costs, including manpower and time, should be taken into account for the test coverage rate.

Personal opinion, for reference only. If you have questions or comments, please contact your unique.wuchaodong@hotmail.com or leave a message directly ~
The discussion on the 100% test coverage rate will continue. If necessary, I will continue to summarize the issues later in this series of articles. According to the plan, in the next article (test coverage rate 4-Test Coverage Rate tool), I will introduce the tools I have used and the tools I have not used but can find relevant information online, let's take a look at it.TestCoverage