LECTURE 7: SOFTWARE TESTING

WHITE BOX TESTING

1
 White-box Testing
 White Box Testing is a testing technique which evaluates the code and
the internal structure of a program.

 It is one of the most used software testing techniques.

 Designing white-box test cases:

– requires knowledge about the internal structure of software.
– white-box testing is also called structural testing.

 There exist several popular white-box testing methodologies:

1. Statement coverage
2. branch coverage
3. path coverage
4. condition coverage
5. mutation testing
6. data flow-based testing
2
 Statement Coverage
 Statement coverage testing: In this the test case is executed in such a
way that every statement of the code is executed at least once.
Example
1.print (int a, int b) {   
2.int sum;
3.sum = a+b;   
4.if (sum>0)   
5.print ("This is a positive result")   
6.else   
7.print ("This is negative result")   
8.}   

If a = 5, b = 4, So the Statement coverage = 5/7*100 = 71%

3
 Branch Coverage
 Branch coverage is a testing method, is used to cover all branches of the
control flow graph.

1.Read X  
2.Read Y   Control flow graph of code
structure
3.IF X+Y > 100 THEN  
4.Print "Large"  
5.ENDIF  
6.If X + Y<100 THEN  
7.Print "Small"  
8.ENDIF  
Path 1 - A1-B2-C4-D6-E8
Path 2 - A1-B3-5-D7
Branch Coverage (BC) = Number of paths =2
Case Covered Branches Path Branch coverage
Yes 1, 2, 4, 5, 6, 8 A1-B2-C4-D6-E8 2
No 3,7 A1-B3-5-D7 4
 Path Coverage
 A path through a program:
– a node and edge sequence from the starting node to a terminal node of
the control flow graph.
– There may be several terminal nodes for program.
 Design test cases such that:
– all linearly independent paths in the program are executed at least once.

Linearly independent paths

 Is any path through the program that introduces at least one new edge or
node that is not included in any other linearly independent paths.
 Defined in terms of: control flow graph (CFG) of a program.

Path coverage-based testing

 To understand the path coverage-based testing: we need to learn how to draw
control flow graph of a program.

5
 Control flow graph (CFG)
 A control flow graph (CFG) describes:
1. The sequence in which different instructions of a program get executed.
2. How the control flows through the program.
How to draw Control flow graph?

1. Number all the statements of a program.

2. Numbered statements: represent nodes of the control flow graph.
3. 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.

6
How to draw Control flow graph?
 Sequence: 1
– 1 a=5;
– 2 b=a*b-1;
2
 Selection:
– 1 if(a>b) then 1
– 2 c=3; 2 3
– 3 else c=5;
– 4 c=c*c; 4
1
 Iteration:
– 1 while(a>b){
– 2 b=b*a; 2
– 3 b=b-1;}
– 4 c=b+d;
3
4
 Example
int f1(int x,int y){
1
1 while (x != y){
2 if (x>y) then 2
3 x=x-y; 3 4
4 else y=y-x;
5
5 }
6 return x; } 6
 It is straight forward to identify linearly independent paths of simple
programs.
 For complicated programs: it is not so easy to determine the number of
independent paths.

8
 McCabe's Cyclomatic complexity metric
 Is a software metric used to indicate the complexity of a program. It is a
quantitative measure of the number of linearly independent paths through a
program's source code.

 It is computed using the control flow graph of the program: the nodes of the
graph correspond to indivisible groups of commands of a program.

 To test each linearly independent path through the program; the number of
test cases will equal the cyclomatic complexity of the program.

 Given a control flow graph G, the cyclomatic complexity can be computed in

two ways:
1. V(G) = E-N+2P
‾ N is the number of nodes in G
‾ E is the number of edges in G
‾ P = the number of connected components [always 1 for a single program]
2. V (G) = P + 1
‾ P = Number of predicate nodes (node that contains condition)
9
Example Control Flow Graph
1
2
3 4
5
6
Cyclomatic complexity
V(G) = M = 7-6+2 = 3.
V(G) = 2 + 1 = 3.

10
 Cyclomatic complexity
 McCabe's metric provides: quantitative measure of testing difficulty

 The first method of computing V(G) is amenable to automation:

– You can write a program which determines the number of nodes and
edges of a graph
– Applies the formula to find V(G).

 The cyclomatic complexity of a program provides:

– The number of independent paths in a program
– A lower bound on the number of test cases to be designed
– To guarantee coverage of all linearly independent paths.

 Knowing the number of test cases required:

– does not make it any easier to derive the test cases,
– only gives an indication of the minimum number of test cases required.

11
 Path testing
 The tester proposes:
