Module-4

Path Testing, Dataflow Testing,

Levels of Testing, Decision Table
Testing
Introduction
• Path Testing is a method that is used to design the test cases.

• In the path testing method, the control flow graph of a program is designed to find a set
of linearly independent paths of execution.

• In this method, Cyclomatic Complexity is used to determine the number of linearly

independent paths and then test cases are generated for each path.

• It gives complete branch coverage but achieves that without covering all possible paths
of the control flow graph.

• McCabe’s Cyclomatic Complexity is used in path testing. It is a structural testing

method that uses the source code of a program to find every possible executable path.
Path Testing Process
• Control Flow Graph:
Draw the corresponding control flow graph of the program in which all the
executable paths are to be discovered.
• Cyclomatic Complexity:
After the generation of the control flow graph, calculate the cyclomatic
complexity of the program using the following formula.

McCabe's Cyclomatic Complexity = E - N + 2P

Where, E = Number of edges in the control flow graph

N = Number of vertices in the control flow graph
P = Program factor
• Make Set:
Make a set of all the paths according to the control flow graph and calculate
cyclomatic complexity.
• Create Test Cases:
Create a test case for each path of the set obtained in the above step.
Path Testing Techniques:

• Control Flow Graph (CFG) - The Program is converted into Flow graphs by
representing the code into nodes, regions and edges.

• Decision to Decision path (D-D) - The CFG can be broken into various
Decision to Decision paths and then collapsed into individual nodes.

• Independent (basis) paths - Independent path is a path through a DD-path

graph that cannot be reproduced from other paths by other methods.
• A program graph is a directed graph in which nodes are either entire statements or
fragments of a statement, and edges represent the flow of control.

• If i and j are nodes in the program graph, there is an edge from node i to node j iff
the statement (fragment) corresponding to node j can be executed immediately after
the statement (fragment) corresponding to node i.

• Constructing a program graph from a given program is an easy process. Line

numbers refer to statements and statement fragments.

• The groups of statements that make up a node in the Program Graph are called a
basic block.

• There is a straightforward algorithm to segment a code fragment into basic

blocks and create the corresponding Program Graph.
DD Paths
• The best-known form of structural testing is based on a construct known as a
decision-to decision path (DD-Path).
• The name refers to a sequence of statements that, in Miller’s words begins with
the “outway” of a decision statement and ends with the “inway” of the next
decision statement.
• We will define DD-Paths in terms of paths of nodes in a directed graph. We
might call these paths as chains, where a chain is a path in which the initial and
terminal nodes are distinct, and every interior node has indegree = 1 and
outdegree = 1.
A DD-Path is a sequence of nodes in a program graph such that:
• Case 1: It consists of a single node with indeg = 0.
• Case 2: It consists of a single node with outdeg = 0.
• Case 3: It consists of a single node with indeg ≥ 2 or outdeg ≥ 2.
• Case 4: It consists of a single node with indeg =1 and outdeg=1.
• Case 5: It is a maximal chain of length ≥ 1.

Example solved on board

Test Coverage Metrics
• Test coverage metrics are a device to measure the extent to which a set of test
cases covers a program.
• Having an organized view of the extent to which a program is tested makes it
possible to sensibly manage the testing process.
• Several widely accepted test coverage metrics are used; most of those are in
Table below (Miller, 1977).
• Most quality organizations now expect the C1 metric (DD-Path coverage) as the
minimum acceptable level of test coverage. Less adequate, the statement
coverage metric (C0) is still widely accepted
Metric –Based Testing
Statement and Predicate Coverage:
• Statement coverage-based testing aims to devise test cases that collectively
exercise all statements in a program – Co
• Predicate coverage (or branch coverage, or decision coverage) based testing aims
to devise test cases that evaluate each simple predicate of the program to True
and False - C1
– Here the term simple predicate refers to either a single predicate or a compound
Boolean expression that is considered as a single unit that evaluates to True or
False.
– For example, in predicate coverage, for the condition if (A or B) then C, we
could consider the test cases A=True, B= False (true case), and A=False, B=False
(false case).
Condition Testing - C1p:

