www.jntuworld.

com

An Introduction to Data-Flow Testing

Janvi Badlaney Rohit Ghatol Romit Jadhwani

Department of Computer Science
North Carolina State University
Raleigh, NC 27695, USA
[email protected], [email protected], [email protected]

Abstract
Control flow diagrams are a keystone in testing the In data-flow testing, the first step is to model the
structure of software programs. By examining the flow of program as a control flow graph. This helps to identify
control between the various components, we can design the control flow information in the program. In step 2, the
and select test cases. Data-flow testing is a control-flow associations between the definitions and uses of the
testing technique which also examines the lifecycle of variables that is needed to be covered in a given coverage
data variables. Use of data-flow testing leads to a richer criterion is established. In step 3, the test suite is created
test suite concentrating on improper use of data due to using a finite number of paths from step 2.
coding errors. The main goal of this paper is to discuss In this paper, we have discussed the concept of data-
the concept of data-flow testing and apply it to a running flow testing. The next section covers the data-flow testing
example. criteria and data-flow anomalies. A billing application is
considered and the corresponding control-flow graphs are
Keywords: Data-flow testing, control-flow graph, Data- presented and annotated to explain the concept of data-
flow anomaly. flow testing. Section 3 presents the test cases created for
this application. Section 4 summarizes the concepts
1. Introduction presented in this paper and concludes the paper.

Software testing is “The process of analyzing a 2. Literature survey/Case Study

software item to detect the differences between existing
and required conditions (that is, bugs) and to evaluate the This section discusses data-flow testing concepts, data-
features of the software items” [9]. The main goals of flow anomalies and data-flow testing strategies.
software testing are to reveal bugs and to ensure that the Throughout this section, data-flow testing techniques are
system being developed complies with the customer’s illustrated using an example of a billing application.
requirements. To make testing effective, it is Data-flow testing monitors the lifecycle of a piece of
recommended that test planning/development begin at the data and looks out for inappropriate usage of data during
onset of the project. Software testing techniques can be definition, use in predicates, computations and
divided into 2 kinds: black box and white box techniques. termination (killing). It identifies potential bugs by
Black box testing is mainly a validation technique that examining the patterns in which that piece of data is used.
checks to see if the product meets the customer For example, A pattern which indicates usage of data in a
requirements. However, white box testing is a verification calculation after it has been killed is certainly a bug which
technique which uses the source code to guide the needs to be addressed.
selection of test data. To examine the patterns, we need to construct a
Data-flow testing is a white box testing technique that control flow graph of the code. A control flow graph is a
can be used to detect improper use of data values due to directed graph where the nodes represent the processing
coding errors [6]. Errors are inadvertently introduced in a statements like definition, computation and predicates
program by programmers. For instance, a software while the edges represent the flow of control between
programmer might use a variable without defining it. processing statements. Since data-flow testing closely
Additionally, he/she may define a variable, but not examines the state of the data in the control flow graph, it
initialize it and then use that variable in a predicate [6]. results in a richer test suite than the one obtained from
e.g. int x ; traditional control flow graph testing strategies like all
if (x ==100) {}; branch coverage, all statement coverage, etc [3].

NCSU CSC TR-2006-22 -1-

www.jntuworld.com

