Chapter 4: Structural (White Box) Testing

Tadele M.
1
 White-Box Testing

 White-box testing(also called clear box testing, glass box testing, transparent box
testing, or structural testing)
 is a method of testing software that tests internal structures or workings of an
application
 The tester has access to the internal data structures and algorithms including the code
that implement these.
 Test sets are derived from the structure of the code.

2
 Types of White-Box Testing

 Control flow/Coverage testing

 Data flow based testing
 Mutation testing

3
 Control Flow Testing
 Code structure represented as Control Flow Graph (CFG).
 Control flow refers to flow of control from one instruction to another.
 Edges in CFG portray control flow paths and the nodes in CFG portray basic
blocks.
 The goal is to cover the CFG.

4
 Control Flow Testing
 The software tester will start by creating CFG, which will help them
identify all the possible execution paths of a program.
 The set of paths chosen is used to achieve a certain measure of testing
thoroughness.
 Enough entry/exit paths are selected to satisfy path selection criteria.

5
 Control Flow Testing
 Basic notations that are used to draw a flow graph

6
 Control Flow Graph – Examples

Sample Code: CFG:

1. if A = 10 then
2. if B > C
3. A=B
4. else A = C
5. endif
6. endif
7. print A, B, C

7
 Code complexity
 Is there any limit to the number of tests that must be run to ensure that all the
statements have been executed at least once?
 The answer to this question is a metric that quantifies the complexity of a program and
is known as cyclomatic complexity.

 It is a number which provides us with an upper bound for the number of tests that
must be conducted to ensure that all statements have been executed at least once.

8
 Paths in a Control Flow Graph

 Cyclomatic complexity-V(G)

V(G)=P+1=2+1=3 [nodes 1 and 2 are predicate nodes]

or
 V(G)=number of enclosed regions +1 =2+1=3
or
 V(G)=e-n+2= 8-3+2= 3

 Paths of the above CFG:

 Path 1: 1-2-3-5-6-7
 Path 2: 1-6-7
 Path 3: 1-2-4-5-6-7

9
 Testing Coverage

 Enough testing is defined in terms of coverage.

 Coverage refers to the extent to which a given testing activity has satisfied its objectives.
 It is the degree (expressed as percentage) to which a specified coverage item has been
exercised by a test suite.
 It measures how well the tests cover the code.

10
 Types of Test Coverage

 We have three types of test coverage

 Statement coverage
 Decision coverage
 Condition coverage

11
 Statement coverage

 Also known as line coverage

 It measures if all the possible executable statements of code have been executed at
least once.

12
 Strategy for statement coverage

1. Derive flow graph

