SOFTWARE TESTING

(CONTROL FLOW TESTING)

Engr. Sajid Saleem
 OUTLINE
 Control Flow Testing
 Technique
 Example

 Levels of Coverage
 Level 0 to Level 7

 Applicability and Limitations

 Drawbacks

2
Control Flow Basis Path Data Flow
Testing Testing Testing
CONTROL FLOW TESTING
 Identifies the execution paths

 Creates test cases to cover those paths

 Execute test cases to cover those paths

TECHNIQUE: CONTROL FLOW
GRAPHS
1. Document modules control structure

2. Modules are converted into graphs

3. Paths in graph are analyzed

4. Test cases are created

 TECHNIQUE: CONTROL FLOW

GRAPHS
Process Blocks

 Decision Point

 Junction point
 STEP 1: NUMBER THE
EXAMPLE CODE LINES
q=1
b=2 1. q=1

c=3 2. b=2

if (a==2) 3. c=3

{x=x+2;} 4. if (a==2)

else 5. {x=x+2;}

{x=x/2;} 6. else

p=q/r; 7. {x=x/2;}

if(b/c > 3) 8. p=q/r;

{z=x+y;} 9. if(b/c > 3)

10. {z=x+y;}
 STEP 2: MODULES ARE CONVERTED
INTO GRAPHS A
 Put all the processing statements
in one process block.
B

 As soon as you get a decision

C D
statement make a decision block.
E
 After the outcomes of decision is
executed make a junction block. F

G
 When the code is finished an
END NODE is formed. H
STEP 3: PATHS IN GRAPH ARE
ANALYZED A
1. abdefgh

B
2. abcefgh
C D
3. abdefh
E
4. abcefh
F

G
H
 STEP 4: TEST CASES ARE
CREATED 1. q=1
A

Test a b/c Path 2. b=2

Case #
3. c=3 B
1 3 10 ABDEFGH
4. if (a==2)
2 2 10 ABCEFGH C D
5.
3 2 2 ABCEFH {x=x+2;}
4 4 2 ABDEFH 6. else E
7. {x=x/2;}
F
8. p=q/r;
9. if(b/c > 3) G
10. {z=x+y;} H
FLOWCHART VS CONTROL
FLOW GRAPH
 PRACTICE 1 1

// Computing a fine for a late rental

int computerFine (int daysLate, boolean 2
printOn) F
T
{
3
1 int MAX_FINE_PERIOD = 21, fine = 0;
2 if (daysLate <= MAX_FINE_PERIOD) {
4
3 fine = daysLate * DAILY_FINE;
}
4 logFine (fine);
5 if (printON == TRUE) { 5
6 printFine(fine); T
Statement Coverage
} F
7 return Afine;
test case for computerFine()
6
} Test Case # daysLate printON Path Coverage
1 1 TRUE 1-2-3-4-5-6-7 100% 7
LEVELS OF COVERAGE
 Level 0 ( <100% Statement Coverage)
 That level is defined as "test whatever you test; let the users test the rest." Statement
 Level 1 (100% Statement Coverage) Coverage
 This means that every statement within the module is executed, under test, at least once.
 Level 2 (100% Decision Coverage) Branch
 This is also called "branch coverage." Coverage
 Level 3 (100% Condition Coverage)
 At this level enough test cases are written so that each condition that has a TRUE and FALSE outcome that makes up
a decision is evaluated at least once.
Condition
 Level 4 (100% Decision/Condition)
Coverage
 At this level test cases are created for every condition and every decision.
 Level 5 (100% Multiple Condition Coverage)
 Achieving 100% multiple condition coverage also achieves decision coverage, condition coverage, and
decision/condition coverage.
 Level 6 ( <100% Path Coverage) Path
 When a module has loops in the code paths such that the number of paths is infinite, a significant but meaningful Coverage
reduction can be made by limiting loop execution to a small number of cases.
 Level 7 (100% Path Coverage)
 For code modules without loops the number of paths is generally small enough that a test case can actually be
constructed for each path.
STATEMENT COVERAGE
 Every statement in the module is executed under test.
 if (a>0) {x=x+1;}
 if (b==3) {y=0;}

 Make graph and identify unique paths.

 Make a test case to execute both statements.

 Are all paths addressed?

