White Box Testing

White‐box tes,ng 
Corso di Laurea Magistrale in Ingegneria Informa,ca 

Lecturer: Valen,na Presu> 
Academic Year: 2008/2009

Summary 
•  White‐box (or Glass‐box) tes,ng: general 
characteris,cs 
•  Statement coverage 
•  Decision coverage 
•  Condi,on coverage 
•  Decision and condi,on coverage 
•  Coverage of a linearly independent set of 
paths 
SoNware Engineering a.a. 2008/2009  
2 
White‐box tes,ng

White‐box tes,ng: general characteris,cs 

•   Also called 
–  Glass‐box tes,ng 
–  Structural tes,ng (compared to func,onal) 
•  Exploits the control structure, that means the 
control or ﬂow graph of programs in order to 
design test cases 
•  Typically performed during coding 

3 

White‐box tes,ng: general characteris,cs cont.d 

•  Allows to test parts of the program 
–  With black‐box is not possible 
•  Allows to cover systema,cally every part of 
the program 
–  ONen errors are found in special cases 

4 

Types of white‐box tests 

5 

Statement coverage 

•  It is the easiest criterion for a reasonable 
white‐box test 
•  Necessary but not suﬃcient 
•  Goal 
–  To iden,fy a set of test cases suﬃcient to exercise 
all statements at least once 

6 

Statement coverage cont.d 
Java example:  A 

    /*A*/  ﬂoat x = InOut.readFloat(),  B 
x != 0 
                 y = InOut.readFloat(); 
    /*B*/  if (x != 0)  x == 0 
C 
    /*C*/    y += 10; 
    /*D*/  y = y/x; 
    /*E*/  System.out.println(x + ' ' + y);  D 

•  The test case  E 
{x != 0; y = any}
 
•  Covers the statements  Control ﬂow graph for the example 

7 

Statement coverage cont.d 
•  Possible problem 
–  Even in a case of a program without itera,ons, the 
execu,on of every statement does not guarantee 
that all possible paths are exercised 
•  Possible nega,ve consequence: 
–  In previous java example program the error of 
division by 0 is not iden,ﬁed (statement D) 

8 

Decision coverage 
•  Properly includes statement coverage 
•  Vice versa does not hold 
•  Focus on all possible decisions in a program  
•  Decisions are in statements 
–  if, switch, while, for, do 
•  Goal  
–  To iden,fy a set of test cases suﬃcient for 
guaranteeing that each decision will have value 
“true” at least once and value “false” at least once 
9 

Decision coverage cont.d 
Java example: 

    /*A*/  ﬂoat x = InOut.readFloat(), 
                      y = InOut.readFloat(); 
    /*B*/  if (x != 0) 
A 
    /*C*/    y += 10; 
    /*D*/  y = y/x;  B 
    /*E*/  System.out.println(x + ' ' + y);  x != 0 
x == 0 
C 
Test cases 
1.  {x=20;  y=30} 
2.  {x=0;    y=30}  D 

 Cover decisions hence statements. 
 The second case iden,ﬁes the error of division by zero in 
E 
statement D 

10 

•  Possible problem 
•  If decisions are composed of several condi,ons (AND, 
OR), decision coverage can be not suﬃcient 

Esempio Java: 
/*A*/  ﬂoat z = InOut.readFloat(), 
             w = InOut.readFloat(); 
             t = InOut.readFloat(); 
/*B*/  if (z  == 0 || w > 0) 
What is the 
/*C*/    w = w/z;  problem here? 
/*D*/  else w = w + 2/t; 
/*E*/  System.out.println(z+' '+w+' '+t); 

11 

•  Test cases: 
–  {t = 0; z= 5 ; w= 5}  decision TRUE 
–  {t = 0; z= 5 ; w= ‐5}  decision FALSE 
•  Cover decision 
•  The second one iden,ﬁes the division by zero in 
D but 
•  The risk of division by zero in C is not iden,ﬁes 
•  We need a criterion that considers both structure 
and components of decisions 

12 

Condi,on coverage 
•  Does not properly include decision coverage 
•  It is not properly included by decision coverage 
•  Focus on all possible condi,ons in a program 
•  Condi,ons are the operands of non‐atomic 
boolean expressions  
•  Goal: 
guaranteeing that every condi,on (atomic boolean 
expression) included in the program’s decisions have 
value “true” at least once and value “false” at least 
once 

13 

Condi,on coverage cont.d 
Java example: 
/*B*/  if (z  == 0 || w > 0) 
/*C*/    w = w/z; 
/*D*/  else w = w + 2/t; 
/*E*/  System.out.println(z+' '+w+' '+t);  What problem do  
such case tests  
make emerge? 
Test cases 
{t=0;z=0;w=‐5}  1a c.=T, 2a c.=F 
{t=0;z=5;w= 5}  1a c.=F, 2a c.=T 
Cover condi,ons 