2.1. Data-flow Anomalies applicable. If ‘Bill’ is more than $100, 10% discount is
given.
Data-flow anomalies represent the patterns of data
usage which may lead to an incorrect execution of the Table 2: Billing rules
code. Usage(min) Bill ($)
The notation for representing the patterns is [2][5]:
<100 40.0
50 cents for every additional
• d – defined, created, initialized 101-200 minute.
• k – killed, terminated, undefined 10 cents for every additional
• u – used >200 minute.
o c – used in a computation
o p – used in a predicate
• ~x - indicates all prior actions are not of interest The source code for the above application is:
to x
• x~ - indicates all post actions are not of interest public static double calculateBill (int Usage)
to x {
double Bill = 0;
Table 1 lists the combinations of usage and their
corresponding consequences. It can be observed that not if(Usage > 0)
all data-flow anomalies are harmful but they are all {
Bill = 40;
suspicious and indicate that an error can occur. For }
example, the usage pattern ‘ku’ indicates that a variable is if(Usage > 100)
used after it has been killed which is a serious defect. {
if(Usage <= 200)
{
Table 1: Testing anomalies [1][6] Bill = Bill + (Usage - 100) * 0.5;
Anomaly Explanation }
else
~d first define Allowed. {
du define – use Allowed. Normal case. Bill = Bill + 50 + (Usage - 200) * 0.1;
dk define – kill Potential bug. Data is killed if(Bill >= 100)
without use after definition. {
Bill = Bill * 0.9;
~u first use Potential bug. Data is used without }
definition. }
ud use – define Allowed. Data is used and then }
redefined. return Bill;
}
uk use – kill Allowed.
~k first kill Potential bug. Data is killed before
definition. The control flow diagram is given in Figure 1 and the
ku kill – use Serious Defect. Data is used after annotated control flow diagram with define-use-kill
being killed. information for each variable is given in Figure 2.
kd kill – define Allowed. Data is killed and then
re-defined. For variable ‘Usage’, the define-use-kill patterns are
dd define–define Potential bug. Double definition. • ~ define : normal case
uu use – use Allowed. Normal case. • define-use : normal case
kk kill – kill Potential bug. • use-use : normal case
d~ define last Potential bug. • use-kill : normal case
u~ use last Allowed.
k~ kill last Allowed. Normal case. For variable ‘Bill’, the define-use-kill patterns are
• ~ define : normal case
2.2. Static Data-flow Testing • define-define: suspicious
• define-use : normal case
With static analysis, the source code is analyzed • use-define : acceptable
without executing it [6]. Let us consider an example of an • use-use : normal case
application to calculate the bill of a cellular service • use-kill : normal case
customer depending upon on his/her usage. The following
calculates ‘Bill’ as per ‘Usage’ with the following rules

NCSU CSC TR-2006-22 -2-

www.jntuworld.com

The static data-flow testing for the given application 0. Start

discovered the following anomaly:
Bill: define – define 1. define Bill

Why Static Data-flow testing is not enough?

Static Data-flow testing will fail in situations where 2. Y 3. define Bill

the state of a data variable cannot be determined by just
analyzing the code. This is possible when the data
variable is used as an index for a collection of data Y

elements. For example, in case of arrays, the index might

be generated dynamically during execution hence we 4. 5.
can’t guarantee what the state of the array element is
which is referenced by that index. Moreover, the static
data-flow testing might denote a certain piece of code to N N

be anomalous which is never executed and hence not

completely anomalous [7]. N 7. 6. use Bill
use Bill define Bill
Y
0. Start
Y
N
8. use Bill
1. Bill = 0 define Bill

9. use Bill
10. use Bill
define Bill

2.
Y 3. Bill = 40 11. Kill Bill
Usage > 0

Figure 2. Annotated control flow diagram for ‘Bill’

Y
Table 3: Static analysis for variable ‘Bill’
4. 5. Anomaly Explanation
Usage > 100 Usage < 200
~d 0-1 Allowed. Normal case
dd 0-1-2-3 Potential bug. Double definition.
N N du 3-4-5-6 Allowed. Normal case.
ud 6 Allowed. Data is used and then
6. Bill = Bill + 50 +
7.
(Usage – 200) * redefined.
N Bill > 100
0.1 uk 10-11 Allowed.
Y
dd 1-2-3 Potential bug. Double definition.
Y
N uu 7-8 Allowed. Normal case.
8. Bill = Bill + 0.9
k~ 11 Allowed. Normal case.
9. Bill = Bill +
10. return Bill
(Usage - 100) * 0.5 Referring to Table 3, we observe that static data-flow
testing for variable ‘Bill’ discovered the following usage
11. End 0-1-2-3 as a potential bug.

Figure 1. Control flow Diagram

NCSU CSC TR-2006-22 -3-

www.jntuworld.com

0. define Usage All-du paths (ADUP)

