Condition testing Branch coverage exposes faults in how a computation has been decomposed into cases intuitively attractive:

e: check the programmers case analysis but only roughly: groups cases with the same outcome Condition coverage considers case analysis in more detail also individual conditions in a compound Boolean expression e.g., both parts of digit_high == 1 || digit_low == -1 Adequacy criterion: each basic condition must be executed at least once Coverage: # truth values taken by all basic conditions 2 * # basic conditions Basic condition adequacy criterion can be satisfied without satisfying branch coverage T4 = {first+test%9Ktest%K9} satisfies basic condition adequacy does not satisfy branch condition adequacy Branch and basic condition are not comparable (neither implies the other) Branch and condition adequacy: cover all conditions and all decisions Compound condition adequacy: Cover all possible evaluations of compound conditions Cover all branches of a decision tree
digit_high == -1
true false

digit_low == 1
true false

FALSE

TRUE

FALSE

Compound conditions: Exponential complexity (((a || b) && c) || d) && e

Test a b c d e Case (1) T T T (2) F T T T (3) T F T T (4) F T F T T (5) F F T T (6) T T F (7) F T T F (8) T F T F (9) F T F T F (10) F F T F (11) T F F (12) F T F F (13) F F F Condition Coverage execute each decision with all possible outcomes at least once Multiple condition Coverage Invokes each point of entry at least once. Condition Coverage Example A=X If (A > 3) or (A < B) Then B=X+Y End-If-Then While (A > 0) and (Not EOF) Do Read (X) A=A-1 End-While-Do Condition Coverage In the branch coverage we make sure that we execute every branch at least once For conditional branches, this means that, we execute the TRUE branch at least once and the FALSE branch at least once Conditions for conditional branches can be compound boolean expressions A compound boolean expression consists of a combination of boolean terms combined with logical connectives AND, OR, and NOT Condition coverage: Select a test set T such that by executing program P for each test case d in T, (1) each edge of Ps control flow graph is traversed at least once and (2) each boolean term that appears in a branch condition takes the value TRUE at least once and the value FALSE at least once Condition coverage is a refinement of branch coverage (part (1) is same as the branch coverage)