• Decision coverage is good for exercising faults in the way a computation has
been decomposed into cases.
• A test suite T for a program P covers all C1P iff for each atomic condition in P, it
has at least two test cases in T: one forcing P to have a true out come and the
other one forcing P to have a false outcome.
Loop Coverage - C2:
• Test cases that exercise the two possible outcomes of the decision of a loop condition,
that is one to traverse the loop and the other to exit (or not enter) the loop.
• An extension would be to consider a modified boundary value analysis approach where
the loop index is given a minimum, minimum +, a nominal, a maximum-, and a
maximum value or even robustness testing.
• Once a loop is tested, then the tester can collapse it into a single node to simplify the
graph for the next loop tests. In the case of nested loops, we start with the innermost
loop and proceed outward
Dependent DD-Path Pairs Coverage - Cd
• two DD-Paths are said to be dependent iff there is a define/reference relationship
between these DD-Paths, in which a variable is defined (receives a value) in one
DD-Path and is referenced in the other.
• In Cd testing we are interested on covering all edges of the DD-Path graph and
all dependent DD-Path pairs.
Multiple (Compound) Condition Coverage – CMCC:
• CMCC, A more complete extension that includes both the basic condition and
branch adequacy criteria
• CMCC requires a test case T for each possible evaluation of compound
conditions.
• For N basic conditions, we need 2 N combinations of test cases are required.
• Short-circuit evaluation is effective in reducing the above number to a more
manageable number.
• For a compound predicate P1 (A or B), CMCC requires that each possible
combination of inputs be tested for each decision. Ex: if (A or B) requires, A =
True/False , B = True/False ( 4 Combinations of test cases)
Statistically Significant Path Coverage Testing –Cstat:
• The goal of statistically significant coverage is to develop methods for software
testing based on statistical methods, such as Multivariable Testing, Design of
Experiments, and Markov Chain usage models, and to develop methods for
software testing based on statistical measures and confidence levels.

Path testing - C∞(or P∞):

A test suite T for a program P satisfies the path adequacy criterion iff,
• for each path pi of P, there exists at least one test case in T that causes the
execution of pi.
• This is the same as stating that every path in the flow graph model of program P
is exercised by at least one test case in T.
Basis Path Testing
• Basis Path Testing is a white-box testing technique based on a program's or
module's control structure. A control flow graph is created using this structure,
and the many possible paths in the graph are tested using this structure.
• The approach of identifying pathways in the control flow graph that give a
foundation set of execution paths through the program or module is known as
basis path testing.
• Four stages are followed to create test cases using this technique −
a. Create a Control Flow Graph.
b. Calculate the Graph's Cyclomatic Complexity
c. Identify the Paths That Aren't Connected
d. Create test cases based on independent paths.
Example solved on board.
Dataflow Testing
• Data flow testing is a term which is having no connection with dataflow
diagrams. 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 (or referenced).
• Most programs deliver functionality in terms of data. Variables that represent
data somehow receive values, and these values are used to compute values for
other variables.
• Since the early 1960s, programmers have analyzed source code in terms of the
points (statements) at which variables receive values and points at which these
values are used.
Early data flow analysis often centered on a set of faults that are now known as
define/reference anomalies:
a. A variable that is defined but never used (referenced)
b. A variable that is used but never defined
c. A variable that is defined twice before it is used

• Data flow testing can be performed at two conceptual levels.

– Static data flow testing
– Dynamic data flow testing
• Static data flow testing
– Identify potential defects, commonly known as Data Flow Anomaly.
– Analyze source code.
– Do not execute code.

• Dynamic data flow testing

