Overview

Structural Testing
Introduction – General Concepts
Flow Graph Testing
Data Flow Testing
Definitions
Some Basic Data Flow Analysis Algorithms
Define/use Testing
Slice Based Testing
Guidelines and Observations

1
 Data Flow Testing – Basic Idea

• Data flow testing is an unfortunate term

because it suggests some connection with dataflow
diagrams; but no connection exists.

• Data flow testing refers to forms of structural

testing that focus on the points at which
variables receive values and the points at
which these values are used.

• Data-flow testing involves selecting entry/exit

paths with the objective of covering certain data
definition and use patterns, commonly known
as data-flow criteria 2
 Data Flow Testing – Basic Idea

• An outline of data-flow testing is as follows:

– Draw a data flow graph for the program

– Select data-flow testing criteria

– Identify paths in the data-flow graph to satisfy the

selection criteria (i.e. all-defs, all-uses,
all-P-uses/some-C-uses etc.)

– Produce test cases for the selected paths

3
 Data Flow Testing – Basic Idea

•Early data flow analyses often centered on a set of

faults that are now known as define/reference
anomalies,

– A variable that is defined but never used.

– A variable that is used before it is defined.

– A variable that is defined twice before it is used.

Each of these anomalies can be recognized from the

concordance of a program. The concordance is
compiler generated.
4
 Some Definitions
• Node n in the CFG of program P is a defining
node of the variable v V, written as DEF(v, n), iff
the value of the variable v is unambiguously defined
at the statement fragment corresponding to node n.

Example: Suppose we have a program P with the following

code:
1. x = 5;
2. y = x + 3;
3. z = y * 2;

The Control Flow Graph (CFG) of this program might look

like this:
Node 1: x = 5;
Node 2: y = x + 3;
Node 3: z = y * 2;
5
 Some Definitions
According to the definition, we can say:-

•DEF(x, 1) because the value of x is unambiguously

defined at Node 1.
•DEF(y, 2) because the value of y is unambiguously
defined at Node 2.
•DEF(z, 3) because the value of z is unambiguously
defined at Node 3.

In other words, each node in the CFG where a variable is

assigned a value is considered a defining node for that
variable.

6
 Some Definitions
• Node n in the CFG of program P is a usage node of
 v V, written as USE(v, n), iff the value
the variable
of the variable v is used at the statement fragment
corresponding to node n.

• Example: Suppose we have a program P with the following

code:
1. x = 5;
2. y = x + 3;
3. z = y * 2;
4. print(z);
The Control Flow Graph (CFG) of this program might look like
this:
1. Node 1: x = 5;
2. Node 2: y = x + 3;
3. Node 3: z = y * 2;
7
4. Node 4: print(z);
 Some Definitions

According to the definition, we can say:-

•USE(x, 2) because the value of x is used at Node 2.

•USE(y, 3) because the value of y is used at Node 3.
•USE(z, 4) because the value of z is used at Node 4.

•In other words, each node in the CFG where a variable's

value is used (e.g., in an expression or as an argument) is
considered a usage node for that variable.

8
 Some Definitions
• A usage node USE(v, n), is a predicate use
(denoted as P-use) iff, the statement n is a
predicate statement, otherwise USE(v, n) is a
computation use or C-use.

Example: Suppose we have a program P with the

following code:
1. x = 5;
2. y = x + 3;
3. if (y > 10) {
4. z = y * 2;
5. } else {
6. z = y - 2;
7. }
8. print(z);
9
 Some Definitions
The Control Flow Graph (CFG) of this program might look like
this:
1. Node 1: x = 5;
2. Node 2: y = x + 3;
3. Node 3: if (y > 10)
4. Node 4: z = y * 2;
5. Node 5: else
6. Node 6: z = y - 2;
7. Node 7: end if
8. Node 8: print(z);
According to the definition:-
USE(y, 3) is a P-use (predicate use) because Node 3 is a
predicate statement (if statement).
USE(y, 4) and USE(y, 6) are C-uses (computation uses)
because Nodes 4 and 6 are computation statements
(assignment statements).

