DA-IICT

IT 415: Software Testing and Quality Analysis

Control Flow & Data Flow Analysis

& Level of Testing
Saurabh Tiwari

Data Flow Analysis

What is it?
A form of static analysis based on the definition and usage of variables
How it is performed?
Analysis of data use
The usage of data on paths through the program code is checked

Use to detect data flow anomalies

Unintended or unexpected sequence of operations on a variable
What is an anomaly?
An inconsistency that can lead to failure, but does not necessarily so
May be flagged as a risk

Data Flow Analysis

Examples of data flow anomalies
Reading variables without previous initialization
Not using the values of a variable at all
The usage of every single variable is inspected
Three types of usage or states of variables
Defined (d) : the variable is assigned a value
Reference (r) : the value of the variable is read and/or used
Undefined (u) : the variable has no defined value

Data Flow Analysis

Three types of data flow anomalies
ur-anomaly : an undefined value (u) of a variable is read on a program
path (r)
du-anomaly : the variable is assigned a value (d) that becomes
invalid/undefined (u) without having been used in the meantime
dd-anomaly : the variable receives a value for the second time (d) and the
first value had not been used (d)

Data Flow Coverage for Source

def : a location where a value is stored into memory
x appears on the left side of an assignment (x = 44;)
x is an actual parameter in a call and the method changes its value
x is a formal parameter of a method (implicit def when method starts)
x is an input to a program
use : a location where variables value is accessed
x appears on the right side of an assignment
x appears in a conditional test
x is an actual parameter to a method
x is an output of the program
x is an output of a method in a return statement
If a def and a use appear on the same node, then it is only a DU-

pair if the def occurs after the use and the node is in a loop

Example Data Flow Stats

