1. Examining Variables on Flow Paths
Data Flow Analysis
Examining Variables on Flow Paths
See paper: An Introduction to Data-Flow Testing by Janvi Badlaney Rohit Ghatol Romit Jadhwani
This should follow the Flow_graph presentation, although not necessarily immediately after
Copyright © Curt Hill

2. Introduction The purpose of the Data Flow Analysis is to:
Examine the life cycle of variables – definition through use through deletion
Find numerous type of errors
Very commonly use in compilers
We use as a form of white box testing
This presentation considers these topics
Copyright © Curt Hill

3. Compilers They use data flow for optimization
Dead code elimination
Code motion
Moving code out of loop
Strength reduction
Using a faster less general operation
Constant propagation
Common sub-expression elimination
In testing we use to find certain classes of errors
Copyright © Curt Hill

4. Once Again The purpose of testing is to:
Reveal defects in the code
Portions of the requirements that are not implemented or done properly
Data Flow Analysis can lead us to generate test data that will help this
Yet be smaller than every path
This is a form of white box testing
Copyright © Curt Hill

5. Data Flow Analysis
In data flow testing we consider the lifecycle of variables along a path
A definition of a variable is any statement that sets the variable to a new value
A use is any statement that access the value of the variable
Some distinguish between use in a predicate and use in a computation
Copyright © Curt Hill

6. Continued
We are now interested in definition use chains for a variable
AKA DU chain
A DU chain is a path of statements starting with a definition and ending with a use
A DU chain may contain other chains since a variable may be used several times along the path
One test data strategy is to cover every DU chain in a program
Copyright © Curt Hill

7. Potential Errors
We would like Data Flow testing to find these kinds of errors:
A variable that is defined but never used in a significant way
A variable that is used but has no valid initialization
A variable that is defined multiple times before it is used
A dynamic variable destroyed before it is used
Copyright © Curt Hill

8. Process
We typically construct a data flow graph of one sort or another
We then decorate this flow diagram with letters indicating how variables are handled:
d indicates a definition
u indicates a usage
k indicates killing the variable
Such as a delete on a pointer
~ indicates we do not care about prior or trailing actions
Copyright © Curt Hill

9. Alternative process
The flow graph is visually helpful, but harder to construct
A listing with cross reference can also be used
We then create a table of the data flow chains
Copyright © Curt Hill

10. Data Flow Chain A data flow chain is a triple
The original letter (or ~) of the chain
The final letter (or ~) of the chain
The path
Path is usually a sequence of numbered nodes that are executed
We may leave out some of the intermediate nodes if they do not matter
Path only contains references to a variable at the begin and end
Copyright © Curt Hill

11. Triple Example on Variable a
1: int a;
2: cin >> a;
3: if(b > 0)
4: b += a;
5: else
6: c = a+b;
7: a = d;
8: return a;
Pair
Path ~d
1,2 du
2,3,4
2,3,6 ud
4,7
6,7
7,8 u~ 8
Copyright © Curt Hill

12. Anomalies There are numerous combinations of these four symbols
Some are acceptable and normal, others are errors and some may be either one
We are only interested in pairs:
A path that starts with one reference to a variable and ends with another
No references in between
Next screen considers the combinations
Copyright © Curt Hill

13. Table 1 of 2 Pair Name Details ~d First define OK du Define use
Normal - OK dk
Define kill
Data is killed without use ~u
Use w/o define
No definition (not necessarily declaration). This is an error. ud
Use define
Defined after use. OK. This just means a new value is given to the variable. uk
Use kill ~k
First kill
Data is killed before definition. Usually a bug
Copyright © Curt Hill

14. Table 2 of 2 Pair Name Details ku Kill use Used after killed. Error.kd
Kill define
OK. Data is killed and then redefined dd
Define define
Double definition. Potentially an error, but may be OK. uu
Use use
OK. This is a normal case. kk
Kill kill
Potentially an error. d~
Use last
Potentially an error u~ OK k~
Kill last
Normal case
Copyright © Curt Hill

15. Example Let’s consider calculation of a bill
There are three major cases based on the (integer) amount of usage
Usage
Bill amount
< 100
40.00
for every additional unit
> 200
for every additional unit
Copyright © Curt Hill

16. Code double CalculateBill (int Usage){ double Bill = 0;
if(Usage > 0)
Bill = 40;
if(Usage > 100){
if(Usage <= 200)
Bill = Bill + (Usage - 100) * 0.5;
else {
Bill = Bill (Usage - 200) * 0.1;
if(Bill >= 100)
Bill = Bill * 0.9;
} // else
} // outer if
return Bill; }
From ftp://ftp.ncsu.edu/pub/tech/2006/TR pdf
Copyright © Curt Hill

