Shulou(Shulou.com)06/03 Report--

I would like to share with you an example analysis of unit test code coverage in a programming language. I believe most people don't know much about it, so share this article for your reference. I hope you will learn a lot after reading this article. let's learn about it!

First, let's take a look at the so-called "code coverage". I found the so-called definition:

Code coverage = code coverage, a measure.

The short and pithy text above describes the meaning of code coverage very accurately. There are many ways to measure code coverage. Here are some of the most commonly used ones:

1. Statement override (StatementCoverage)

Also known as line coverage (LineCoverage), segment coverage (SegmentCoverage), basic block coverage (BasicBlockCoverage), which is the most common and most common way of coverage, is to measure whether each executable statement in the code under test has been executed. We're talking about "executable statements", so it doesn't include header file declarations like C++, code comments, blank lines, and so on. It's easy to understand that only how many lines of code that can be executed are counted.

It is important to note that curly braces {} on a single line are often counted as well. Statement coverage is often criticized as the "weakest coverage". It only covers the execution statements in the code, but does not consider the combination of various branches, and so on.

If your boss only requires you to achieve sentence coverage, then you can save a lot of effort, but the test effect is not obvious, it is difficult to find more problems in the code.

To give an example that can't be simpler, let's look at the following code being tested:

Int foo (int a, int b) {return a / b;}

Suppose our tester writes the following test case:

TeseCase: a = 10, b = 5

The tester's test results will tell you that his code coverage has reached 100%, and all the test cases have passed. Unfortunately, our statement coverage reaches the so-called 100%, but we don't find the simplest Bug. For example, when I let bicon0, I throw a zero division exception.

Because of this, if the above only requires testers to achieve sentence coverage, testers can easily meet the supervisor's requirements as long as they exploit loopholes and write test cases specifically on how to cover lines of code. Of course, this illustrates several things at the same time:

1. It is problematic for supervisors to use only statement coverage to assess the testers themselves.

two。 The tester's goal is to test the code, and it is unethical to exploit such loopholes.

3. Should a better assessment method be adopted to assess the work of testers?

In order to find better assessment criteria, we must first understand what the code coverage is. If your supervisor only knows sentence coverage and line coverage, then you should take the initiative to introduce him to more coverage methods. For example:

two。 Decision overlay (DecisionCoverage)

Also known as branch coverage (BranchCoverage), all boundary coverage (All-EdgesCoverage), basic path coverage (BasicPathCoverage), decision path coverage (Decision-Decision-Path). It measures whether each branch of the program has been tested. This sentence needs to be further understood and should be easily confused with the conditional coverage mentioned below. So let's introduce the third coverage directly and compare it with the decision coverage to see what's going on between the two.

3. Conditional coverage (ConditionCoverage)

It measures whether the results of each subexpression in the decision, true and false, have been tested. To illustrate the difference between decision coverage and conditional coverage, let's give an example if our tested code is as follows:

Int foo (int a, int b) {if (a < 10 | | b < 10) / / decide {return 0; / / Branch 1} else {return 1; / / Branch 2}}

When designing a decision coverage case, we only need to consider two cases where the decision result is true and false. Therefore, we can design the following cases to achieve 100% decision coverage:

TestCaes1: a = 5, b = any number covers the branch-TestCaes2: a = 15, b = 15 covers the branch two

When designing a conditional coverage case, we need to consider the result of each conditional expression in the decision. In order to achieve 100% coverage, we have designed the following case:

TestCase1: a = 5, b = 5 true, trueTestCase4: a = 15, b = 15 false, false

From the above example, we should be very clear about the difference between decision coverage and conditional coverage. It is important to note that conditional coverage does not arrange and combine the results of each conditional expression in the decision, but OK as long as the results of each conditional expression are tested by true and false. Therefore, we can infer that complete conditional coverage does not guarantee complete decision coverage. For example, in the above example, if the case I designed is:

TestCase1: a = 5, b = 15 true, false branch-TestCase1: a = 15, b = 5 false, true branch-

We see that although we have achieved a complete conditional coverage, we have not achieved a complete decision coverage, we have only covered branch one. As can be seen from the above example, neither of these two kinds of coverage seems to be good. Let's take a look at the fourth type of coverage.

4. Path coverage (PathCoverage)

Also known as assertion coverage (PredicateCoverage). It measures whether every branch of the function is executed. This sentence is also very easy to understand, that is, all possible branches are executed once, when there are multiple branches nested, multiple branches need to be arranged and combined, it is conceivable that the test path increases exponentially with the number of branches. For example, there are two decision branches in the following test code:

Int foo (int a, int b) {int nReturn = 0; if (a < 10) {/ / Branch-nReturn + = 1;} if (b < 10) {/ / Branch two nReturn + = 10;} return nReturn;}

For the above code, we design test cases for our first three coverage methods:

a. Statement coverage

TestCase a = 5, b = 5 nReturn = 11

Statement coverage 100%

b. Decision coverage

TestCase1 a = 5, b = 5 nReturn = 11TestCase2 a = 15, b = 15 nReturn = 0

Decision coverage 100%

c. Conditional coverage

TestCase1 a = 5, b = 15 nReturn = 1TestCase2 a = 15, b = 5 nReturn = 10

Conditional coverage 100%

As we can see, the above three coverage rates all look cool! All reached 100%! The supervisor may be very happy, but let's take a closer look. In the code under test above, there are four possible return values for the result of nReturn: 0mem1, 10 and 11, while the test case we designed for each coverage only covers part of the return value. Therefore, it can be said that using any of the above coverage methods, although the coverage has reached 100%, the test has not been completely tested. Next, let's take a look at the test cases designed for path coverage:

TestCase1 a = 5, b = 5 nReturn = 0TestCase2 a = 15, b = 5 nReturn = 1TestCase3 a = 5, b = 15 nReturn = 10TestCase4 a = 15, b = 15 nReturn = 11

Path coverage 100%

great! The path coverage tests all possible return values. This is why it is considered by many to be the "strongest coverage".

There are other forms of coverage, such as loop coverage (LoopCoverage), which measures whether zero, one, and more than one loop is performed on the body of the loop. The rest of the other coverage methods will not be introduced.

These are all the contents of the article "sample Analysis of Unit Test Code coverage in programming languages". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.