Formal Definition
1.
‘Every du path from every definition of every variable to
every use of that definition’ [7].
It is the strongest data-flow testing strategy since it is a
superset of all other data flow testing strategies.
2. Moreover, this strategy requires greatest number of paths
Y 3.
use Usage
for testing.

Y All-Uses (AU)
Formal Definition
4. 5. ‘At least one path from every definition of every variable
use Usage use Usage
to every use of that can be reached by that definition’ [7].

N N For every use of the variable, there is a path from the

definition of that variable to the use.
N 7. 6. use Usage
Y All-p-uses (APU)
Formal Definition
Y
N ‘APU Strategy is derived from APU+C by dropping the
8. requirement of including a c-use if there are no p-use
instances following the definition’ [7].
10. 9. use Usage
In this testing strategy, for every variable, there is path
11. kill Usage
from every definition to every p-use of that definition. If
there is a definition with no p-use following it, then it is
Figure 3. Annotated control flow diagram for ‘Usage’ dropped from contention.

Table 4: Static analysis for variable ‘Usage’ All-c-uses (ACU)

Anomaly Explanation Formal Definition
~d 0 Allowed. ‘ACU Strategy is derived from ACU+P by dropping the
du 0-1-2 Allowed. Normal case. requirement of including a p-use if there are no c-use
uk 9-10-11 Allowed. instances following the definition’ [7].
uu 5-6 Allowed. Normal case.
k~ 11 Allowed. Normal case. In this testing strategy, for every variable, there is a path
from every definition to every c-use of that definition. If
Referring to Table 4, we observe that static data-flow there is a definition with no c-use following it, then it is
testing for variable ‘Usage’ did not discover any bugs. dropped from contention.

All-p-uses/Some-c-uses (APU+C)
Formal Definition
2.3. Dynamic Data-flow Testing ‘For every variable and every definition of that variable,
include at least one path from the definition to every
The primary purpose of dynamic data-flow testing is to predicate use; if there are definitions of the variable that
uncover possible bugs in data usage during the execution are not covered then add computational use test cases as
of the code. To achieve this, test cases are created which required to cover every definition’ [7].
trace every definition to each of its use and every use is
traced to each of its definition. Various strategies are In this testing strategy, for every variable, there is a path
employed for the creation of the test cases [4][5]. The from every definition to every p-use of that definition. If
definition of all strategies is followed by an example to there is a definition with no p-use following it, then a
explain the same. c-use of the definition is considered.

NCSU CSC TR-2006-22 -4-

www.jntuworld.com

All-c-uses/Some-p-uses (ACU+P) Let us consider our billing application and perform

Formal Definition dynamic data-flow testing. The control flow graph is
‘For every variable and every definition of that variable, annotated for each variable (Figure 4 and Figure 5) by
include at least one path from the definition to every removing references to all other variables and replacing
computational use; if there are definitions of the variable the contents of the nodes with ‘def’ for definition, ‘c-use’
that are not covered then add predicate use test cases as for computational use and ‘p-use’ for predicate use. The
required to cover every definition’ [7]. testing strategies are then applied to the annotated control
flow graphs and test cases are derived. Table 5 presents
In this testing strategy, for every variable, there is a path the list of test paths for variables ‘Bill’ and ‘Usage’ of the
from every definition to every c-use of that definition. Ibf billing application.
there is a definition with no c-use following it, then a
p-use of the definition is considered.

All-definition (AD)
Formal Definition
‘Every definition of every variable be covered by at least
one use of that variable, be that use a computational use
or a predicate use’.

In this strategy, there is path from every definition to at

least one use of that definition.

0. def

1.

2.
Y 3.
p - use

4. 5.
p - use p - use

N 7. 6. c - use

Y
N
8.

10. 9. c - use

11.

Figure 4.Annotated Control Flow diagram for Figure 5.Annotated Control Flow diagram for
variable ‘Bill’ variable ‘Usage’

NCSU CSC TR-2006-22 -5-

www.jntuworld.com

