SQA:: Defect Detection:: White Box

Test Case Design through

Control Flow Graph

by

Dr. Rizwan
 White Box Testing
 White box testing is also know as Glass Testing or Open box
testing is detailed examination of internal structure and logic
of code.
 This examination is demonstrated through test cases creation
by looking at the code to detect any potential failure
scenarios.
 Disadvantages of White Box Testing

 This approach generates test inputs, but a test also

requires expected outcomes to compare against.
 Code-based test case design cannot tell whether the
outcomes produced by the software are the correct
values – it is the specification for the code that tells
you what it should do.
 So this approach is incomplete, since it cannot
generate expected outcomes.
 It is very difficult to look into every corner of the code,
some code will go unchecked.
 Disadvantages of White Box Testing
 Another problem with this approach is that it only
tests code that exists and cannot identify code that is
missing.
 It is also testing that 'the code does what the code
does.'
 This is generally not the most useful kind of testing,
since we normally want to test that 'the code does
what it should do.‘
 Software works as coded' (not 'as specified').
 This approach cannot find specification defects or
missing specifications.
 Advantages of White Box Testing

 As tester has knowledge of the source code it is easy to find

errors.
 White box testing helps us to identify memory leaks.
 When we allocate memory using malloc( ) in C, we should
explicitly release that memory also.
 If this is not done then over time, there would be no memory
available for allocating memory on requests.
 Performance analysis:
 Code coverage tests can identify the areas of a code that are
executed most frequently.
 Extra efforts can be then made to check these sections of code.
 Advantages of White Box Testing
 Due to testers knowledge of code , maximum coverage is
attained during test scenario.
 He or she can then see if the program diverges from its
intended goal.
 How Complex Should Code Be?

 <10: Simple module, not much risk

 10-20: More Complex; moderate risk

 20-50: Complex; high risk

 >50: Untestable; extremely high risk

 Complexity Warning
 As code is broken into smaller modules to decrease
complexity, structural complexity increases
 Some modules may have high complexity but are very easy
to comprehend and easy to test
 High complexity numbers are only an indicator of
something to investigate
 White Box Testing
 White box testing utilizes the logical flow through a
program to propose test cases.
 Logical flow means the way in which certain parts of a
program may be executed as we run the program. Logical
flow of a program can be represented by a control flow
graph.
 Most common white box testing methods are:
 Statement Coverage
 Decision/Branch Coverage
 Condition Coverage
 Path Coverage
 Control Flow Graph
 How to Draw a Control Flow Graph
 Number all the statements of a program

 Numbered statements:
 Represent nodes of the flow graph

 An edge from one node to another node exists:

 If execution of the statement representing the first node can result in
transfer of control to the other node
 We need to analyze code
 Control-flow
 Dataflow
 Input space partitions
Types of Control Flow Graph
Types of Control Flow Graph
Types of Control Flow Graph
Types of Control Flow Graph
 Statement Coverage

 The goal is to design test cases so that every statement of

the program is executed at least once

 An error in a program can not be discovered unless the

part of the program containing the error is executed (based
on observation)
 Statement Coverage

int abs(int x ) {
if ( x ≥ 0 )
x = 0 - x;
return x;
}
 Statement Coverage
 Exercise all statements at
least once

A=2 and B=0 (ace)

 Branch Coverage

 The goal is to design test cases to ensure that each branch

is executed once
 Each decision is evaluated to true and false, at least once
traversed
 Generally satisfies statement coverage
 Branch coverage has problems with multiple (compound)
conditions within a decision (&&, ||)
 Branch Coverage

/* x is valid if 0 ≤ x ≤ 100 */

int check (int x ){

if( x ≥ 0 && x ≤ 100 )

return TRUE;

else return FALSE;

} Inputs Actual Output

Test Cases x
T1 -5
T2 5
 Branch Coverage
/* finding the maximum of two integers x and y */
int Max_check(int x, y, max) {
If (x>y) max = x;
else max = y;
}
Inputs Actual Output
Test Cases x y
T1 3 2
T2 2 4
 Branch Coverage
 Each decision has a true
and a false outcome at
least once

A=2 and B=0 (ace)

A=1 and X=1 (abd)
 Condition Coverage

 The goal is to design test cases to ensure that each

condition in a decision takes on all possible outcomes at
least once.
 Ensures that every condition within a decision is covered
 Consider the conditional expression:
((c1 and c2)or c3)
 Each of c1, c2, and c3 are exercised at least once,
i.e. given true and false values require 23 test cases.
 Useful if number of component conditions is small.
 Condition Coverage

 Each condition in a decision

