When doing unit testing, the code coverage rate is often used as the criteria for measuring testing performance, even in some cases code coverage may be used to consider whether the testing task is completed or not. So testers need to spend much time on designing test cases which can cover as many codes as possible. There are advantages and disadvantages about using code coverage rate.
First let's check what is code coverage rate:
code coverage rate= the degree of code coverage in testing.
There are some ways to measure the degree of code coverage. Here we introduce some common used ways:
1. StatementCoverage
It's also called LineCoverage,SegmentCoverage or BasicBlockCoverage, this is the most frequently used code coverage method. It means every executable code statement is tested. Here the executable statement doesn't include those statements which are declared in C++ header files, comments,blank lines etc. We only count the statements which can be executed. The single line which contains only a { is also considered an executable statement. StatementCoverage is considered as the weakest coverage, it only concerns about the executable statements but not care about different branch combinations. Some bugs may not be found in this method.
For example:
int foo(int a, int b)
{
return a / b;
}
If the tester writes a test case as :
TeseCase: a = 10, b = 5
The result is the code coverage rate is 100%, and the testing is passed. But we may not find the bug here,if b is 0, it will throw a divisor equal to 0 exception.
2. DecisionCoverage
It's also called BranchCoverage , All-EdgesCoverage, BasicPathCoverage or Decision-Decision-Path. It checks whether each branch is tested in the codes.
3. ConditionCoverage
It checks whether each sub expression which has a result of true or false is tested. To distinguish between DecisionCoverage and ConditionCoverage, we take an example here.
int foo(int a, int b)
{
if (a < 10 || b < 10) // Condition
{
return 0; // Branch 1
}
else
{
return 1; // Branch 2
}
}
When we design DecisionCoverage test cases, we only need to consider two situations where the result is true and the result is false. Hence we can design below test cases so that the code coverage rate is 100%:
TestCaes1: a = 5, b ï¼ any number Cover Branch 1
TestCaes2: a = 15, b = 15 Cover Branch 2
When designing ConditionCoverage test cases, we need to consider result of each condition in the if statement. We need to design below test cases:
TestCase1: a = 5, b = 5 true, true
TestCase4: a = 15, b = 15 false, false
From above example, we can find the difference between DecisionCoverage and ConditionCoverage. In ConditionCoverage, we no need to check all the combinations of each condition, we only need to have each condition results in true and false once. Hence the complete ConditionCoverage cannot guarantee complete DecisionCoverage. For the above example, if we design test cases as:
TestCase1: a = 5, b = 15 true, false Branch 1
TestCase1: a = 15, b = 5 false, true Branch 1
From above, we can see we covered all conditions, but we don't cover all branches.
4. PathCoverage
It's also called PredicateCoverage, it checks whether each branch is executed or not. For below code:
int foo(int a, int b)
{
int nReturn = 0;
if (a < 10)
{// Branch 1
nReturn += 1;
}
if (b < 10)
{// Branch 2
nReturn += 10;
}
return nReturn;
}
We design test cases using above 3 code coverage methods:
a. StatementCoverage
TestCase a = 5, b = 5 nReturn = 11
b. DecisionCoverage
TestCase1 a = 5, b = 5 nReturn = 11
TestCase2 a = 15, b = 15 nReturn = 0
c. ConditionCoverage
TestCase1 a = 5, b = 15 nReturn = 1
TestCase2 a = 15, b = 5 nReturn = 10
All the above 3 methods have a code coverage rate of 100%. However, mReturn may have 4 possible return values:0.1.10.11. And above test cases only covers some return values, not all of them. Lets check the 4th method now:
TestCase1 a = 5, b = 5 nReturn = 0
TestCase2 a = 15, b = 5 nReturn = 1
TestCase3 a = 5, b = 15 nReturn = 10
TestCase4 a = 15, b = 15 nReturn = 11
PathCoverage covers all the 4 return values. It's called the strongest coverage.
There are some other coverage methods such as LoopCoverage. We will not cover them here.
Conclusion
a. Coverage rate only represents what codes are tested, it cannot represent you can test these codes well.
b. Don't over trust code coverage rate
c. Don't assess your testers only relying on StatementCoverage rate
d. PathCoverage>DecisionCoverage>StatementCoverage
e. Testers should not concern about code coverage rate only. Instead they should design more and better test cases.
Source : http://www.cnblogs.com/coderzh/archive/2009/03/29/1424344.html