Table 5: Data-flow testing paths for each variable In case of All c-uses/Some p-uses, we observe that the
Strategy Bill Usage paths are similar to All c-uses since every definition has a
All uses 3-4-5-6 0-1-2 corresponding c-use.
(AU) 6-7 0-1-2-3-4 In case of All p-uses/Some c-uses, definitions in 8 and 9
6-7-8 0-1-2-3-4-5 don’t have a corresponding p-use, hence c-use in 10 is
8-10 0-1-2-3-4-5-6 considered.
3-4-5-9 0-1-2-3-4-5-9 For All uses, we trace a path to all the uses (c-use and p-
use).
All p – uses 1-2-3-4-5-6-7 0-1-2
(APU) 3-4-5-6-7 0-1-2-3-4 2.4. Ordering of Strategies
6-7 0-1-2-3-4-5
For selection of test cases, we need to analyze the
relative strength of the data-flow testing strategies. Figure
All c – uses 1-2-10 0-1-2-3-4-5-6 6 depicts the relative strength of the data-flow strategies
(ACU) 3-4-5-6 0-1-2-3-4-5-9 and other control-flow testing strategies such as all-
3-4-5-9 branch and all-statement. According to the figure, the
3-4-10 strength of testing strategies reduces along the direction
6-7-8 of the arrow. Hence ALL PATHS is the strongest testing
6-7-10 strategy. Also note that ACU+P and APU+C run parallel
8-10 hence they are comparable [7].
9-10
All p – use/ 1-2-3-4-5-6-7 0-1-2
some c 3-4-5-6-7 0-1-2-3-4
(APU + C) 6-7 0-1-2-3-4-5
8-10
9-10 ALL PATHS

All c – use/ 1-2-10 0-1-2-3-4-5-6

ALL DU PATHS
some p 3-4-5-6 0-1-2-3-4-5-9
(ACU + P) 3-4-5-9
ALL USES
6-7-8
8-10
ALL – C / SOME - P ALL – P / SOME - C
9-10
All du (ACU+P) + (ACU+P) + ALL – C USES ALL – P USES
ALL DEFS
(ADUP) (APU+C) (APU+C)
BRANCH

STATEMENT

All definition 1-2-10 0-1-2

(AD) 3-4-5-6 Figure 6. Relative Strength of Testing Strategies [7]
6-7
8-10
3. Test Case Creation
9-10
After obtaining the test paths, test cases are created by
giving values to the input parameter (‘Usage’ for
In Table 5 for variable ‘Bill’: application considered). We obtain different test suites for
Path 1-2-10 depicts an all-definition path from definition each variable. For the application considered, we get 2
in 1 to c-use in 10. test suites for ‘Bill’ and ‘Usage’ respectively.
For All c-uses, we trace a path for every definition of Bill
to at least one c-use and a path tracing from every c-use
to its definition.
The same applies for All p-uses.

NCSU CSC TR-2006-22 -6-

www.jntuworld.com

Table 6. Test Suite for variable ‘Bill’ Table 7. Test Suite for variable ‘Usage’
Input Input
Expected Expected
Uses Bill Usage Uses Usage Usage
Value Value
Value Value
All 1-2-10 0 0.0 All definition 0-1-2 0 0.0
definition 3-4-5-6 220 92.0 (AD)
(AD) 6-7 220 92.0
8-10 350 94.5 All c – use 0-1-2-3-4- 220 92.0
9-10 220 92.0 (ACU) 5-6 170 75.0
All c – use 1-2-10 0 0.0 0-1-2-3-4-
(ACU) 3-4-5-6 220 92.0 5-9
6-7-8 350 94.5 All p – use 0-1-2 0 0.0
8-10 350 94.5 (APU) 0-1-2-3-4 170 75.0
9-10 220 92.0 0-1-2-3-4-5 170 75.0

All p – use 1-2-3-4-5-6-7 220 92.0

