0
3.1kviews
Logic Coverage Criteria
0
91views

Structural testing considers the program code, and test cases are designed based on the logic of the program such that every element of the logic is covered. Therefore, the intention in white-box testing is to cover the whole logic.

1. Statement Coverage

The first kind of logic coverage can be identified in the form of statements. It is assumed that if all the statements of the module are executed once, every bug will be notified.

Consider the C code segment shown below figure, If we want to cover every statement in this, then the following test cases must be designed:

Test case $1 : x=y=n$ , where $n$ is any number. Test case $2 : x=n, y=n^{\prime},$ where $n$ and $n'$ are different numbers. Test case 1 just skips the while loop and all loop statements are not executed. Considering test case $2,$ the loop is also executed. However, every statement inside the loop is not executed. So two more cases are designed: Test case $3 : x\gt y$ Test case $4 : x\lt y$ These test cases will cover every statement in the code segment, but statement coverage is a poor criteria for logic coverage. We can see that test cases 3 and 4 are sufficient to execute all the statements in the code. However, if we execute only test cases 3 and $4,$ conditions and paths in test case 1 will never be tested and errors will go undetected. Thus, statement coverage is a necessary but not a sufficient criteria for logic coverage. **2. Decision or Branch Coverage** Branch coverage states that each decision takes on all possible outcomes (True or False) at least once. In other words, each branch direction must be traversed at least once. In the previous sample code shown in above figure , *while* and *if* statements have two outcomes: True and False. So, test cases must be designed such that both outcomes for *while* and *if* statements are tested. The test cases are designed as: Test case $1 : x=y$ Test case $2 : x !=y$ Test case $3 : x\lt y$ Test case $4 : x\gt y$ **3. Condition Coverage** Condition coverage states that each condition in a decision takes on all possible outcomes at least once. For example, consider the following statement: while $((I \leq 5) \& \& (J \lt COUNT)$ In this loop statement, two conditions are there. So, test cases should be designed such that both the conditions are tested for True and False outcomes. The following test cases are designed: $\begin{array}{l}{\text { Test case } 1 : I \leq 5, J<\text { COUNT }} \ {\text { Test case } 2 : I<5, J>\text { COUNT }}\end{array}$ **4. Decision/condition Coverage** Condition coverage in a decision does not mean that the decision has been covered. If the decision $(A \& \& B)$ is being tested, the condition coverage would allow one to write two test cases: $\begin{array}{l}{\text { Test case } 1 : A \text { is True, } B \text { is False }} \ {\text { Test case } 2 : A \text { is False, } B \text { is True }}\end{array}$ However, these test cases would not cause the THEN clause of the IF to execute (i.e., execution of decision). The obvious way out of this dilemma is a criterion called decision/condition coverage. It requires of sufficient test cases such that each condition in a decision takes on all possible outcomes at least once, each decision takes on all possible outcomes at least once, and each point of entry is invoked at least once. **5. Multiple Condition Coverage** In case of multiple conditions, even decision/condition coverage fails to exercise all outcomes of all conditions. The reason is that we have considered all possible outcomes of each condition in the decision, but we have not taken all combinations of different multiple conditions. Certain conditions mask other conditions. For example, if an AND condition is False, none of the subsequent conditions in the expression will be evaluated. Similarly, if an OR condition is True, none of the subsequent conditions will be evaluated. Thus, condition coverage and decision/ condition coverage need not necessarily uncover all the errors. Therefore, multiple condition coverage requires that we should write sufficient test cases such that all possible combinations of condition outcomes in each decision and all points of entry are invoked at least once. Thus, as in decision/condition coverage, all possible combinations of multiple conditions should be considered. The following test cases can be there: Test case $1 : A=$ True, $B=$ True, Test case $2 : A=$ True, $B=$ False Test case $3 : A=$ False $, B=$ True Test case $4 : A=$ False $, B=$ False