In other words, a usage node is classified as a P-use if the

variable is used in a predicate statement (e.g., if, while,
switch), and as a C-use if the variable is used in a computation
10
statement (e.g., assignment, arithmetic operation).
 Some Definitions
• The nodes corresponding to predicate uses have
always an outdegree ≥ 2, and nodes
corresponding to computation uses always have
outdegree ≤ 1.

The Control Flow Graph (CFG) of this program might

look like this:
1. Node 1: x = 5; (outdegree = 1)
2. Node 2: y = x + 3; (outdegree = 1)
3. Node 3: if (y > 10) (outdegree = 2)-->
4. Node 4: z = y * 2;-->
5. Node 5: else
6. Node 4: z = y * 2; (outdegree = 1)
7. Node 5: else (outdegree = 1)
8. Node 6: z = y - 2; (outdegree = 1)
9. Node 7: end if (outdegree = 1)
10. Node 8: print(z); (outdegree = 0)
11
 Some Definitions
According to the definition:-

Node 3 has an outdegree ≥ 2 (outdegree = 2),

corresponding to a predicate use (P-use).-

Nodes 1, 2, 4, 5, 6, 7, and 8 have outdegrees ≤ 1,

corresponding to computation uses (C-uses).

In other words, nodes with predicate uses (P-

uses) always have at least two outgoing edges
(outdegree ≥ 2), while nodes with computation
uses (C-uses) always have at most one outgoing
edge (outdegree ≤ 1).

12
 Some Definitions
• A definition-use (sub)path with respect to a
variable v (denoted as du-path) is a (sub)path in
PATHS(P), (where PATHS(P) is the set of all
possible paths in the CFG of program P,) such that,
for some v in V, there are define and usage nodes
DEF(v, m) and USE(v, n) such that m, and n are the
initial and final nodes in the path respectively.

Suppose we have a program P with the following code:

1. x = 5;
2. y = x + 3;
3. if (y > 10) {
4. z = y * 2;
5. } else {
6. z = y - 2;
7. }
8. print(z);
13
 Some Definitions
The Control Flow Graph (CFG) of this program might look like
this:
1.Node 1: x = 5;
2.Node 2: y = x + 3;
3.Node 3: if (y > 10)
4.Node 4: z = y * 2;
5.Node 5: else
6.Node 6: z = y - 2;
7.Node 7: end if
8.Node 8: print(z);

According to the definition:-

•A definition-use (du-)path for variable y is: Node 2 → Node 3 →

Node 4.
– DEF(y, 2) is the define node
– USE(y, 4) (or USE(y, 6)) is the usage node
14
 Some Definitions

• Another du-path for variable y is: Node 2 → Node 3

→ Node 5 → Node 6.

– DEF(y, 2) is the define node

– USE(y, 6) is the usage node

In both cases, the du-path starts at the define node

(Node 2) and ends at the usage node (Node 4 or
Node 6).

15
 Some Definitions
• A definition-clear (sub)path with respect to a
variable v (denoted as dc-path) is a definition-use
path in PATHS(P) with initial nodes DEF(v, m) and
USE(v, n) such that there no other node in the
path is a defining node for v.

Suppose we have a program P with the following code:

1. x = 5;
2. y = x + 3;
3. if (y > 10) {
4. z = y * 2;
5. } else {
6. z = y - 2;
7. }
8. y = 20; // new definition of y
9. print(z); 16
 Some Definitions
The Control Flow Graph (CFG) of this program might
look like this:
1. Node 1: x = 5;
2. Node 2: y = x + 3;
3. Node 3: if (y > 10)
4. Node 4: z = y * 2;
5. Node 5: else
6. Node 6: z = y - 2;
7. Node 7: end if
8. Node 8: y = 20;
9. Node 9: print(z);