14 

Condi,on coverage 
•  Test cases 
–  {t=0;z=0;w=‐5}  1a condi,on =T, 2a condi,on =F 
–  {t=0;z=5;w= 5}  1a condi,on=F, 2a condi,on=T 
•  Cover condi,ons 
•  The first one iden,fies the division by zero in 
C 
•  The risk of division by zero in D is not 
iden,fied as D is never excercised 
•  Decision is always “true” 
15 

Decision and condi,on coverage 
•  Properly includes 
–  Decision coverage 
–  Condi,on coverage 
•  Goal  
guaranteeing that  
•  Each decision is “true” at least once and “false” at least 
once 
•  All condi,ons composing decisions is “true” at least 
once and “false” at least once 

16 

Decision and condi,on coverage 
cont.d 
/*B*/  if (z  == 0 || w > 0) 
/*C*/    w = w/z; 
/*D*/  else w = w + 2/t; 

Test cases 
{t=0;z=0;w=5}  1a c.=T, 2a c.=T, dec.=T 
{t=0;z=5;w=‐5}  1a c.=F, 2a c.=F, dec.=F 
Cover decisions and condi,ons and iden,fy both division by zero 
in statements C and D 

17 

Summary of test cases so far 
Test  t z w cond.1 cond.2 decis. Finds  Finds 
case error  error 
in C? in D?
C1 0 0 5 T T T yes no

C2 0 5 5 F T T no no

C3 0 0 ‐5 T F T yes no

C4 0 5 ‐5 F F F no yes

18 

Coverage  Associated  Finds error  Finds error 
criterion test cases  in C? in D?

Decision  C2 + C4 no yes

Condi,on  C2 + C3 yes no

Decision and  C1 + C4, or  yes yes
condi,on C2 + C3 + C4

19 

Methodological issue 
•  There are different combina,on of test cases 
that guarantee decision and condi,on 
coverage but it is not always trivial to find one 
•  We need a simple and effec,ve method for 
iden,fying test cases that cover both decisions 
and condi,ons 

20 

Control ﬂow graph’s paths coverage 
•  Based on 
–  Criteria of decision and condi,on coverage 
–  Program’s control ﬂow graph 
•  Goal  
–  To provide a simple method for guaranteeing 
decision and condi,on coverage 

21 

Control ﬂow graph 
Predicate nodes  arc 
while (A) { 
A         if (B) { C } 
node         else  { D } 
B         E 
   } 
D  C   F; 

E 

region  Example: 
F 
V(G) = 7 ‐ 6 + 2 = 3 
V(G) = 3 

Cycloma,c number 
• V(G) = E ‐ N + 2 (E = number of arcs, N = number of nodes) 
• V(G) = R             (R = number of regions) 
22 

Control ﬂow graph 

un,l 

Sequence of 
statements 
Simple if  case 
while 

23 

Control flow graph without condi,ons 
/*A*/  float z = InOut.readFloat(),  A 
B 
             t = InOut.readFloat();  False  True 
/*B*/  if (z  == 0 || w > 0) 
/*C*/    w = w/z;  D  C 
/*D*/  else w = w + 2/t; 
E 

The control flow graph should be more 
detailed 

24 

Control ﬂow graph with complex decisions 
  if (a || b)     if (a && b)  

        x;          x; 
    else y;      else y; 
...  ... 

a  a 
a==F  a==T  a==T  a==F 

b  b 
b==F  b==T  b==F 
b==T 
y  x  x  y 

...  ... 

25 

Control flow graph for the program 
/*B*/  if (z  == 0 || w > 0) 
/*C*/    w = w/z; 
/*D*/  else w = w + 2/t; 
A 
z 
!= 0  == 0 
A 

B  <= 0  w  > 0 
False  True 
D  C 
D  C 

E 
E  Control flow graph with condi:ons 
Control flow graph  
Without condi:ons  SoNware Engineering a.a. 2008/2009  
26 

Control ﬂow graph, condi,ons and 
decisions 
•  Boolean values (“true” and “false”) associated 
with condi,ons and decisions have 
correponding arcs 
•  To design a set of test cases such that all arcs 
of the control ﬂow graph are traversed implies 
condi,on and decision coverage 

27 

Paths of the control ﬂow graph 
•  The set of test cases corresponds to a set of 
paths such that all every arc is traversed at 
least once 
•  The number of paths suﬃcient for covering all 
arcs is always equal or less than the cycloma,c 
complexity 

28 

For the previous example 
/*A*/  ﬂoat z = InOut.readFloat(),  A 
             t = InOut.readFloat();  z 
/*B*/  if (z  == 0 || w > 0)  != 0  == 0 
/*C*/    w = w/z; 
/*D*/  else w = w + 2/t;  <= 0  w  > 0 
D  C 