2. Find cyclomatic complexity #c
3. Determine at most #c independent paths through the program
(add one new edge for each test case)
4. Prepare test cases covering the edges for each path (possibly
fewer than #c cases)

13
 Statement coverage

 Example 1
1. READ X 1,2
2. READ Y
3. IF “X > Y”
4. PRINT X is greater that Y
5. ENDIF 3

 To get 100% statement coverage only one test case is

sufficient for this pseudo-code.
 TEST CASE 1: X=10 Y=5
4
 Path: 1-2-3-4-5 5

14
 Statement coverage
1 READ X
 Example 2 2 READ Y
3 Z =X + 2*Y
4 IF Z> 50 THEN
5 PRINT large Z
6 ENDIF
 The following test cases were executed, how much statement coverage did the
tester achieve?
 TEST SET 1
Test 1_1: X= 2,Y = 3
Test 1_2: X =0,Y = 25
Test 1_3: X =47,Y = 1

15
 Statement coverage

 = 5/6*100
 =83% statement coverage

16
 Decision Coverage

 Decision coverage, also known as branch coverage, is a testing technique that

ensures that each possible branch from each decision point is tested at least once,
ensuring that all reachable code is executed.

17
 Decision Coverage - Example

18
 Decision Coverage - Example
• We have three decision points—these are the nodes: (1, 2), (3), and (6).
• We have six test conditions to cover:
• Decision (1, 2) outcome to TRUE
• Decision (1, 2) outcome to FALSE
• Decision (3) outcome to TRUE
• Decision (3) outcome to FALSE
• Decision (6) outcome to TRUE
• Decision (6) outcome to FALSE
• The minimum number of test cases achieving the decision coverage is 3.
•Test 1: 1, 2, 9, 10 (covers the test condition 2)
•Test 2: 1, 2, 3, 4, 5, 3, 6, 7, 9, 10 (covers the test conditions 1, 3, 4, and 5)
19 •Test 3: 1, 2, 3, 6, 8, 9, 10 (covers the test conditions 1, 4, and 6)
 Decision Coverage
 Example: 1 READ A
2 READ B
3 C = A – 2 *B
4 IFC <0 THEN
5 PRINT “C negative”
6 ENDIF
 TEST SET 2: Test 2_1: A = 20, B = 15 50% decision coverage

Test 2_2: A=10, B=2 50% decision coverage

100% decision coverage guarantees 100% statement coverage

20
 Condition Coverage
 In Condition Coverage (also know as Predicate Coverage) each of the boolean
expressions must be evaluated to true and false at least once.
 Condition Coverage requires that each condition will have been True at least once
and False at least once.
 The possible outcomes of (“true” or “false”) for each condition are tested at least once

21
 Condition Coverage- Example
1. int num1 = 0;
2. if(num1>0){
3. cout<<"valid input";
4. }else{
5. cout<<"invalid input";
6. }

 Two test cases are needed to achieve 100 % condition coverage:

22
  Consider the below example to calculate Condition Coverage:
If (x < y) AND (c > d) THEN
 For the above expression, there are 4 possible combinations: TT, TF, FT, FF
 Scenario:
 x=3, y=4
 c=3, d=4
 x<y = TRUE, c<d = FALSE which satisfies one of the 4 combinations (TF).
 Therefore, Condition Coverage is equal to (1/4)*100 = 25%

23
 Outline of Control Flow Testing

24 Figure : The process of generating test input data for control flow testing.
 Quiz

• Draw CFG
• Calculate Cyclomatic complexity V(G)
• List linear independent paths
25 • Calculate the statement coverage if x= 2, y=5
 Coverage-revised

26
 Coverage-revised
 For example, consider the following fragment of code:
 Decision coverage Condition coverage

• Condition coverage check each of the conditional parts independently and the other side
branch coverage check the conditional part as one final statement based on the outer
27 conditional keyword.
 Coverage-revised
entry

Tests: x=0, y=-5

1. void main(){ 2,3,4 x=5, y=5
2. float x,y;
3. read x;
4. read y;
5. if((x==0)|| (y>0))
5 Branch coverage=?
6. y=y/x;
7. else x=y+2; 6 7
8. write(x);
9. write(y);
10. }
8

28 exit
 Coverage-revised
entry
Test case
Final
number X==0 Y>0
output
1. void main(){ 2,3,4
2. float x,y; 1 True True True
3. read x;
2 True False True
4. read y; 5
5. if((x==0)|| (y>0))
6. y=y/x; 3 False True True
7. else x=y+2; 6 7
8. write(x); 4 False False False
9. write(y);
10. }
8
Tests: x=0, y=-5
x=5, y=5
9

exit Condition coverage=?

29
 Mutation Testing

 Certain statements of the source code are changed/mutated to check if the test cases are
able to find errors in source code.

Original Program Mutant Program

If (x>y) If(x<y)
Print “Hello” Print “Hello”
Else Else
Print “Hi” Print “Hi”

30
 Data Flow Testing
 You can also design test cases based on "data flow“ (i.e., how data flows through
the code)
 Paths from the definition of a variable to its use are more likely to contain bugs

 It designs test cases that cover control flow paths around variable definitions and
31
their uses in the modules
  Data Flow testing helps us to pinpoint any of the following issues:
a) A variable that is declared but never used within the program.
b) A variable that is used but never declared.
c) A variable that is defined multiple times before it is used
d) Deallocating a variable before it is used.

32
  A usage node is a predicate use, P-use, if variable v appears in a predicate
expression
 A usage node is a computation use, C-use, if variable v appears in a
computation
 A node in the program is a kill node for a variable v – KILL(v, n) – if the
variable is deallocated at the statement fragment in that node.

33
  A definition-use path, du-path, with respect to a variable v is a path whose first node is a
defining node for v, and its last node is a usage node for v
 A du-path with no other defining node for v is a definition-clear/ dc- path.
 An example of a DU-path that is also definition-clear since there is no a second
defining node within the path.

34
 Some adequacy criteria
 All DU pairs: Each DU pair is exercised by at least one test case
 All DU paths: Each simple (non looping) DU path is exercised by at least one test
case
Example:
Identify DU pairs for variable A

35
 Example…

<1,2> <1,3,4> <1,3,4,5> <1,3,5>

36
 Exercise
 Identify DU pairs and DU path for variable B using the CFG used by the previous
example.

37