According to the definition:-

A definition-clear (dc-)path for variable y is: Node 2 →

Node 3 → Node 4 (or Node 6)
DEF(y, 2) is the define node
USE(y, 4) (or USE(y, 6)) is the usage node
There are no other defining nodes for y in this path
17
 Some Definitions

•However, the path,

Node 2 → Node 3 → Node 4 (or Node 6) → Node 8
→ Node 9 is not a dc-path because Node 8 is
another defining node for y.

•In a dc-path, there must be no other defining

nodes for the variable between the initial
define node and the usage node.

18
 Some Definitions
• A global definition is a definition of a variable x
in node n if there is a definition of x in node n and
there is a definition-clear path from n to some node
m containing a global c-use of x, or containing a p-
use of x. Note x is live at n .
Suppose we have a program P with the following code:
1. x = 5; // global definition
2. y = x + 3;
3. if (y > 10) {
4. z = y * 2;
5. } else {
6. z = y - 2;
7. }
8. print(z); // global c-use of x (indirectly through y and z)
19
 Some Definitions
The Control Flow Graph (CFG) of this program might look like this:
1. Node 1: x = 5;
2. Node 2: y = x + 3;
3. Node 3: if (y > 10)
4. Node 4: z = y * 2;
5. Node 5: else
6. Node 6: z = y - 2;
7. Node 7: end if
8. Node 8: print(z);
According to the definition:-
•Node 1 is a global definition of x because:
There is a definition of x in Node 1.
There is a definition-clear (dc-)path from Node 1 to Node 8 (Node
1 → Node 2 → Node 3 → ... → Node 8).
Node 8 contains a global c-use of x (indirectly through y and z).

Note that x is live at Node 1 because its value is used later in the
program (indirectly through y and z). 20
 Some Definitions
• A global c-use of variable x in node n is a c-use of
variable x in node n and x has been defined in a
node other than n.
Example: Suppose we have a program P with the following code:
1. x = 5;
2. y = x + 3;
3. z = y * 2;
The Control Flow Graph (CFG) of this program might look like this:
1. Node 1: x = 5;
2. Node 2: y = x + 3;
3. Node 3: z = y * 2;
According to the definition:-
Node 2 contains a global c-use of variable x because:
There is a c-use of x in Node 2 (x is used in the expression x + 3).
x has been defined in Node 1, which is a node other than Node 2.

In other words, a global c-use occurs when a variable is used21in a

node, but its definition comes from a different node.
 Some Definitions
• Simple path is a path in which all nodes except
possibly the first and the last are distinct

• Loop free path is a path in which all nodes are

distinct

• Complete path is a path from the entry node to the

exit node of the CFG

• Du-Path with respect to variable x at node n 1 is a

path [n1, n2, …. nk] where n1 has a global definition of
x and either
– Node nk has a global c-use of x and [n 1….nk] is def-clear
simple path with respect to x or,
– Node nk has a p-use of x and [n1….nj] is a def-clear loop-
free path with respect to x
22
Definition / Use Associations - Example
What are the def-use associations for the
program below?

1 read (z)
2 x=0
3 y=0
4 if (z  0) {
5 x = sqrt (z)
6 if (0  x && x  5)
7 y = f (x)
else
8 y = h (z)
}
9 y = g (x, y)
10 print (y)

23
Definition / Use Associations - Example
def-use associations for
variable z.
read (z)
x=0
y=0
if (z  0)
{
x = sqrt (z)
if (0  x && x 
5)
y = f (x)
else
y = h (z)
}
y = g (x, y)
print (y) 24
 Definition / Use Associations -
Example
def-use associations for
variable y.
read (z)
x=0
y=0
if (z  0)
{
x = sqrt (z)
if (0  x && x 
5)
y = f (x)
else
y = h (z)
}
y = g (x, y)
print (y) 25
Example