E 
Three test cases 
C2. {t=0; z=5; w= 5}  V=7‐6+2=3 
C3. {t=0; z=0; w= ‐5}  The three paths  
C4. {t=0; z=5; w=‐5}  1.  A‐z‐w‐C‐E  (C2)  
Cover all arcs, hence decisions and condi,ons  2.  A‐z‐C‐E  (C3) 
3.  A‐z‐w‐D‐E  (C4) 

29 

How to choose paths 
•  Pragma,c rule 
–  Experiments show that the the number of errors 
increase with increasing of the cycloma,c 
complexity 
–  Choose a number of paths equal to the 
cycloma,c complexity 
–  You have a propor,on between number of test 
cases and complexity of the code 

30 

Linearly independent paths 
•  A good criterion for choosing paths is based on the 
concept of linear independency 
•  A maximal set of linearly independent paths is called a 
base 
–  It is NOT unique 
•  A base contains a number of paths equal to the 
cycloma,c complexity 
•  Intui,vely, every path input‐output can be obtained as 
a linear combina,on of paths of a base 
•  By choosing a base, a certain extend of reliability id 
guaranteed with respect of combina,ons of errors that 
hide each other 
31 

Example of paths 
A 
1  while (A) {  Paths 
B         if (B) { C } 
2  3         else  { D } 
α.  A‐F 
7 
D  C  6         E  β.  A‐B‐D‐E‐A‐F 
   } 
4  5 
 F;  γ.  A‐B‐C‐E‐A‐F 
E 

F 
The matrix rank 
Arcs/ 1 2 3 4 5 6 7 is 3 (the 
paths
maximum)   
α 0 0 0 0 0 0 1
{α β γ} is a base 
β 1 1 0 1 0 1 1
γ 1 0 1 0 1 1 1
32 

Remarks 
•  Every path corresponds to a binary row vector (0/1) 
•  Vice versa does not hold 
•  A matrix represen,ng paths has maximum 2E dis,nct 
rows (E = n° archi)  A 
•  McCabe proved that for each graph G:  B 
1 
1.  The matrix rank cannot be greater than V(G) (cycloma,c  2  3 
complexity)  7  D  C  6 
2.  There exists always a matrix made of paths with rank 
equal to V(G)  4  5 
E 
•  A base is any set of paths (rows) with maximum rank 
•  Note: MacCabe’s result is purely topological  
F 
/*B*/    if(5>7) 
       /*C*/  i=9 
•  Arc B‐C is never covered  
•  In other cases is necessary to re‐iterate the cycles in 
order to traverse all arcs 
33 

Arcs traversable only by itera,ons 
/*A*/  int z = InOut.readInt(); int t=0; 
/*B*/  while (t<100) 
/*C*/    if (t > 20)  
/*D*/                 t=t+90; 
/*E*/          else  t= t+z*z; 
/*F*/  System.out.println(t); 

A 

B 
B‐F  t<100  t>=100 
C‐D 
Require at least one itera,on in order to   C 
t>20  t<=20 
be traversed 
{10} A‐B‐C‐E‐K‐B‐F  D  E 
{5}   A‐B‐C‐E‐K‐B‐C‐D‐K‐B‐F 
F 
K 
Fake node 
34 

Addi,onal considera,ons 
•  Paths coverage method does not consider 
explicitly loops itera,ons 
•  In some cases it is necessary to perform 
itera,ons in order to traverse all arcs 
•  It might be interes,ng to consider some 
itera,on in any case but the number of test 
cases increases exponen,ally 
•  It is important to decide the type of itera,ons 
35 

Pragma,c choices for loops 
•  To limit the number of itera,ons to n 
–  It is called “loop coverage” 
•  To execute only certain loops 
•  To limit the number of paths to be traversed based on 
weighted arcs and func,on to be maximized 
–  Probability of execu,on 
–  Resources occupancy  
•  To limit the number of paths by iden,fying the paths 
that deﬁne and use program variables (Data Flow 
tes,ng) 
–  Deﬁni,on of a variable value 
–  Use of such value in a test 
36 

Data Flow Tes,ng  B 

C 
... 
A   int x,y,a,b;  D 
B   scanf(“%d %d”,&x, &y); 
C   a=x;  E 
D   b=y  a!=b  a==b 
E    while (a!=b) 
F 
F        if(a>b)  a>b  a<=b 
G            a=a‐b; 
G  H 
H       else  b=b‐a; 
I     prin~(“%d”,a); 
.... 
I 
For x and y it is not needed to execute the loop (loop coverage = 0) 
For the deﬁni,on of a and b the loop has to be iterated once (loop coverage = 1) 
For the deﬁni,on and usage of a and b the loop has to be iterated twice (loop coverage = 2) 
37 

White Box Testing

More Related Content

What's hot

Similar to White Box Testing

White Box Testing