– Involves actual program execution.
– Bears similarity with control flow testing.
• Identify paths to execute them.
• Paths are identified based on data flow testing criteria
There are two major forms of dataflow testing
1. Define/Use testing
– paths to the locations and properties of references to variables within the program

code.
– a program can be analyzed in terms of
• how the variables are affected,
• assigned and

2. Slice- Based Testing

– “Slice” the program into a number of individually executable components
– Each focusing on one particular variable at one particular location within the
program.
– Slicing techniques, especially on larger projects with large teams of developers.
• Much of the formalization of define/use testing was done in the early 1980s. It
presumes a program graph in which nodes are statement fragments (a fragment may be
an entire statement), and programs that follow the structured programming precepts.

The following definitions refer to a program P that has a program graph G(P), and a set
of program variables V.
• Nodes correspond to program statements
• Edges correspond to the flow of information
• Program Graph G(P) with respect to program(P) has,
 Single entry and single exit node
 Number of edges from node to itself
 Set of program variables: V
 Set of all paths in P: PATHS(P)
Definition
• Node n ∈ G (P) is a defining node of the variable v ∈ V, written as DEF (v, n), iff
the value of the variable v is defined at the statement fragment corresponding to
node n.
Ex: Input (x)
Ex: x = 20

Definition
• Node n ∈ G (P) is a usage node of the variable v ∈ V, written as USE (v, n), iff the
value of the variable v is used at the statement fragment corresponding to node n.
Define/use of variables of the above example:
1. read x, y;
2. if(x>y)
3. a = x+1
else
4. a = y-1
5. print a;
• Definition-use path (du-path): A definition-use path with respect to a variable v
(denoted du-path) is a path in PATHS(P) such that, for some v ∈ V, there are
define and usage nodes DEF(v, m) and USE(v, n), where m and n are the initial
and final nodes of the path.

• Definition-clear path (dc-path): A definition-clear path with respect to a

variable v (denoted dc-path) is a definition-use path in PATHS (P) with initial
and final nodes DEF (v, m) and USE (v, n) such that no other node in the path is
a defining node of v.
Slice-Based Testing
• Given a program P, and a set V of variables in P, a slice on the variable set V at
statement n, written S(V,n), is the set of all statements in P that contribute to the
values of variables in V. at node n.

• The idea of slices is to separate a program into components that have some useful
meaning.

• Slice captures the execution time behavior of a program with respect to the
variable(s) in the slice.

• Eventually, we will develop a lattice (a directed, acyclic graph) of slices, in which

nodes are slices, and edges correspond to the subset relationship.
USE relationship pertains to five forms of usage:
• P-use used in a predicate (decision)
• C-use used in computation
• O-use used for output
• L-use used for location (pointers, subscripts)
• I-use iteration (internal counters, loop indices)

We identify two forms of definition nodes:

• I-def defined by input
• A-def defined by assignment
For now, assume that the slice S(V, n) is a slice on one variable, that is, the set V
consists of a single variable, v.
• If statement fragment n is a defining node for v, then n is included in the slice.
• If statement fragment n is a usage node for v, then n is not included in the slice.
• P-uses and C-uses of other variables (not the v in the slice set V) are included to the
extent that their execution affects the value of the variable v.
• If the value of v is the same whether a statement fragment is included or excluded,
then exclude that statement fragment.
• L-use and I-use variables are typically invisible outside their modules
• O-use, L-use, and I-use nodes are excluded from slices.

Example:
Lattice
• A lattice in slice-based testing refers to the structure used to represent the
dependencies between different parts of the system, such as modules,
components, or functions.
• The lattice helps in identifying and selecting appropriate slices for testing, based
on the dependencies between different parts of the system.
• Consider a software system that consists of three modules: A, B, and C. Module
A depends on module B, and module B depends on module C. The dependencies
can be represented as a lattice, where module C is at the bottom, module B is in
the middle, and module A is at the top:

A
/\
B .
/\
C .