17. Flow Diagram (Bill) D 1 2 D 3 4 5 7 U D U D 6 9 U D 8 U 10 K 11
Copyright © Curt Hill

18. Paths D 1 2 D 3 4 5 7 U D U 6 9 D U D 8 U 10 K 11 Type Path DD 1,2,3
Double definition DU
3,4,5, 6
Normal UD 6 UK
10,11 UU
7,8 D 1 2 D 3 4 5 7 U D U D 6 9 U D
Not quite right 8 U 10 K 11
Copyright © Curt Hill

19. Path Combinations ~D, DU, UU and UK are normal
Most others are suspicious or errors
A few are syntax errors
DD is a double definition
May indicate but not guarantee an error
DK or D~ defined without any use
~U indicates use before definition
Error if path is achievable
KU and KK indicates an error
Dangling pointer or syntax error
Copyright © Curt Hill

20. Example Now we look at a bad routine
It has a number of undesirable path combinations
Consider the next three screens
Copyright © Curt Hill

21. 1 AClass * P, * Q = new AClass(); 2 if(R != NULL) 3 P = R;
int fn(AClass * R){
1 AClass * P, * Q = new AClass();
2 if(R != NULL)
3 P = R;
4 if(Q->OK())
5 P->Fix();
6 if(Q->OK())
7 Q = new AClass(*R);
8 if(P->OK()){
9 delete P;
10 P = NULL;
11 }
12 AClass * T = Q;
13 Q->Fix();
14 R->Mod(*Q);
15 delete P;
16 delete Q; }
Copyright © Curt Hill

22. P 1, 2, 3 ~D 1,2,4,5 ~U 3,4,6,8 DU 8,9 UK 9,15 KK int fn(AClass * R){
1 AClass * P, * Q = new AClass();
2 if(R != NULL)
3 P = R;
4 if(Q->OK())
5 P->Fix();
6 if(Q->OK())
7 Q = new AClass(*R);
8 if(P->OK()){
9 delete P;
10 P = NULL;
11 }
12 AClass * T = Q;
13 Q->Fix();
14 R->Mod(*Q);
15 delete P;
16 delete Q; } P
1, 2, 3 ~D
1,2,4,5 ~U
3,4,6,8 DU
8,9 UK
9,15 KK
Copyright © Curt Hill

23. Q T 1, 4 DU 1, 6, 7 DD 13, 16 UK 12, 16 D~ int fn(AClass * R){
1 AClass * P, * Q = new AClass();
2 if(R != NULL)
3 P = R;
4 if(Q->OK())
5 P->Fix();
6 if(R->OK())
7 Q = new AClass(*R);
8 if(P->OK()){
9 delete P;
10 P = NULL;
11 }
12 AClass * T = Q;
13 Q->Fix();
14 R->Mod(*Q);
15 delete P;
16 delete Q; } Q
1, 4 DU
1, 6, 7 DD
13, 16 UK T
Q memory leak
12, 16 D~
There are more than shown
Copyright © Curt Hill

24. Test Generation
Data flow analysis should lead us to develop test cases
Often the flows give us something better than basis path testing with fewer tests than every path
A path is only interesting if data flow suggests variable interaction
Copyright © Curt Hill

25. Recall This Two paths provide a basis path set
1, 2, 4, 5, 7
1, 3, 4, 6, 7
Clearly four distinct paths
Yet if there if there is no DU chain involving 3 and 5 or 2 and 6, then these two paths are adequate 1 3 2 4 6 5 7
Copyright © Curt Hill

26. Static Analysis Data flow analysis is a form of static analysis
The Halting problem shows static analysis cannot find all problems
Dead code is one of these
There may be error paths that are not possible to actually execute
Arrays and dynamic data structures are problematic because of one name with many values
Copyright © Curt Hill

27. Data Flow Strategies All DU Paths (ADUP) All Uses (AU)
Every DU path of every variable is exercised
All Uses (AU)
For each variable, at least one path from every definition to every use
Need an example of this one
Copyright © Curt Hill

28. What DU paths? cin >> x >> y; for(int i = 0;i< 2; i++)
cout << “Hello\n”;
cout << “Some statements\n”;
if(y<0)
cout << “More statements\n”;
else
cout << x << “\n”;
Copyright © Curt Hill

29. Finally Data flow analysis can be done both manually and automatically
Usually in the course of debugging and code review
Automatically
Part of a compiler or static analyzer
Copyright © Curt Hill