26
27
28
29
30
31
32
33
34
35
 du-paths
• Du-paths for stocks.

• Du-paths for locks.

• Du-paths for totallocks.

• Du-paths for sales.

• Du-paths for commission.

36
 du-paths
Du-paths for stocks.

•First, let us look at a simple path:

•We have DEF(stocks, 15) and USE(stocks, 17), so

the path <15, 17> is a du-path with respect to
stocks.

•No other defining nodes are used for stocks;

therefore, this path is also definition clear.

37
 du-paths
Du-paths for locks.

•Two defining and two usage nodes make the locks

variable more interesting:

•We have DEF(locks,13), DEF(locks, 19), USE(locks,

14), and USE(locks, 16). These yield four du-paths.

– p1 = <13, 14>
– p2 = <13, 14, 15, 16>
– p3 = <19, 20, 14>
– p4 = <19, 20, 14, 15, 16>

38
 du-paths
Du-paths for locks.

39
 du-paths
Du-paths for totallocks.
•The du-paths for totalLocks will lead us to typical test
cases for computations.

•With two defining nodes (DEF(totalLocks, 10) and

DEF(totalLocks, 16)) and three usage nodes
(USE(totalLocks,16), USE(totalLocks, 21), USE(totalLocks,
24)), we might expect five du-paths.

•Path p5 = <10, 11, 12, 13, 14, 15, 16> is a du-path in

which the initial value of totalLocks (0) has a computation
use. This path is definition clear.

•The next path is problematic: p6 = <10, 11, 12, 13, 14,

15, 16, 17, 18, 19, 20, 14, 21>
40
 du-paths
Du-paths for totallocks.

•Path p6 ignores the possible repetition of the while loop.

•We could highlight this by noting that the subpath <16,

17, 18, 19, 20, 14, 15> might be traversed several times.

•Ignoring this for now, we still have a du-path that fails to

be definition clear.

•If a problem occurs with the value of totalLocks at node

21 (the Output statement), we should look at the
intervening DEF(totalLocks, 16) node.

41
 du-paths
Du-paths for totallocks.

•The next path contains p6; we can show this by using a

path name in place of its corresponding node sequence:

– p7 = <10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 14, 21,
22, 23, 24>
– p7 = <p6, 22, 23, 24>

Du-path p7 is not definition clear because it includes node

16.

42
 du-paths
Du-paths for totallocks.

•The remaining two du-paths are both subpaths of p7:

– p8 = <16, 17, 18, 19, 20, 14, 21>
– p9 = <16, 17, 18, 19, 20, 14, 21, 22, 23, 24>

•Both are definition clear, and both have the loop iteration
problem.

43
 du-paths
Du-paths for sales.

•There is one defining node for sales; therefore, all the du-
paths with respect to sales must be definition clear.

•They are interesting because they illustrate predicate

and computation uses.

•The first three du-paths are easy:

– p10 = <27, 28>
– p11 = <27, 28, 29>
– p12 = <27, 28, 29, 30, 31, 32, 33>
•Notice that p12 is a definition-clear path with three usage
nodes; it also contains paths p10 and p11.
44
Du-paths for sales.
du-paths
•The IF, ELSE IF logic in statements 29 through 40
highlights an ambiguity in the original research.

45
 du-paths
Du-paths for sales.

•Two choices for du-paths begin with path p11: one choice
is the path <27, 28, 29, 30, 31,32, 33>, and the other is
the path <27, 28, 29, 34>.

•The remaining du-paths for sales are

– p13 = <27, 28, 29, 34>
– p14 = <27, 28, 29, 34, 35, 36, 37>
– p15 = <27, 28, 29, 34, 38,39>

46
 du-paths
• Du-paths for commission.

• We decided to disallow du-paths from assignment