T = {(x= y=1), (x=1, y=1)} will achieve 1, statement, branch and path coverage, however T will not achieve condition coverage because the boolean term (y < x) never evaluates to true. This test set satisfies part (1) but does not satisfy part (2). something(int x) { if (x < 0 || y < x) { y := -y; x := -x; } z := x; } T = {(x= y=1), (x=1, y=0)} 1, will not achieve condition coverage either. This test set satisfies part (2) but does not satisfy part (1). It does not achieve branch coverage since both test cases take the true branch, and, hence, it does not achieve condition coverage by definition. T = {(x= y= {(x=1, y=1)} 1, 2), achieves condition coverage. Multiple Condition Coverage Multiple Condition Coverage requires that all possible combination of truth assignments for the boolean terms in each branch condition should happen at least once For example for the previous example we had: x < 0 && y < x Test set {(x= y= (x=1, y=1)}, achieves condition coverage: 1, 2), test case (x= y= makes term1=true, term2=true, and the whole 1, 2) expression evaluates to true (i.e., we take the true branch) test case (x=1, y=1) makes term1=false, term2=false, and the whole expression evaluates to false (i.e., we take the false branch) However, test set {(x= y= (x=1, y=1)} does not achieve multiple condition 1, 2), coverage since we did not observe the following truth assignments term1=true, term2=false term1=false, term2=true

Condition Coverage
Condition coverage reports the true or false outcome of each condition. A condition is an operand of a logical operator that does not contain logical operators. Condition coverage measures the conditions independently of each other. This metric is similar to decision coverage but has better sensitivity to the control flow.

However, full condition coverage does not guarantee full decision coverage. For example, consider the following C++/Java fragment.
bool f(bool e) { return false; } bool a[2] = { false, false }; if (f(a && b)) ... if (a[int(a && b)]) ... if ((a && b) ? false : false) ...

All three of the if-statements above branch false regardless of the values of a and b. However if you exercise this code with a and b having all possible combinations of values, condition coverage reports full coverage.

Multiple Condition Coverage

Multiple condition coverage reports whether every possible combination of conditions occurs. The test cases required for full multiple condition coverage of a decision are given by the logical operator truth table for the decision. For languages with short circuit operators such as C, C++, and Java, an advantage of multiple condition coverage is that it requires very thorough testing. For these languages, multiple condition coverage is very similar to condition coverage. A disadvantage of this metric is that it can be tedious to determine the minimum set of test cases required, especially for very complex Boolean expressions. An additional disadvantage of this metric is that the number of test cases required could vary substantially among conditions that have similar complexity. For example, consider the following two C/C++/Java conditions.
a && b && (c || (d && e)) ((a || b) && (c || d)) && e

To achieve full multiple condition coverage, the first condition requires 6 test cases while the second requires 11. Both conditions have the same number of operands and operators. The test cases are listed below.
1. 2. 3. 4. 5. 6. 1. 2. 3. 4. 5. a && b && (c || (d && e)) F T F T T F F T T F T F T T F T T T T T ((a || b) && (c || d)) && e F F F T F F F T F T F F T F T T F T T F

6. 7. 8. 9. 10. 11.

F T T T T T

T -

T F F F T T

F T T -

T F T F T

As with condition coverage, multiple condition coverage does not include decision coverage. For languages without short circuit operators such as Visual Basic and Pascal, multiple condition coverage is effectively path coverage (described below) for logical expressions, with the same advantages and disadvantages. Consider the following Visual Basic code fragment.
If a And b Then ...

Multiple condition coverage requires four test cases, for each of the combinations of a and b both true and false. As with path coverage each additional logical operator doubles the number of test cases required. Conditional Testing The first improvement to white box techniques is to ensure that the Boolean controlling expressions are adequately tested, a process known as condition testing. The process of condition testing ensures that a controlling expression has been adequately exercised whilst the software is under test by constructing a constraint set for every expression and then ensuring that every member on the constraint set is included in the values which are presented to the expression. This may require additional test runs to be included in the test plan. To introduce the concept of constraint sets the simplest possible Boolean condition, a single Boolean variable or a negated Boolean variable, will be considered. These conditions may take forms such as:
if DateValid then while not DateValid then

The constraint set for both of these expressions is {t ,f } which indicates that to adequately test these expressions they should be tested twice with DateValid having the values True and False. Perhaps the next simplest Boolean condition consists of a simple relational expression of the form value operator value, where the operator can be one of: is equal to ( = ), is not equal to ( /= ), is greater than ( > ), is less than ( = ) and is less than or equal to ( , <}, which

indicates that to adequately test a relational expression it must be tested three times with values which ensure that the two values are equal, that the first value is less than the second value and that the first value is greater than the second value. More complex control expressions involve the use of the Boolean operators, and, or and xor, which combine the values of two Boolean values. To construct a constraint set for a simple Boolean expression of the form BooleanValue operator BooleanValue all possible combinations of True and False have to be considered. This gives the constraint set for the expression as {{t ,t } {t ,f } {f ,t } {f ,f }}. If both BooleanValues are simple or negated Boolean variables then no further development of this set is required. However if one or both of the BooleanValues are relational expressions then the constraint set for the relational expression will have to be combined with this constraint set. The combination takes the form of noting that the equality condition is equivalent to true and the both inequality conditions are equivalent to false. Thus every true condition in the condition set is replaced with ' = ' and every false replaced twice, once with ' > ' and once with ' < '. Thus if only one the left hand BooleanValue is a relational expression the condition set would be {{= ,t } {= ,f } {> ,t } { ,f } { } {= , ,= } { ,> } {> ,< } { } {< ,< }}. An increase in the complexity of the Boolean expression by the addition of more operators will introduce implicit or explicit bracketing of the order of evaluation which will be reflected in the condition set and will increase the number of terms in the set. For example a Boolean expression of the following form: BooleanValue1 operator1 BooleanValue2 operator3nbsp;BooleanValue3 Has the implicit bracketing: (BooleanValue1 operator1 BooleanValue2) operato3 BooleanValue3 The constraint set for the complete expression would be {{e1,t}{e1,f}}, where e1 is the condition set of the bracketed sub-expression and when it is used to expand this constraint set gives {{t,t,t} {t,f,t} {f,t,t} {f,f,t} {t,t,f} {t,f,f} {f,t,f} {f,f,f}}. If any of the BooleanValues are themselves relational expressions this will increase the number of terms in the condition set. In this example the worst case would be if all three values were relational expressions and would produce a total of 27 terms in the condition set. This would imply that 27 tests are required to adequately test the expression. As the number of Boolean operators increases the number of terms in a condition set increases exponentially and comprehensive testing of the expression becomes more complicated and less likely. It is this consideration which led to the advice, initially given in Section 1, to keep Boolean control expressions as simple as possible, and one way to do this is to use Boolean variables rather than expressions within such control conditions.

Condition coverage In this structural testing, test cases are designed to make each component of a composite conditional expression to assume both true and false values. For example, in the conditional expression ((c1.and.c2).or.c3), the components c1, c2 and c3 are each made to assume both true and false values. Branch testing is probably the simplest condition testing strategy where only the compound conditions appearing in the different branch statements are made to assume the true and false values. Thus, condition testing is a stronger testing strategy than branch testing and branch testing is stronger testing strategy than the statement coverage-based testing. For a composite conditional expression of n components, for condition coverage, 2 test cases are required. Thus, for condition coverage, the number of test cases increases exponentially with the number of component conditions. Therefore, a condition coverage-based testing technique is practical only if n (the number of conditions) is small.