– an initial set of test data using his experience and judgement.
Derivation of Test Cases
 Let us discuss the steps: to derive path coverage test cases of a program.
 Draw control flow graph.
 Determine V(G).
 Determine the set of linearly independent paths.
 Prepare test cases: to force execution along each path.

12
 Example
int f1(int x,int y){ 1
1 while (x != y){ 2
2 if (x>y) then
3 4
3 x=x-y;
4 else y=y-x; 5
5 } 6
6 return x; }

 Number of independent paths: 3

– 1,6 test case (x=1, y=1)
– 1,2,3,5,1,6 test case(x=1, y=2)
– 1,2,4,5,1,6 test case(x=2, y=1)
13
 An interesting application of cyclomatic complexity
 Relationship exists between:
– McCabe's metric
– the number of errors existing in the code,
– the time required to find and correct the errors.

 Cyclomatic complexity of a program:

– also indicates the psychological complexity of a program.
– difficulty level of understanding the program.

 From maintenance perspective,

– limit cyclomatic complexity of modules to some reasonable value.
– Good software development organizations: restrict cyclomatic
complexity of functions to a maximum of ten or so.

14
Basis Path Testing
First, we compute the cyclomatic complexity:
Number of edges – number of nodes + 2
9-7 + 2 = 4 or number of simple decisions + 1 or
Number of enclosed areas + 1 In this case, V(G) = 4
Next, we derive the independent paths:
Since V(G) = 4, there are four paths
Path 1: 1,2,3,6,7,8
Path 2: 1,2,3,5,7,8
Path 3: 1,2,4,7,8
Path 4: 1,2,4,7,2,4,...7,8
Finally, we derive test cases to test these paths.

15
Simple
loop
Nested
Loops

Concatenated
Loops Unstructured
Loops

Loop Testing
16
 Simple Loops
1. skip the loop entirely
2. only one pass through the loop
3. two passes through the loop
4. m passes through the loop m < n
5. (n-1), n, and (n+1) passes through the loop where n is the maximum
number of allowable passes
Nested Loops
1. Start at the innermost loop. Set all outer loops to their minimum iteration
parameter values.
2. Test the min+1, typical, max-1 and max for the innermost loop, while
holding the outer loops at their minimum values.
3. Move out one loop and set it up as in step 2, holding all
4. other loops at typical values. Continue this step until
5. the outermost loop has been tested.

Concatenated Loops
If the loops are independent of one another then treat each as a simple loop
else* treat as nested loops
endif*
for example, the final loop counter value of loop 1 is used to initialize loop 2. 17
 White-box Testing Example
FindMean(float Mean, FILE ScoreFile)
{ SumOfScores = 0.0; NumberOfScores = 0; Mean = 0;

Read(ScoreFile, Score);

/*Read in and sum the scores*/

while (! EOF(ScoreFile) {
if ( Score > 0.0 ) {
SumOfScores = SumOfScores + Score; NumberOfScores++;
}
Read(ScoreFile, Score);
}
/* Compute the mean and print the result */
if (NumberOfScores > 0 ) {
Mean = SumOfScores/NumberOfScores;
printf("The mean score is %f \n", Mean);
} else
}
printf("No scores found in file\n");
}
18
Determining the Paths

19
Constructing the Flow Graph
Finding the Test Cases

20
 Structural Coverage Criteria: Control Flow
Structural Testing: Examples

Path testing
Visit-each-loop path testing
Branch testing
Statement testing 21
 Infeasible paths
The simple code can have four total test paths: TP1: 1,2,4,6,8,10, TP2:
1,2,4,7,9,10, TP3: 1,3,5,6,8,10, TP4: 1,3,5,7,9,10. According to the two
conditional statements and due to the contradicted logic of the two
conditions, we can easily notice that TP1 can never be executed and
hence will be always infeasible paths.

22
 Summary
 Exhaustive testing of non-trivial systems is impractical:
– we need to design an optimal set of test cases
• should expose as many errors as possible.
 If we select test cases randomly:
– many selected test cases don’t add to the significance of the test set.
 There are mainly two approaches to testing:
– black-box testing and
– white-box testing.
 White box testing:
– requires knowledge about internals of the software.
– Design and code is required.
 A stronger testing strategy:
– provides more number of significant test cases than a weaker one.
– Condition coverage is strongest among strategies we discussed.
 Designing test cases for black box testing:
– does not require any knowledge of how the functions have been designed
and implemented.
– Test cases can be designed by examining only SRS document.
23
 References

 Bernd Bruegge & Allen H. Dutoit, Object-Oriented Software

Engineering: Using UML, Patterns, and Java
 Software Engineering, Ivan Marsic, 2020
 Sommerville, I. (2015). Software Engineering 10. Pearson.