statements like 31 and 32, so we will just consider du-
paths that begin with the three “real” defining nodes:
DEF(commission, 33), DEF(commission, 37), and
DEF(commission, 39).
• Only one usage node is used: USE(commission, 41). 47
 DU-Path Test Coverage Criteria

• The three of these are equivalent to three of E.F.Miller’s metrics.

All-Paths, All-Edges and All-Nodes. 48
 DU-Path Coverage Criteria (1)
• The set T satisfies the All-Defs criterion for a program P
iff for every variable v in V, T contains definition
clear (sub)paths from every defining node of v to
a use of v.

Consider the Control Flow Graph (CFG),

Node 1: x = 5;
Node 2: y = x + 3;
Node 3: z = y * 2;
Node 4: x = 10;
Node 5: print(z);

• To satisfy the All-Defs criterion, the set T must contain

definition-clear (dc-)paths from every defining node of x
to a use of x.

• In this case:- There are two defining nodes for x: Node

49 1
and Node 4.- The uses of x are: Node 2.
 DU-Path Coverage Criteria (1)
• The set T must contain the following dc-paths:- Node 1 →
Node 2 and Node 4 → Node 2 is not possible, but Node 4
does not have a dc-path to any use of x.

• However, since Node 4 does not have a dc-path to any

use of x, the All-Defs criterion is not fully satisfied for the
variable x.

• If we modify the program to add a use of x after Node 4,

such as: 4. x = 10;5. y = x * 2; // new use of x

• Then the set T would contain the additional dc-path:-

Node 4 → Node 5.

• Now, the All-Defs criterion is satisfied for the variable x,

since T contains definition-clear paths from every
defining node of x to a use of x. 50
 DU-Path Coverage Criteria (1)
• The set T satisfies the All-Uses criterion for the
program P iff for every variable v in V, T
contains definition-clear (sub)paths from
every defining node of v to every use of v,
and to the successor node of each USE(v, n).

The Control Flow Graph (CFG):

Node 1: x = 5;
Node 2: y = x + 3;
Node 3: z = y * 2;
Node 4: print(z);

• To satisfy the All-Uses criterion, the set T must

contain definition-clear (dc-)paths from every
defining node of x to:
-Every use of x (Node 2)
51
-The successor node of each use of x (Node 3)
 DU-Path Coverage Criteria (1)
• In this case:
- The defining node for x is Node 1.
- The use of x is Node 2.
- The successor node of the use of x is Node 3.

• The set T must contain the following dc-paths:

- Node 1 → Node 2 (dc-path from defining node to use
of x)
- Node 1 → Node 2 → Node 3 (dc-path from defining
node to successor node of use of x)

• If T contains these dc-paths, then the All-Uses

criterion is satisfied for the variable x.

• Note that if there were multiple uses of x, T would

need to contain dc-paths from the defining node 52to
each use and its successor node.
 DU-Path Coverage Criteria (2)
• The set T satisfies the All-P-Uses/Some-C-Uses criterion
for a program P iff for every variable v in V, T contains
definition-clear (sub)paths from every defining
node of v to every p-use of v, and if a definition of v
has no p-uses, there is a definition-clear path to at
least one c-use
• Control Flow Graph (CFG):
Node 1: x = 5;
Node 2: if (x > 10)
Node 3: y = x + 3;
Node 4: else
Node 5: y = 20;
Node 6: end if
Node 7: print(y);

• To satisfy the All-P-Uses/Some-C-Uses criterion, the set T

must contain:
- Definition-clear (dc-)paths from every defining node of x to every p-
use of x (Node 2)
- If a definition of x has no p-uses, a dc-path to at least one c-use of x
(Node 3) 53
 DU-Path Coverage Criteria (2)
In this case:
-The defining node for x is Node 1.
-The p-use of x is Node 2.
-The c-use of x is Node 3.

•The set T must contain the following dc-paths:

-Node 1 → Node 2 (dc-path from defining node to p-use
of x)
-Node 1 → Node 2 → Node 3 (dc-path from defining node
to c-use of x)

