Data Flow Testing

Week 6
Data Flow Testing
 Testing All-Nodes and All-Edges in a control flow graph may miss significant test cases

 Testing All-Paths in a control flow graph is often too time- consuming

 Can we select a subset of these paths that will reveal the most faults?

 Dataflow Testing focuses on the points at which variables receive values and the points
at which these values are used

2
 Data Flow Analysis
 Can reveal interesting bugs
 A variable that is defined but never used
 A variable that is used but never defined
 A variable that is defined twice before it is used
 Sending a modifier message to an object more than once between accesses
 Deallocating a variable before it used

Container problem
 Deallocating container loses references to items in the container, memory leak
Defining a variable
• A variable is said to be defined (created or initialized or instantiated) in a statement if it
acquires a value at that statement.
• Examples
• int x; // default initialization to zero in C lang.
• int x = 0; // initialized at declaration
• x = 15; // assigned a value
• x = compute(y); // computed and assigned a value
• obj = new MyClass(); // instantiated
• public void method (int param) { // instantiated through
// parameter passing
// mechanism

4
Using a variable
• A variable is said to be used in a statement if its value is extracted and utilized in that statement.
• Examples
• y = x; // value of x is assigned to y
• y = compute (x); // value of x is used as a parameter
• if (x) { // value of x is used as a conditional attribute
• sort (arr); // value of arr is used as a parameter and at the same time it is subject to modification
by the method sort.
• myObject = previousObject; // two variables pointing to the
// same object but no values
// extracted or changed
• anObject = clone (previousObject); // values of
// previousObject are
//copied into anObject

5
 Terminating a variable
• A variable is said to be terminated (or killed) when its value is
no longer accessible or relevant to the program. Trying to
access its value must result in an exception or program crash.
• Examples
• public int compute (int param) {
int result; Termination point
….
return result;
}

6
Static and Dynamic Data Flow
Testing
• Static Data Flow Testing
• Analyze code without executing
• Through control flow graphs
• Identify most data flow anomalies

• Dynamic Data Flow Testing

• Analyze code by executing and tracing the paths
• Additional code or tool support necessary
• Useful to find data anomalies such as “array index out of bounds”, “divide by zero”

7
Why to detect data flow
anomalies?
• Consider
x = compute(y);
x = compute(z);
• Possible interpretations of the situation
• The first statement is redundant
• There is a mistake in the first statement; it is supposed to be
w = compute(y);
• There is a mistake in the second statement; it is supposed to be
w = compute(z);
• There is a missing statement in between the two that uses ‘x’; something like
w = function(x);
8
 Categories of Data Flow Anomalies(static Analysis )
Anomaly Explanation
Symbols used in the tables
~d First define Allowed
d – defined
du Define and then use Allowed; normal case
u - used
k - killed/terminated dk Define and kill without use Potential bug; data is
terminated without use
~d – first time defined
~u First time use without definition Potential bug; data used
~u – first time used without assigning value;
~k – first time killed compiler might catch it
ud Used and defined at the same time Allowed
(e.g., i++)
uk Used and killed Allowed

~k Killed without definition Potential bug; compiler

might catch it

9
Categories of Data Flow Anomalies (continued)
Anomaly Explanation

ku Killed and used Serious defect; trying to access

data that was killed

kd Killed and redefined Allowed

dk Define and kill without use Potential bug; data is terminated
without use

dd Defined again without usage Potential bug; first definition of

data is useless

uu Used multiple times Allowed; normal case

kk Killed and killed again Serious defect; once killed, it
should not be accessible

~k Killed without definition Potential bug; compiler might

catch it
10
Exampl
e
 Define-Use (du) path
• 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

12
Data Flow Concept
 Definition Clear Path
 A du-path with no other defining node for v is a definition-clear path
Example 1 – Max Program
Max Program – Analysis
 Modified program graph for the factorial example

1 ret = 0
int i, n, ret; 2
4
n<0 return ret
3

i = n; ret = 1
5

i>0
6

ret = ret * i; i = i - 1
7

8 return ret

The parameter ‘n’ is assumed to be defined in the very first statement

18
Du-paths for variables in factorial
problem
Variable Defined Used at du-path
at
n 1 3 1,2,3
5 1,2,3,5
i 1
5 6 5,6
5 7 5,6,7
7 6 7,6
7 7 7,6,7
19
Du-paths for variables in factorial problem
(continued)
Variable Defined Used at du-path
at
ret 1
2 4 2,3,4
5 7 5,6,7
7 7 7,6,7
7 8 7,6,8

20
Define-use (du) path (continued)
• USE (v,n) can further be classified as

• P-use (v,n) where v is used in a predicate

• C-use (v,n) where v is used in a computation
• O-use (v,n) where v is used in an output statement
• L-use (v,n) where v is used in a location (pointer or subscript)
• I-use (v,n) where v is used as a loop index or an internal counter

21
Exercise
• Find the du-paths of all variables for the program given below.

22
The defining and usage nodes for the
variable totalPrice
Complete this table to find du path
for totalPrice, price and
staffDiscount
Variable Defined at Used at du-path
totalPrice 4 7 4, 5, 6, 7

7 7 7,7
7 10 7,8,9,10
? ? ?
? ? ?
?
Complete
this table
 Guidelines
 When is dataflow analysis good to use?

 Data flow testing is good for computationally/control intensive programs


If P-use of variables are computed, then P-use data flow testing is good

 Define/use testing provides a rigorous, systematic way to examine points at which faults
may occur.
Observations
• Data flow testing will be quite helpful
• when the code is larger (several lines ) and/or deeply nested
• In these scenarios, it is hard to trace the variables in the code manually

• when there are several variables that are shared across many methods (e.g.,
attributes or instance variables of a class)
• Local variables are somewhat easier to trace depending on the size of a method
because their scope is limited to the method

• when data is frequently exchanged between the code and a database

• Remember that a database may be updated externally without going through the
code
Q &A
Thank you!