Statement Coverage=5/7
= 71%
Statement Coverage: 6/7 = 85%
 BRANCH COVERAGE
Conditional
Branch

 Enough test cases are written so that each decision

that has a TRUE and FALSE outcome is evaluated at
least once.
Suppose: C=10

Branch Coverage = 3, i.e. 3 branches are

required to cover the whole code.
Unconditional
Branch

TC# A B Path Branch Coverage % Branch Coverage

1 9 12 bhi 3/9 x100= 33.3%
2 10 11 aceghi 6/9 x100= 66.7% 3
3 10 8 adfghi 6/9 x100= 66.7%

x 100
(%)
 BRANCH COVERAGE
// An updated computeFine() function
TC#1
1
TC#2
1
int computerFine (int daysLate, boolean printOn)
{
1 int MAX_FINE_PERIOD = 21, fine = MAX_FINE; 2 2
//defect fixed T T
F F
2 if (daysLate <= MAX_FINE_PERIOD) {
3 fine = daysLate * DAILY_FINE; 3 3
}
4 logFine (fine); 4 4
5 if (printON == TRUE) {
6 printFine(fine);
}
7 return fine; 5 5
Tests sufficient to}satisfy Branch Coverage T T
Test daysLate printON Path Coverage % Coverage F F
Case #
6 6
1 1 TRUE 1-2-3-4-5-6-7 75%
2 7
2 60 FALSE 1-2-4-5-7 50% 7
BRANCH COVERAGE
 BRANCH COVERAGE 1
// Another updated function computeFines()
int computerFine (int daysLate[], int numDVD, boolean printOn) F
2
{
1 int MAX_FINE_PERIOD = 21, int cumFine = 0; T
2 for (i=0; i<numDVD; i++) { 3
3 fine=MAX_FINE;
4 if (daysLate[i]<=MAX_FINE_PERIOD) {
5 fine=daysLate[i] * DAILY_FINE; 4 T
} F
6 logFine (fine); 5
7 if (printON == TRUE) { 6
8 printFine(fine);
} T
7
9 cumFine += fine; 8
} F
10 return cumFine; 9
} Tests sufficient to satisfy Branch Coverage
Test i<numDVD daysLate [i] printON Path Coverage % Coverage
Case #
10
.
.
 CONDITIONAL COVERAGE
 For more complexed statements
 Enough test cases are written so that each condition that has a true and false outcome
that makes up a decision is evaluated at least once.
 If first part of condition is checked and is true the second expression will not be
evaluated (in logical operation or case).

 Similarly in logical operator && (And case)??

CONDITIONAL COVERAGE
 To be TRUE, the first statement requires a greater than 0 and c equal 1. The second requires b
equal 3 or d less than 0.
 In the first statement if the value of a were set to 0 for testing purposes then the c==1 part of
the condition would not be tested.
 (In most programming languages the second expression would not even be evaluated.)

 The next level of control flow coverage is "100% condition coverage." At this level enough test
cases are written so that each condition that has a TRUE and FALSE outcome that makes up a
decision is evaluated at least once.
 This level of coverage can be achieved with two test cases (a>0, c=1, b=3, d<0 and a≤0, c≠1,
b≠3, d≥0).
 Condition coverage is usually better than decision coverage because every individual condition
is tested at least once while decision coverage can be achieved without testing every condition.
CONDITION/DECISION
COVERAGE
 Consider this situation:

if(x&&y) {conditionedStatement;}

 We can achieve condition coverage with two test cases (x=TRUE, y=FALSE and x=FALSE,
y=TRUE) but note that with these choices of data values the conditionedStatement will never
be executed.
 Given the possible combination of conditions such as these, to be more complete "100%
decision/condition" coverage can be selected.
 At this level test cases are created for every condition and every decision.
MULTIPLE CONDITIONAL
COVERAGE
 To be even more thorough, consider how the programming language compiler actually
evaluates the multiple conditions in a decision. Use that knowledge to create test cases
yielding "100% multiple condition coverage.“

if (a>0 && c==1) {x=x+1;}

if (b==3 || d<0) {y=0;}
 will be evaluated as:
MULTIPLE CONDITIONAL
COVERAGE
 This level of coverage can be achieved with four test cases:

a>0, c=1, b=3, d<0