•If T contains these dc-paths, then the All-P-Uses/Some-

C-Uses criterion is satisfied for the variable x.

•Note that if there were no p-uses of x, T would only

need to contain a dc-path from the defining node to at
least one c-use of x.
54
 DU-Path Coverage Criteria (2)
• The set T satisfies the All-C-Uses/Some-P-Uses
criterion for a program P iff for every variable v in V,
T contains definition-clear (sub)paths from every
defining node of v to every c-use of v, and if a
definition of v has no c-uses, there is a definition-
clear path to at least one p-use
• Control Flow Graph (CFG):
Node 1: x = 5;
Node 2: y = x + 3;
Node 3: if (y > 10)
Node 4: z = y * 2;
Node 5: else
Node 6: z = 20;
Node 7: end if
Node 8: print(z);
• To satisfy the All-C-Uses/Some-P-Uses criterion, the set T
must contain:
-Definition-clear (dc-)paths from every defining node of x to
every c-use of x (Node 2)
-If a definition of x has no c-uses, a dc-path to at least one p-
use of x (Node 3) 55
 DU-Path Coverage Criteria (2)
• In this case:
- The defining node for x is Node 1.
- The c-use of x is Node 2.
- The p-use of x is Node 3 (indirectly through y).

• The set T must contain the following dc-paths:

- Node 1 → Node 2 (dc-path from defining node to c-use of
x)
- Node 1 → Node 2 → Node 3 (dc-path from defining node
to p-use of x)

• If T contains these dc-paths, then the All-C-Uses/Some-P-

Uses criterion is satisfied for the variable x.

• Note that if there were no c-uses of x, T would only need

to contain a dc-path from the defining node to at least
one p-use of x.
56
 DU-Path Coverage Criteria (2)
• The set T satisfies the All-DU-Paths criterion for the
program P iff for every variable v in V, T contains
definition-clear (sub)paths from every defining
node of v to every use of v, and to the successor
node of each USE(v, n), and that these paths are
either single-loop or cycle-free.
• Control Flow Graph (CFG):
Node 1: x = 5;
Node 2: while (x > 0)
Node 3: y = x + 3;
Node 4: x = x - 1;
Node 5: end while
Node 6: print(y);
• To satisfy the All-DU-Paths criterion, the set T
must contain:
- Definition-clear (dc-)paths from every defining node
of x to every use of x (Node 3 and Node 4)
- Definition-clear paths to the successor node of each
use of x (Node 6)
- These paths must be either single-loop or cycle-free
57
 DU-Path Coverage Criteria (2)
• In this case:
- The defining node for x is Node 1.
- The uses of x are Node 3 and Node 4.
- The successor node of the use of x is Node 6.

• The set T must contain the following dc-paths:

- Node 1 → Node 2 → Node 3 (dc-path from defining
node to use of x)
- Node 1 → Node 2 → Node 4 (dc-path from defining
node to use and definition of x)
- Node 1 → Node 2 → Node 5 → Node 6 (dc-path from
defining node to successor node of use of x)

• These paths are cycle-free, so the All-DU-Paths

criterion is satisfied for the variable x.

• Note that if there were cycles in the paths (e.g.,

Node 2 → Node 4 → Node 2), the criterion would
not be satisfied unless the cycles were single-loop
58
(i.e., the cycle has only one edge).
 Slicing
• The notion of a program slice is useful in software testing,
for program debugging, automatic parallelization, and
program integration.

• A slice of a program is taken with respect to a program

point P and a variable x.

• The slice is a set of program statements that may

affect the value x at program point P. The tuple <P, x>
is called a slicing criterion.

• A Forward Slice of a program with respect to a program

point P and variable x consists of all statements of the
program that may be affected by the value of x at point
P.

• One way to compute a slice is by constructing a Program

Dependence Graph (PDG) and then appropriately traverse
this graph. 59
 Motivation