takes on all possible
outcomes at least once
 Conditions: A>1, B=0, A=2,
X>1

A=2, B=0, and X=4 (ace)

A=1, B=1, and X=1 (abd)
 Condition Coverage

 Each condition in a decision takes

on all possible outcomes at least
once, and
 Each decision takes on all
possible outcomes at least once
 Test cases
A=2, B=0, and X=4 (ace)

A=1, B=1, and X=1 (abd)

 What about these?

A=1, B=0, and X=3 (abe)

A=2, B=1, and X=1 (abe)

 Path Coverage
 A path can contain combination of statements, conditions
and branches grouped together in one path.
 In this way you can select statements, conditions and
branches of your own choices and group them in one path.
 Similarly you can prioritize source code statement in to
various paths.
 Path Identification

Path Condition
1, 2, 3, 8, 9 Bottom< top && found == false elemArray[mid] == key
1, 2, 3, 4, 6, 7, 2 Bottom< top && found == false elemArray[mid] == key

1, 2, 3, 4, 5, 7, 2 Bottom< top && found == false elemArray[mid] == key

1, 2, 3, 4, 6, 7, 2, 8, 9 Bottom< top && found == false elemArray[mid] == key

Design Test Cases of identified Paths…

How to Design Test Case Through White Box
 public class myBSearch{
 public intsearch(intkey, int[] elemArray)
 {
 intbottom = 0;
 inttop = elemArray.Length-1;
 intmid;
 intindex = -1;
 Boolean found = false;
 while (bottom <= top && found == false)
 {
 mid = (top + bottom) / 2;
 if (elemArray[mid] == key)
 {
 index = mid;
 found = true;
 return index;
 }
How to Design Test Case Through White Box
 else
 {
 if (elemArray[mid] < key)
 bottom = mid + 1;
 else
 top = mid -1;
 }
 }
 return index;
 }
 }
 }
Design Control Flow Graph
Design Control Flow Graph
Design Control Flow Graph
How to Design Test Case Through White Box
1. int main () {
2. float number1;
3. float number2;
4. float number3;
5. cout<<"Please enter Number 01:";
6. cin>>number1;
7. cout<<"Please enter Number 02:";
8. cin>>number2;
9. cout<<"Please enter Number 03:";
10. cin>>number3;
11. if (number1 > number2 && number1 > number3) {
12. cout<<"Number 01 is maximum… "<<endl;
13. }
14. else if (number2 > number1 && number2 > number3) {
15. cout<<"Number 02 is maximum…"<<endl;
16. }
17. else if (number3 > number1 && number3 > number2) {
18. cout<<"Number 03 is maximum…"<<endl;
19. }
How to Design Test Case Through White Box

20. else {
21. cout<<" Invalid entry for maximum "<<endl;
22. }
23. if (number1 < number2 && number1 < number3) {
24. cout<<"Number 01 is minimum…"<<endl;
25. }
26. else if (number2 < number1 && number2 < number3) {
27. cout<<"Number 02 is minimum…"<<endl;
28. }
29. else if (number3 < number1 && number3 < number2) {
30. cout<<"Number 03 is minimum…"<<endl;
31. }
32. else {
33. cout<<" Invalid entry for minimum "<<endl;
34. }
35. return 0;
36. }
How to Design Test Case Through White Box
 Make Control Flow Graph
 Make Data Flow/Initialize
 Choice of WBT Technique
How to Design Test Case Through White Box

Test Input Output

Case Num1 Num2 Num3

1 2 5 3 Number 3 is Max
Number 1 is Mini
How to Design Test Case Through White Box

Test Input Output

Case Num1 Num2 Num3

2 9 5 2 Number 1 is Max
Number 3 is Mini
How to Design Test Case Through White Box

Test Input Output

Case Num1 Num2 Num3

3 3 7 6 Number 2 is Max
Number 1 is Mini
How to Design Test Case Through White Box

Test Path Input Output

Case ID No. Num1 Num2 Num3

3 3 8 2 9 Number 3 is Max
Number 2 is Mini
 Assignment 6
1) main ( ) {
2) int num student, marks, subject total ;
3) float average ;
4) num_student = 1;
5) while (num_student < = 40) {
 6) total = 0 ;
 7) subject = 1;
 8) while (subject < = 5) {
 9) Scanf ("Enter marks : % d”, & marks);
10) total = total + marks ;
11) subject ++;
12) }
13) average = total/5 ;
14) if (average > = 50)
15) printf ("Pass... Average marks = % f", average);
16) else
17) print ("FAIL ... Average marks are % f”, average) ;
18) num_student ++;
19) }
20) printf ("end of program") ;
21) }