CHAPTER 8

COURSE NAME
DATA FLOW TESTING
SOFTWARE
SOFTWARE
QUALITY AND
ENGINEERING
TESTING
(UNDERGRADUATE
CSC 4133
)

(UNDERGRADUATE
)
 Chapter 8: Data Flow Testing
MMH S.2

DATA FLOW TESTING

 A programmer can perform a number of tests on data values. These tests
are collectively known as ‘data flow testing
 A program unit accepts inputs, performs computations, assigns new values
to variables, and
returns results
 One can visualize of “flow” of data values from one statement to another
 A data value produced in one statement is expected to be used later such
as file pointer is used later. If the later use is never verified, we do not know
if the earlier assignment is acceptable
 Data flow testing is a form of structural testing and a white box testing
technique that focuses on program variables and the paths
o From the point where a variable, v, is defined or assigned a value
o To the point where that variable, v, is used
 Chapter 8: Data Flow Testing
MMH S.3

LEVELS OF DATA FLOW TESTING

 Data flow testing can be performed at two conceptual levels
 Static data flow testing
 Analyse source code but does not involve actual execution of source code
 Identify potential defects, commonly known as data flow anomaly
 Dynamic data flow testing
 Involves actual program execution
 There is similarity and difference between control flow testing (CFT) and data
flow testing (DFT)
 Similarity: both approaches identify program paths & emphasize on
generating test cases from those program paths
 Difference: CFT uses control flow test selection criteria, whereas DFT uses
data flow testing criteria
 Chapter 8: Data Flow Testing
MMH S.4

DATA FLOW ANOMALY

 An anomaly is a deviant or abnormal way of doing something
 Data-flow anomalies represent the patterns of data usage which may lead
to an incorrect execution of the code
 Example 1: The second definition of x overrides the first.
 x = f1(y);
 x = f2(z);
o It is an abnormal situation to successively assign two values to a variable
without using the first value
o It is abnormal to use a value of a variable before assigning a value to the
variable.
o Another abnormal situation is to generate a data value and never use it
 Chapter 8: Data Flow Testing
MMH S.5

TYPES OF DATA FLOW ANOMALY

Three types of abnormal situations concerning the generation and use of data
values:
 Type 1: Defined and then defined again (dd) [cause no error or failure]

x = f1(y);
x = f2(z);
Four interpretations of above example
 The first statement is redundant
 The first statement has a fault -- the intended one might be: w = f1(y);
 The second statement has a fault – the intended one might be: v = f2(z);
 There is a missing statement in between the two: v = f3(x);
 Note: It is for the programmer to make the desired interpretation
 Chapter 8: Data Flow Testing
MMH S.6

TYPES OF DATA FLOW ANOMALY

 Type 2: Undefined but referenced (ur)
 Undeclared but Referenced [cause error or failure]
 Undefined but Referenced [cause no error or failure]
 For example: x = x – y – w; /* w has not been initialized by the
programmer. */
 Two interpretations:
o The programmer made a mistake in using w
o The programmer wants to use the compiler assigned value of w
 One must eliminate the anomaly either by initializing w, or replacing w
with the intended variable
 Chapter 8: Data Flow Testing
MMH S.7

TYPES OF DATA FLOW ANOMALY

 Type 3: Defined but not referenced (du)
 Cause no error or failure to the program
 For Example: Consider the statement x = f(x, y) in which a new value is
assigned to the variable x
 If the value of x is not used in any subsequent computation, then we have
a Defined but not Referenced anomaly.
main()
{
int a=10,b=20, c,
d=30;
c = b+a
cout<<c;
}
 Chapter 8: Data Flow Testing
MMH S.8

REPRESENTING DATA FLOW ANOMALY

 The concept of a state-transition diagram is used to model a program
variable to identify data flow anomaly. “States” of program variables can
be used to identify data flow anomaly.
 Components of the state-transition diagrams:

State U: Undefined
s D: Defined but not referenced
R: Defined and referenced
A: Abnormal
Actio d: define the variable
ns r: reference/read the variable
u: undefine the variable
 Chapter 8: Data Flow Testing
MMH S.9

STATE TRANSITION DIAGRAM OF A PROGRAM VARIABLE

 Initially, a variable can remain in an “undefined” (U) state, meaning that just a memory
location has been allocated to the variable but no value has yet been assigned
(declared).
 At a later time, the programmer can perform a computation to define (d) the variable in
the form of assigning a value to the variable –this is when the variable moves to a
“defined but not referenced” (D) state.
 At a later time, the programmer can reference (r), that is, read, the value of the variable,
thereby moving the variable to a “defined and referenced” state (R) . The variable
remains in the R state as long as the programmer keep referencing the value of the
variable.
 If the programmer assigns a new value to the variable, the variable moves back to the D
