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;
}
 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
 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.
 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.
How to Design Test Case Through White Box
1. public class myBSearch{
2. public intsearch(intkey, int[] elemArray)
3. {
4. Int bottom = 0;
5. Int top = elemArray.Length-1;
6. Int mid=0;
7. Int index = -1;
8. Boolean found = false;
9. while (bottom <= top && found == false)
10. {
11. mid = (top + bottom) / 2;
12. if (elemArray[mid] == key)
13. {
14. index = mid;
15. found = true;
16. return index;
17. }
How to Design Test Case Through White Box
18. else
19. {
20. if (elemArray[mid] < key)
21. bottom = mid + 1;
22. else
23. top = mid -1;
24. }
25. }
26. return index;
27. }
28. }
29. }
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 Num 2 is Max
Num 1 is Mini
How to Design Test Case Through White Box

Test Input Output

Case Num1 Num2 Num3

2 9 5 2 Num 1 is Max
Num 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) }
 Num_std
 Valid Class
 0<Num_std <40
 Invalid Class
 Num_std>40
 0<Num_std

Num_std ECP Actual O/p

T1 22 0<Num_std <40

T2