Static Slicing

• Program reduction technique

• Useful for program comprehension,
debugging, maintenance, reuse, etc.
• Based on control and flow graph
dependencies 60
 Slicing using Control Flow Graphs
• Given a program P, and a set V of variables in P, a slice
on the variable set V at statements n, written as
S(V, n), is the set of all statements P prior to node
n that contribute to the values of variables in V at
node n.

• Suppose we have a program P with the following code:

1. x = 5;
2. y = x + 3;
3. z = y * 2;
4. if (z > 10) {
5. w = z - 5;
6. print(w);
7. }

• Let's say we want to compute a slice on the variable set

V = {z} at statement 5, written as S({z}, 5).

• To compute this slice, we need to find all statements in

61 P
prior to node 5 that contribute to the value of z at node 5.
 Slicing using Control Flow Graphs

In this case:
-Node 3 assigns a value to z, which is used at node 5.
-Node 2 assigns a value to y, which is used to compute z at
node 3.
-Node 1 assigns a value to x, which is used to compute y at
node 2.

Therefore, the slice S({z}, 5) includes the following

statements:
-Node 1: x = 5;
-Node 2: y = x + 3;
-Node 3: z = y * 2;

These statements contribute to the value of z at node 5.

62
 Slicing using Control Flow Graphs
• Given a program P, and a program graph G(P) in which
statements and statement fragments are numbered,
and a set V of variables in P, the slice of the set of
variables V at statement fragment n, written as
S(V, n), is the set of node numbers of all
statement fragments in P prior to and including n
that contribute to the values of variables in V at
statement fragment n.

• Consider the program graph G(P):

Node 1: x = 5;
Node 2: y = x + 3;
Node 3: z = y * 2;
Node 4: if (z > 10)
Node 5: w = z - 5;
Node 6: print(w);
Node 7: end if

• Let's say we want to compute the slice of the set of

variables V = {w} at statement fragment 5, written 63as
S({w}, 5).
 Slicing using Control Flow Graphs
• To compute this slice, we need to find all node
numbers of statement fragments in P prior to and
including 5 that contribute to the value of w at
statement fragment 5.

In this case:
- Node 5 assigns a value to w.
- Node 4 is the conditional statement that controls
whether Node 5 is executed.
- Node 3 assigns a value to z, which is used in the
conditional statement at Node 4.
- Node 2 assigns a value to y, which is used to compute
z at Node 3.
- Node 1 assigns a value to x, which is used to compute
y at Node 2.

• Therefore, the slice S({w}, 5) includes the following

node numbers:- Node 1- Node 2- Node 3- Node 4- Node
5 These nodes contribute to the value of w 64at
statement fragment 5.
 Uses of Slices in Testing

• Test Case Generation: Slices can be used to generate test

cases by identifying the input values that affect the slice.
This helps ensure that the test cases cover all possible
scenarios.

• Test Case Reduction: Slices can be used to reduce the

number of test cases by eliminating unnecessary inputs
and focusing on the inputs that affect the slice.

• Fault Localization: Slices can be used to localize faults by

identifying the statements that contribute to the faulty
behavior. This helps developers focus their debugging
efforts on the relevant code.

• Regression Testing: Slices can be used to identify the parts

of the code that need to be retested after a change. This
helps ensure that the changes do not introduce new faults.
65
 Uses of Slices in Testing
• Test Oracle: Slices can be used to generate test oracles by
identifying the expected output values for a given input.

• Code Review: Slices can be used to support code review

by identifying the parts of the code that need to be
reviewed.

• Debugging: Slices can be used to support debugging by

identifying the statements that contribute to the faulty
behavior.

• Program Understanding: Slices can be used to support

program understanding by identifying the relationships
between different parts of the code.

By using slices in testing, developers can create more

effective test cases, reduce the number of test cases, and
improve the overall quality of the software.
66