public static void computeStats (int [ ] numbers)
{
int length = numbers.length;
double med, var, sd, mean, sum, varsum;
sum = 0.0;
for (int i = 0; i < length; i++)
{
sum += numbers [ i ];
}
med = numbers [ length / 2 ];
mean = sum / (double) length;
varsum = 0.0;
for (int i = 0; i < length; i++)
{
varsum = varsum + ((numbers [ i ] - mean) * (numbers [ i ] - mean));
}
var = varsum / ( length - 1 );
sd = Math.sqrt ( var );
System.out.println ("length:
" + length);
System.out.println ("mean:
" + mean);
System.out.println ("median:
" + med);
System.out.println ("variance:
" + var);
System.out.println ("standard deviation: " + sd);
}

Control Flow Graph for Stats

1

( numbers )
sum = 0
length = numbers.length

i=0

i >= length

i < length

sum += numbers [ i ]
i++

med = numbers [ length / 2 ]

mean = sum / (double) length
varsum = 0
i=0

i >= length

i < length

7
varsum =

var = varsum / ( length - 1.0 )

sd = Math.sqrt ( var )
print (length, mean, med, var, sd)

i++

CFG for Stats With Defs & Uses

1 def (1) = { numbers, sum, length }

def (2) = { i }

use (3, 5) = { i, length }

use (3, 4) = { i, length }

def (5) = { med, mean, varsum, i }

use (5) = { numbers, length, sum }

def (4) = { sum, i }

use (4) = { sum, numbers, i }

use (6, 8) = { i, length }

use (6, 7) = { i, length }

def (7) = { varsum, i }

use (7) = { varsum, numbers, i, mean }

def (8) = { var, sd }

use (8) = { varsum, length, mean,
med, var, sd }

Defs and Uses Tables for Stats

Node
1
2
3
4
5

Def

Use

{ numbers, sum,
length }
{i}

{ numbers }

{ sum, i }
{ med, mean,
varsum, i }

{ numbers, i, sum }
{ numbers, length, sum }

{ varsum, i }

{ var, sd }

Use

(1, 2)
(2, 3)
(3, 4)
(4, 3)

{ i, length }

(3, 5)

{ i, length }

(5, 6)

6
7

Edge

{ varsum, numbers, i,
mean }
{ varsum, length, var,
mean, med, var, sd }

(6, 7)

{ i, length }

(7, 6)
(6, 8)

{ i, length }

DU Pairs for Stats

variable

DU Pairs

defs come before uses, do

not count as DU pairs

numbers (1, 4) (1, 5) (1, 7)

length
(1, 5) (1, 8) (1, (3,4)) (1, (3,5)) (1, (6,7)) (1, (6,8))
med
var
sd
mean
sum

(5, 8)
(8, 8)
(8, 8)
(5, 7) (5, 8)
(1, 4) (1, 5) (4, 4) (4, 5)

varsum
i

(5, 7) (5, 8) (7, 7) (7, 8)

(2, 4) (2, (3,4)) (2, (3,5)) (2, 7) (2, (6,7)) (2, (6,8))
(4, 4) (4, (3,4)) (4, (3,5)) (4, 7) (4, (6,7)) (4, (6,8))
(5, 7) (5, (6,7)) (5, (6,8))
No path through graph from
(7, 7) (7, (6,7)) (7, (6,8))
nodes 5 and 7 to 4 or 3

defs after use in loop,

these are valid DU pairs
No def-clear path
different scope for i

DU Paths for Stats

variable
numbers

length

med
var
sd
sum

DU Pairs

DU Paths

(1, 4)
(1, 5)
(1, 7)

[ 1, 2, 3, 4 ]
[ 1, 2, 3, 5 ]
[ 1, 2, 3, 5, 6, 7 ]

(1, 5)
(1, 8)
(1, (3,4))
(1, (3,5))
(1, (6,7))
(1, (6,8))

[ 1, 2, 3, 5 ]
[ 1, 2, 3, 5, 6, 8 ]
[ 1, 2, 3, 4 ]
[ 1, 2, 3, 5 ]
[ 1, 2, 3, 5, 6, 7 ]
[ 1, 2, 3, 5, 6, 8 ]

(5, 8)
(8, 8)
(8, 8)
(1, 4)
(1, 5)
(4, 4)
(4, 5)

[ 5, 6, 8 ]
No path needed
No path needed
[ 1, 2, 3, 4 ]
[ 1, 2, 3, 5 ]
[ 4, 3, 4 ]
[ 4, 3, 5 ]

variable
mean

DU Pairs
(5, 7)
(5, 8)

DU Paths
[ 5, 6, 7 ]
[ 5, 6, 8 ]

varsum

(5, 7)
(5, 8)
(7, 7)
(7, 8)

[ 5, 6, 7 ]
[ 5, 6, 8 ]
[ 7, 6, 7 ]
[ 7, 6, 8 ]

(2, 4)
(2, (3,4))
(2, (3,5))
(4, 4)
(4, (3,4))
(4, (3,5))
(5, 7)
(5, (6,7))
(5, (6,8))
(7, 7)
(7, (6,7))
(7, (6,8))

[ 2, 3, 4 ]
[ 2, 3, 4 ]
[ 2, 3, 5 ]
[ 4, 3, 4 ]
[ 4, 3, 4 ]
[ 4, 3, 5 ]
[ 5, 6, 7 ]
[ 5, 6, 7 ]
[ 5, 6, 8 ]
[ 7, 6, 7 ]
[ 7, 6, 7 ]
[ 7, 6, 8 ]

Summary
Applying the graph test criteria to control flow graphs is

relatively straightforward
Most of the developmental research work was done with CFGs

A few subtle decisions must be made to translate control

structures into the graph

Questions?

In general, how many different combinations of

condition values must be considered when a branch
predicate has N conditions?

In General

Number of
program Paths

Path Coverage

Number of
Basis Paths

=>

Basis Paths
Coverage

=>

Number of test cases

required for branch
coverage

Branch Coverage

Exercise
1.

Prove that Path and Compound Condition Coverage are

independent.
(Hint: consider the proof that Branch and Condition
Coverage are independent.)

2.

Prove that Branch Testing guarantees statement coverage

3.

Condition Testing: Stronger testing than branch testing

4.

Which code coverage criteria is strongest among testing

strategies? Why?

Questions?

Next.
Levels of Testing, Junit Testing Framework

Levels of Testing
Lowlevel testing
Unit (module) testing
Integration testing

Type of Testing Performed By

Programmer/Developer
Development team

Highlevel testing
System testing
Function testing

Independent Test Group

Independent Test Group

Acceptance testing

Customer

Testing Terms
Test case A set of Inputs, execution preconditions, and

expected outcomes for testing an specific aspect of CUT

Test Suite A collection of test cases for the CUT
Test Criterion A set of test requirements
Failure An observation of the behavior of CUT different
from expected one
Fault A condition in CUT that may cause failure
Effectiveness Fault detection capability
Efficiency The average testing cost (i.e. effort) to identify a
fault in the program

A Testing Process

Unit Testing
Done on individual units (Class or small cluster classes in
OO System and a function or modules in Procedural
Systems)
Test unit w.r.to unit specification
Mostly done by developers/programmers
requires stubs and drivers
Further Popularized by the availability of Unit Testing
Frameworks

10

Stubs and Drivers

Stub:
dummy units which
simulates the function
of other units required
to test unit under test

Driver:
Code that executes unit
under test

Integration Testing
Tests a group of units, modules, or a subsystem
Test subsystem structure w.r.to design, subsystem
functions
Focuses on unit interfaces
Done by one/group of developers
Undertaken based on dependency considerations

11

Integration Testing Approaches

Nonincremental (BigBang integration )
unit test each module independently
combine all the units to form the subsystem in one
step, and test the combination
Incremental
instead of testing each unit in isolation, the next unit to
be tested is first combined with the set of units that
have already been tested
integration approaches: Functional System: Top-down, Bottom-up
OO System: Based on dependency considerations

Comparison
NonIncremental

Incremental

requires more stubs, drivers

requires less stubs, drivers

module interfacing errors

detected late
debugging errors is difficult

module interfacing errors

detected early
debugging errors is easier
results in more thorough
testing of modules

12

Example: Integration Testing in Functional

Systems

Example: Integration Testing in OO Systems

13

Top-down Integration
Begin with the top module in the module call hierarchy
Stub modules are produced
Stubs are often complicated
The next module to be tested is any module with at
least one previously tested super-ordinate (calling)
module
After a module has been tested, one of its stubs is
replaced by an actual module (the next one to be tested)
and its required stubs

Top-down Integration Testing

14

Bottom-Up Integration Testing

Begin with the terminal modules (those that do not call
other modules) of the modules call hierarchy
A driver module is produced for every module
The next module to be tested is any module whose
subordinate modules (the modules it calls) have all
been tested
After a module has been tested, its driver is replaced
by an actual module (the next one to be tested) and its
driver

Example: Module Hierarchy

15

Example: Bottom-Up Integration Testing

System Testing

Process of attempting to demonstrate that the program

or system does not meet its original requirements and
objectives as stated in the requirements specification
Test cases derived from
requirements specification
system objectives, user documentation

16

System Testing: Example

Questions??

Next Lecture.
More on Levels of Testing, Junit Testing Framework

17