a≤0, c=1, b=3, d≥0
a>0, c≠1, b≠3, d<0
a≤0, c≠1, b≠3, d≥0

 Achieving 100% multiple condition coverage also achieves decision coverage, condition
coverage, and decision/condition coverage.
 Note that multiple condition coverage does not guarantee path coverage.
 PATH COVERAGE
// An updated computeFine() function
int computerFine (int daysLate, boolean printOn)
{
1 int MAX_FINE_PERIOD = 21, fine = MAX_FINE;
//defect fixed
Path#1 Path#2 Path#3 Path#4
2 if (daysLate <= MAX_FINE_PERIOD) {
3 fine = daysLate * DAILY_FINE;
1 1 1 1
}
4 logFine (fine);
2 2 2 2
5 if (printON == TRUE) {
F T F T F T F T
6 printFine(fine);
3 3 3 3
}
7 return fine; 4 4 4 4
Test daysLate } printOn Path
Case #
5 5 5 5
1 1 True 1-2-3-4-5-6-7
T T T T
2 60 False 1-2-4-5-7 F F F F
6 6 6 6
3 1 False 1-2-3-4-5-7
7 7 7 7
4 60 True 1-2-4-5-6-7
PATH COVERAGE (LOOPS)
 When a module has loops in the code paths such that the number of paths is infinite, a
significant but meaningful reduction can be made by limiting loop execution to a small
number of cases.
 the first case is to execute the loop zero times;
 the second is to execute the loop one time,
 the third is to execute the loop n times
 where n is a small number representing a typical loop value;

 the fourth is to execute the loop its maximum number of times m.

 In addition you might try m-1 and m+1.

 Before beginning control flow testing, an appropriate level of coverage should be chosen.
 PATH COVERAGE (LOOPS)
 0 times
 1 time
 N times (100)
 Its Maximum number m times
 Optional : m-1, m+1

Tests sufficient to satisfy Path Coverage

Test Case # i Expected Output Actual Output Status
1 2000 -----
2 999 Hello
3 900 Hello 100 times
4 0 Hello 1000 times
5 1 Hello 999 times
6 -1 Hello 1001 times
 1

PATH COVERAGE (LOOPS)

F
2

// Another updated function computeFines() T

int computerFine (int daysLate[], int numDVD, boolean printOn) 3
{
1 int MAX_FINE_PERIOD = 21, int cumFine = 0;
2 for (i=0; i<numDVD; i++) { 4 T
3 fine=MAX_FINE; F
4 if (daysLate[i]<=MAX_FINE_PERIOD) { 5
6
5 fine=daysLate[i] * DAILY_FINE;
}
6 logFine (fine); T
7
7 if (printON == TRUE) { 8
8 printFine(fine);
Tests sufficient to satisfy Path Coverage F
} Test i daysLate[i printOn Expected Actual Status 9
9 cumFine += fine;
Case # ] Output Output
} 1
10 return cumFine;
2 10
}
3
4
APPLICABILITY AND
LIMITATIONS
 Control flow testing is the cornerstone of unit testing.
 It should be used for all modules of code that cannot be tested sufficiently through reviews and
inspections.
 Its limitations are that the tester must have sufficient programming skill to understand the code and
its control flow.
 In addition, control flow testing can be very time consuming because of all the modules and basis
paths that comprise a system.
DRAWBACKS IF WE DO EXHAUSTIVE
TESTING
1. Time versus no. of paths

 No of paths could be huge

 Every decision doubles the number of paths
 Every loop multiplies the number of paths by number of iterations.

for (i=1;i<=1000;i++)
for (j=1;j<=1000;j++)
for (k=1;k<=1000;k++)
do this (i, j, k)
DRAWBACKS IF WE DO EXHAUSTIVE
TESTING
2. How to handle if some path has been missed?

if (a>0)
callGreater ();
if (a==0)
callEquals()

//missing statement=> if (a<0) callLesser();

DRAWBACKS IF WE DO EXHAUSTIVE
TESTING
3. Defects may exist in processing statements while the flow is correct.
a = a+1; //correct

a=a-1;//actual
DRAWBACKS IF WE DO EXHAUSTIVE
TESTING
4. Module may execute correctly for all data except for a few.

int blech(int a, int b)

{
return a/b ;
}

How will it fail ?? Not covered through control flow testing.

THANK YOU