(APU) 3-4-5-6-7 220 92.0 All c - use + 0-1-2-3-4- 220 92.0
6-7 220 92.0 p (ACU + P) 5-6 170 75.0
0-1-2-3-4-
5-9
All c - use 1-2-10 0 0.0 All p - use + 0-1-2 0 0.0
+p 3-4-5-6 220 92.0 c (APU + C) 0-1-2-3-4 170 75.0
(ACU + P) 3-4-5-9 170 75.0 0-1-2-3-4-5 170 75.0
6-7-8 350 94.5
8-10 350 94.5
9-10 170 75.0 All uses 0-1-2 0 0.0
All p - use 1-2-3-4-5-6-7 220 92.0 (AU) 0-1-2-3-4 170 75.0
+c 3-4-5-6-7 220 92.0 0-1-2-3-4-5 170 75.0
(APU + C) 6-7 220 92.0 0-1-2-3-4- 220 92.0
8-10 350 94.5 5-6 170 75.0
9-10 170 75.0 0-1-2-3-4-
5-9

All uses 3-4-5-6 220 92.0 4. Conclusion

(AU) 6-7 220 92.0
6-7-8 350 94.5 We have presented a literature survey of data-flow
8-10 350 94.5 testing concentrating on data-flow testing criteria and
3-4-5-9 170 75.0 data-flow testing anomalies. We have presented the
concept with the help of a billing application that bills
mobile customers as per their usage. Finally, we provided
the test cases created after performing data-flow testing
on the considered application.

NCSU CSC TR-2006-22 -7-

www.jntuworld.com

5. References 6. Appendices

[1] Tsai, B.-Y.; Stobart, S.; Parrington, N.; “Employing data Appendix A: Glossary
flow testing on object-oriented classes”, Software, IEEE
Proceedings, USA, April 2001, p 56-64-87.
Black-box testing – The use of specifications of a unit,
[2] Harrold M Jean.; Rothermel Gregg.; “Performing data flow subsystem, or system to design tests. It is synonymous
testing on classes”, ACM SIGSOFT Software Engineering with specification-based testing or functional testing. [8]
Notes , Proceedings of the 2nd ACM SIGSOFT symposium on
Foundations of software engineering SIGSOFT’94, December Branch coverage – Branch coverage is achieved when
1994, pp 154 - 163. every path from a control flow graph node has been
executed at least once by a test suite. [8]
[3] Chang Liu; “Teaching “Data Flow Testing” in an Software
Engineering Course”, School of Electrical Engineering and
Computer Science, Russ College of Engineering and
Data-Flow Anomaly – A data-flow anomaly is denoted
Technology, Ohio University. by a two-character sequence of actions [7].

[4] Rapps, Sandra, Elaine J. Weyuker; “Data Flow Analysis Data-Flow Testing – It selects paths through the
Techniques for Test Data Selection”, Sixth International program’s control flow in order to explore sequences of
Conference on Software Engineering, Tokyo, Japan, September events related to the status of data objects [7].
13-16, 1982.
State - The state of an object can be defined as a set of
[5] Parrish, A.S.; Zweben, S.H.; “On the relationships among
instance variable value combinations that share some
the all-uses, all-DU-paths, and all-edges testing criteria”,
Software Engineering, IEEE Transactions, 1995, p 1006-1009.
property of interest. [8]

Statement coverage – Coverage achieved when all the

[6] Lee Copeland, “A Practitioner’s Guide to Software Test
Design”, STQE Publishing, 2004. statements in a method have been executed at least once.
[8]
[7] Boris Beizer, “Software Testing Techniques”, International
Thomson Computer Press, 1990. Test case – A set of inputs, execution conditions, and
expected results developed for a particular objective [8].
[8] Robert V. Binder, “Testing Object-Oriented Systems
Models, Patterns and Tools”, Addison-Wesley, 2000. Testing – The process of operating a system or
component under specified conditions, observing or
[9] IEEE Standard 610.12-1990, IEEE Standard Glossary of
recording the results, and making an evaluation of some
Software Engineering Terminology, Technical Report, IEEE,
1990 aspect of the system or component [8].

Test suite – A related collection of test cases [8].

White-box testing – The use of source-code analysis to

develop test cases. It is synonymous with program-based
testing or structural testing [8].

NCSU CSC TR-2006-22 -8-