state. On the other hand, the programmer can take an action to undefine (u) the
variable.
 Chapter 8: Data Flow Testing S.
MMH 10

STATE TRANSITION DIAGRAM OF A PROGRAM VARIABLE

 However, the programmer can make mistakes by taking the wrong actions while a
variable is in a certain state. For example,
o If a variable is in the state U – that is the variable is still undefined – and a
programmer reads (r) the variable, then the variable moves to an abnormal (A)
state.
o Similarly, while a variable is in the state D and programmer undefines (u) the
variable or redefines (d) the variable, then the variable moves to the abnormal
(A) state.
 Once a variable enters the abnormal state (A), it remains in that state irrespective
of what action – d, u, r is taken.
 The abnormal state of a variable means that a programming anomaly has occurred.
 Chapter 8: Data Flow Testing S.
MMH 11

STATE TRANSITION DIAGRAM OF A PROGRAM VARIABLE

 Data flow anomaly can be detected by using the idea of program
instrumentation
 Program instrumentation: Insert new code to monitor the states of
variables
 If the state sequence contains dd, ur, or du sequence, a data flow
anomaly is said to have occurred.
 Question: Does the presence of data flow anomaly always mean that
execution of the program will result in a failure?
 Answer: Not always…
 The presence of a data flow anomaly in a program does not necessarily
mean that execution of the program will result in a failure (e.g. dd –
define and define again)
 A data flow anomaly simply means that the program may fail, and
therefore the programmer must investigate the cause of the anomaly.
 Chapter 8: Data Flow Testing S.
MMH 12

STATE TRANSITION DIAGRAM OF A PROGRAM VARIABLE

 Scenario 1: A data flow anomaly does not lead to program failure

 Let us consider the dd anomaly in Example 1.
 If the real intention of the programmer was to perform the second
computation and the first computation produces no side effects, then the
first computation merely represents a waste of processing power. Thus dd
anomaly will not lead to program failure.
 Scenario 2: A data flow anomaly leads to a program failure
 If a statement is missing in between the two statements in Example 1,
then the program can possibly lead to a failure.
 Chapter 8: Data Flow Testing S.
MMH 13
STATE TRANSITION DIAGRAM OF A PROGRAM VARIABLE
 While data flow anomalies are dangerous signs, they may or may not lead to
defects
 A defined, but never used variable may just be extra stuff
 Some compilers will assign an initial value of zero or blank to all undefined
variable
based on the data type
 Multiple definitions prior to usage may just be bad and wasteful logic
 The programmers must analyze the causes of data flow anomalies and
eliminate them.
 Investigate the cause of the anomaly
 To fix an anomaly, write new code or modify the existing code
 Chapter 8: Data Flow Testing S.
MMH 14

DATA FLOW GRAPH

 Data-flow testing uses the data flow graph to explore the unreasonable
things that can happen to data (i.e., anomalies)
 In practice, programmers may not draw data flow graphs by hand. Instead,
language translators are modified to produce data flow graphs from
program units
 A data flow graph is drawn with the objective of identifying data definitions
and their uses.
 Each occurrence of a data variable is classified as follows:
 Definition (d)
 Kill (k)
 Use (u):
o c-use: Used in a calculation
o p-use: Used in a predicate
 Chapter 8: Data Flow Testing S.
MMH 15

DATA FLOW GRAPH

 This occurs when a value is moved into the memory location of the variable
(i.e. a variable gets new value)
 i = x; /* The variable i gets a new value. */
 Kill: This occurs if the value and the location become unbound (release)
 Use: This occurs when the value is fetched from the memory location of
the variable.
There are two forms of uses of a variable –
1. Computation use (c-use)
 Example: x = 2*y; /* y has been used to compute value of x
*/
2. Predicate use (p-use)
 Example: if (y > 100) { …} /* y has been used in a
condition */
 Chapter 8: Data Flow Testing S.
MMH 16

DATA FLOW GRAPH

 Data flow testing criteria are based on two fundamental
concepts:
o Definitions
o Uses (both c-uses and p-uses of variables)
Definition C-use
P-use
1. read (x, y); x, y
2. z = x + 2; z x
3. if (z < y) z, y
4. w = x + 1; w x
5. else
6. y = y + 1; y++; y+=3; y y
7. z = f1 (x, y) z x,y
8. print (x, y, w, z); x,y,w,z
 Chapter 8: Data Flow Testing S.
17

REFERENCES

 Software Testing And Quality Assurance – Theory and Practice - Kshirasagar Naik
& Priyadarshi Tripathy
 Software Quality Engineering: Testing, Quality Assurance and Quantifiable
Improvement - Jeff Tian