SOFTWARE TESTING METHODOLOGIES AND TOOLS

(A1217156) SOFTWARE TESTING METHODOLOGIES AND TOOLS

UNIT II

UNIT-II: Flow graphs and Path testing: Basics concepts of path testing,
predicates, path predicates and achievable paths, path sensitizing, path
instrumentation, application of path testing.

Flow graphs and Path testing:

 Basics concepts of path testing

 Predicates, Path predicates and achievable paths
 Path sensitizing
 Path instrumentation
 Applications of path testing.

Prepared by: Dept. of CSE, RGMCET Page 1

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

1. Motivation and Assumptions

 Path testing is the name given to a family of test techniques based on
judiciously selecting a set of test paths through the program.

 If the set of paths is properly chosen, then we have achieved some measure
of test thoroughness.

Motivation:
 Path testing is most applicable to new software for unit testing. It is a
structural technique.

 It requires complete knowledge of program structure (source code).

 Path testing is rarely used for system testing. For the programmer it is the
basic test technique.

 Path testing is the fundamental to all testing techniques.

The Bug Assumption:

 The bug assumption for the path-testing strategies is that something has
gone wrong with the software that makes it take a different path than
intended.
 Structured programming languages prevent many of the bugs targeted by
path testing.
 Conversely, assembly languages, COBOL, FORTRAN, and Basic have a
higher proportion of control-flow bugs than contemporary code, and for
such software path testing is necessary.

Prepared by: Dept. of CSE, RGMCET Page 2

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

2. Path testing Basics :

2.1. Introduction:

Path testing is the name given to a family of test techniques based on

judiciously selecting a set of test paths through the program. If the set of test
paths is properly chosen, then we have achieved some measure of test
thoroughness. For example, pick enough paths to assure that every source has
been executed at least once.

Path-testing techniques are the oldest of all structural test techniques. They
are recorded as being in use at IBM for more than two decades.

Path testing is most applicable to new software for unit testing. It requires
complete knowledge of the program‘s structure (i.e., source code). It is most
often used by programmers to unit test their own code.

The effectiveness of path testing rapidly deteriorates [to become worse, degrade]
as the size of the software aggregate under test increases. For the programmer,
it is the basic test technique.

2.2. Control Flow graphs:

The Control graph is a graphical representation of program‘s control structure.
It uses the following elements.

 Process blocks
 Decisions
 Case statements
 Junctions

Prepared by: Dept. of CSE, RGMCET Page 3

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

2.2.1. Process Blocks

A process block is a sequence of program statements uninterrupted by either
decisions or junctions. Formally, it is a sequence of statements of the block is
executed, and then all statements thereof are executed.

Once a process block is initiated, every statement within it will be executed.

Similarly, there is no point within the process block that is the target of a
GOTO.

A process has one entry and one exit. It can consist of a single statement or
instruction, a sequence of statements or instructions;

Process:

2.2.2. Decisions and case statements

A decision is a program point at which the control flow can diverge. Machine
language conditional branch and conditional skip instructions are examples of
decisions. The FORTRAN IF and the Pascal IF-THEN –ELSE constructs are also
examples of decisions.

Decision:

A case statement is a multi-way branch or decision. Examples of case

statements includes a jump table (In assembly language), GOTO (In FORTRAN),
CASE statements (In Pascal).

Prepared by: Dept. of CSE, RGMCET Page 4

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

Case Statement:

From the point of test design, there are no differences between decisions and
case statements.

2.2.3. Junctions
A junction is a point in the program where the control flow can merge.
Examples of junctions are: the target of a jump or skip (In assembly language),
a label that is the target of a GOTO, the END-IF and CONTINUE statements in
FORTRAN, END and UNTIL (In Pascal).

Junctions:

2.2.4. Control Flow graphs Versus Flowcharts

A program‘s flowchart resembles a control flow graph, but differs in one
important way.

 In control flow graphs, we don‘t show the details of what is in a process

block; indeed, the entire block, no matter how many statements in it, is
shown as a single process. In flowcharts, conversely, every part of the
process block is drawn: (i.e., if a process block consists of 100 steps, the
flowchart may have 100 boxes.).

Prepared by: Dept. of CSE, RGMCET Page 5

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

 The flowchart focuses on process steps, whereas the control flow graph
ignores them.

 The flowchart forces an expansion of visual complexity by adding many

off-page connectors, which confuses the control flow, but the flow graph
compacts the representation and makes it easier to follow.

 When we used flowcharts for design we were actually using cluttered-up

control flow graphs. The trouble with them is that there‗s too much
information—especially if the flowcharting standard requires one
flowchart box per source statement.

So while the exercise of drawing detailed flowcharts may not be an

effective step in the design process, the act of drawing a control flow graph
is a useful tool that can help us to clarify the control flow and data flow
issues.

2.2.6. Notational Evolution:

The control flow graph is a simplified (i.e., more abstract) representation of the
program‘s structure. To understand it‘s creation and use, we‘ll go through an
example, starting with a simple code written in FORTRAN-like program design
language.

Prepared by: Dept. of CSE, RGMCET Page 6

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

Fig 1: Program example (PDL)

The first step is translating this code to a control flow graph is as shown in the
below figure, where we have the typical one-to-one flowchart.

Fig 2: one-to-one flowchart for figure 1

Note that the complexity has increased, clarity has decreased, and that we had
to add auxiliary labels (LOOP, XX, and YY), which have no actual program
counterpart. In the below figure, we merged the process steps and replaced
with the single process box. We now have a control flow graph.

Prepared by: Dept. of CSE, RGMCET Page 7

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

Fig 3: Control Flow graph for figure 1

But this representation is still too busy. We simplify this notation further to
achieve figure 4. To do that, we had to make several more notational changes.

1. The process boxes weren‘t really needed. There is an implied process

on every line joining junctions and decisions.

2. We don‘t need to know the specifics of the decisions, just the fact that
there is a branch—so we can do away with things such as ―U>V?‖,
―yes‖, ―no‖, and so on.

3. The specific target label names aren‘t important--- just the fact that
they exist. So we replace them by simple numbers.

Prepared by: Dept. of CSE, RGMCET Page 8

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

Fig 4: Simplified Flow graph Notation.

Figure 4 is the way we usually represent the program‘s control flow graph. In
this, there are two types of components: Circles and Arrows, which joins
circles.

 A circle with more than one arrow leaving it is a decision.

 A circle with more than one arrow entering is a junction.

 We call the circles as nodes and the arrows as links.

Note: The entry and exit are also denoted by circles (nodes).

Nodes are usually numbered (or) labeled by using the original program labels.
The link name can be formed from the names of the nodes it spans. Thus a link
from node 7 to node 4 is called link (7, 4), where as a link from node 4 to node
7 is called link (4,7). For parallel links, between a pair of nodes (nodes 12 and
13 in figure 4), we can use subscripts, to denote each one or some
unambiguous notation such as ―(12, 13 upper)‖ and ―(12, 13 lower)‖.

An alternate way to name links that avoids this problem is to use a unique
lowercase letter for each link in the flow graph.

The final transformation is shown in figure 5, where we‘ve dropped the node
numbers to achieve an even simpler representation.

Prepared by: Dept. of CSE, RGMCET Page 9

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

Fig 5: Even simpler flow graph notation

The way to work with control flow graphs is to use the simplest possible
representation—that is, no more information available to correlate back to the
source program.

Although graphical representations are revealing, they are often inconvenient---

especially if you want to work with them. The alternative is to use a linked-list
representation, shown in figure 6. Each node has a name and there is an entry
on the list for each link in the flow graph. Only the information is pertinent to
the control flow is shown--- that is the labels and the decisions.

Fig 6: linked-list control flow graph notation

Prepared by: Dept. of CSE, RGMCET Page 10

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

The linked list is the representation of choice for programs that manipulate or
create flow graphs.

2.2.7. Flow graph- Program Correspondence

A flow graph is a pictorial representation of a program. It just acts as a
topographic map, no matter how detailed. This distinction is important: failure
to make it can lead to bugs.

The translation from a flow graph element to a statement and vice versa is not
always unique. Myers cites an anomaly based on different representations of
the FORTRAN statement IF (A=0).AND. (B=1) THEN…..‖. it has the alternate
representations shown in figure 7.

Fig 7: Alternative Flow graphs for the same logic

Note: The control Flow graph is a simplified version of the earlier flowchart.

Prepared by: Dept. of CSE, RGMCET Page 11

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

2.3. Path Testing

2.3.1. Paths, Nodes, and Links

 A path is a sequence of instructions or statements that start at an entry,
junction, or decision and ends at another or possibly the same junction,
decision, or exit.

 A path may go through several junctions, processes, or decisions, one or

more times. Paths consists of segments, the smallest segment is a link, that
is, a single process that lies between two nodes.

Eg:- junction-process-junction, junction-process-decision, decision-

process-decision etc.

 A path segment is a succession of consecutive links that belongs to some

path.

 The length of a path is measured by the number of links in it (or) the

number of nodes traversed.

 The name of a path is the name of the nodes along the path. Alternatively,
if we choose to label the links, the name of the path is the succession of link
names along the path.

 A path has a loop in it if any node (link) name is repeated in that path.

 The terms entry/exit path and complete path are also used in the
literature to denote a path that starts at an entry and goes to an exit.

2.3.2. Fundamental Path Selection Criteria

There are many paths between the entry and exit of a typical routine. Every
decision doubles the number of potential paths, and every loop multiplies the
number of potential paths by the number of different iteration values are
possible for the loop.

Prepared by: Dept. of CSE, RGMCET Page 12

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

A lavish test approach might consist of testing all the paths, but that would not
be a complete test, because a bug could create unwanted paths (or) make
mandatory paths unexecutable. Just because of all paths are right, doesn‘t
mean that the routine is doing the required processing along those paths.

How can we define Complete Testing?

1) Exercise every path from entry to exit. [P1]

2) Exercise every statement or instruction at least once. [P2]

3) Exercise every branch and case statement, in each direction, at least

once.[P3]

If ‗P1‘ is followed, then ‗P2‘ and ‗P3‘ are automatically followed; but ‗P1‘ is
impractical for most of the routines. It can be done only for the routines, those
have no loops.

‗P2‘ and ‗P3‘ might appear to be equivalent, but they are not. Here is a correct
version of routine:

For „X‘ is negative, the output is „X+A‟, while for X greater than or equal to
zero, the output is X+2A. Following P2 and executing every statement, but not
every branch, would not reveal the bug in the following incorrect version:

Prepared by: Dept. of CSE, RGMCET Page 13

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

A negative value produces the correct answer. Every statement can be

executed, but if the test cases do not force each branch to be taken, then the
bug can remain hidden. The next example uses a test based on executing every
branch but does not force the execution of all statements;

The hidden loop around label 100 is not revealed by tests based on ‗P3‘ alone
because no test forces the execution of statement100 and the fallowing GOTO
statement.

2.3.3. Path-Testing Criteria

Any testing strategy based on paths must at least exercise every instruction
and take branches in all directions. Here, we are discussing three different
testing criteria or strategies out of a potentially infinite family of strategies.
They are:

1) Path Testing (P∞):

Execute all possible control flow paths through the program. Typically it is
restricted to all possible entry/exit paths through the program. If we achieve
this prescription, we are said to have achieved 100% path coverage. This is
the strongest criterion in the path-testing strategy family. It is generally
impossible to achieve.

Prepared by: Dept. of CSE, RGMCET Page 14

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

2) Statement Testing (P1):

Execute all statements in the program at least once under some test. If we do
enough tests to achieve this, we are said to have achieved 100% statement
coverage (100% node coverage). We denote this by C1. This is the weakest
criterion in the family. Testing less than this for a new software is
unconscionable [not guided by, not conforming to reason] and should be
criminalized.

3) Branch Testing (P2):

Execute enough tests to assure that every branch alternative has been
exercised at least once under some test. If we do enough tests to achieve this
prescription, then we have achieved 100% branch coverage (100% link
coverage). We denote branch coverage by C2.

NOTE:

1) We usually drop the ―100%” so, when we say that we have ―achieved
branch coverage‖ means that, we have achieved 100% branch coverage.
Similarly for path and statement coverage also.

2) The term ―Complete Coverage” or “Coverage” alone is often used in the

literature to mean 100% statement and branch coverage (i.e., C1 + C2).

2.3.4. Common Sense and Strategies

 Branch and statement coverage are accepted today as the minimum

mandatory testing requirement.

 Statement coverage is established as a minimum testing requirement in the

IEEE unit test standard.

 Statement and Branch coverage have also been used for more than two
decades as minimum mandatory unit test requirements for new code at IBM
and other major software companies.

Prepared by: Dept. of CSE, RGMCET Page 15

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

2.3.5.Which paths we‟ve to select

You must pick enough paths to achieve C1+C2. The question is, what is the
fewest number of such paths is interesting to the designer of test tools that
help automate path testing.

It is better to take many simple paths than a few complicated paths. There‘s no
harm in taking paths that will exercise the same code more than once.

As an example of how to go about selecting paths, consider the following figure.

Fig: An example of Path Selection

Start at the beginning and take the most obvious path to the exit. The most
obvious path in the above figure is (1, 3, 4, 5, 6, 2), if we name it by nodes, or
abcde if we name it by the links.

Then take the next most obvious path, abhkgde. All other in this example
leads to loops. Take a single loop first, build if possible on a previous path,
such as abhlibcde. Then take another loop abcdfjgde. Finally, abcdfmibcde.

Some practical suggestions to select optimum paths:

1) Draw the control flow graph on a single sheet of paper.

2) Make several copies—as many as you‘ll need for coverage.

Prepared by: Dept. of CSE, RGMCET Page 16

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

3) Use a yellow highlighting marker to trace paths. Copy the paths on to a

master sheet.

4) Continue the tracing of paths until all lines on the master sheet are
covered, that indicates that you appear to have achieved C1+C2.

As you trace the paths, create a table that shows the paths, the coverage status
of each process, and each decision. The above path leads to the following table:

After you have traced a covering path set on the master sheet and filled in the
table for every path, check the following:

 Does every decision have a YES and a NO on its column? (C2)

 Has every case of all case statements been marked? (C2)

 Is every three way branches (less, equal, greater) covered? (C2)

 Is every link (Process) covered at least once? (C1)

Select successive paths as small variations of previous paths. Try to change

only one thing at a time (only one decision‘s outcome if possible). The abcd
segment in the above example is common to many paths. If this common
segment has been debugged, and a bug appears in a new path that uses this
segment, it‘s more likely that the bug is in the new part of the path (say fjgde)
rather than in the part that is already been debugged.

Prepared by: Dept. of CSE, RGMCET Page 17

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

Note:

 You could select paths with the idea of achieving coverage without
knowing anything about what the routine is supposed to do.

 Path selection is completely based on pure structure without regard to

function.

Path Selection Rules:

 Pick the simplest entry/exit path

 Pick additional paths as small variations from previous paths.

 Pick the paths that do not have loops.

 Favor short paths over long paths, simple paths over complicated paths.

 Be comfortable with your chosen paths.

 Don‘t follow the rules slavishly [blindly imitative] --- except for
Coverage.

2.4. Loops

Cases for a single loop: A Single loop can be covered with two cases: Looping
and Not looping. But, experience shows that many loop-related bugs are not
discovered by C1+C2. Bugs hide themselves in corners and congregate at
boundaries - in the cases of loops, at or around the minimum or maximum
number of times the loop can be iterated. The minimum number of iterations is
often zero, but it need not be.

CASE 1: Single loop, Zero minimum, N maximum, No excluded values

1. Try bypassing the loop (zero iterations). If you can't, you either have a
bug, or zero is not the minimum and you have the wrong case.

Prepared by: Dept. of CSE, RGMCET Page 18

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

2. Could the loop-control variable be negative? Could it appear to specify a

negative number of iterations? What happens to such a value?
3. One pass through the loop.
4. Two passes through the loop.
5. A typical number of iterations, unless covered by a previous test.
6. One less than the maximum number of iterations.
7. The maximum number of iterations.
8. Attempt one more than the maximum number of iterations. What
prevents the loop-control variable from having this value? What will happen
with this value if it is forced?

CASE 2: Single loop, Non-zero minimum, No excluded values

1. Try one less than the expected minimum. What happens if the loop
control variable's value is less than the minimum? What prevents the value
from being less than the minimum?
2. The minimum number of iterations.
3. One more than the minimum number of iterations.
4. Once, unless covered by a previous test.
5. Twice, unless covered by a previous test.
6. A typical value.
7. One less than the maximum value.
8. The maximum number of iterations.
9. Attempt one more than the maximum number of iterations.

CASE 3: Single loops with excluded values

1. Treat single loops with excluded values as two sets of tests consisting of
loops without excluded values, such as case 1 and 2 above.
2. Example, the total range of the loop control variable was 1 to 20, but that
values 7, 8,9,10 were excluded. The two sets of tests are 1-6 and 11-20.
Prepared by: Dept. of CSE, RGMCET Page 19
 SOFTWARE TESTING METHODOLOGIES AND TOOLS

3. The test cases to attempt would be 0,1,2,4,6,7 for the first range and
10,11,15,19,20,21 for the second range.
2.4.1. The Kinds of Loops

There are three kinds of Loops. They are

 Nested loops

 Concatenated loops

 Horrible loops

i) Nested Loops:

If you had five tests(assuming that one less than the minimum and one
more than the maximum were not achievable) for one loop, a pair of nested
loops would require 25 tests, and three nested loops would require 125. This is
heavy process. You can‘t always afford to test all combinations of nested loops‘
iteration values. Here‘s a tactic to use to discard some of these values:

1. Start at the innermost loop. Set all the outer loops to their minimum
values.
2. Test the minimum, minimum+1, typical, maximum-1, and maximum for
the innermost loop, while holding the outer loops at their minimum-
iteration-parameter values Expand the tests as required for out-of-range
and excluded values.
3. If you‘ve done the outermost loop, GOTO step 5, ELSE move out one loop
and set it up as in step 2-with all other loops set to typical values.
4. Continue outward in this manner until all loops have been covered.
5. Do the five cases for all loops in the nest simultaneously.

This procedure works out to twelve tests for a pair of nested loops,
sixteen for three nested loops, and nineteen for four nested loops. Practicality

Prepared by: Dept. of CSE, RGMCET Page 20

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

may prevent testing in which all loops achieve their maximum values
simultaneously.

Fig: Nested Loops

ii) Concatenated Loops:

Concatenated loops fall between single and nested loops with respect to
test cases. Two loops are concatenated if it‘s possible to reach one after exiting
the other while still on a path from entrance to exit. If the loops cannot be on
the same path, then they are not concatenated and can be treated as individual
loops. Even if the loops are on the same path and you can be sure that they are
independent of each other, you can still treat them as individual loops; but if
the iteration values in one loop are directly or indirectly related to the iteration
values of another loop, and they can occur on the same path, then treat them
as you would nested loops. The problem of excessive processing time for
combinations of loop-iteration values should not occur because the loop-
iteration values are additive rather than multiplicative as they are for nested
loops.

Fig: Concatenated Loops

Prepared by: Dept. of CSE, RGMCET Page 21

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

iii) Horrible Loops:

Although some methods give you some insight into the design of test
cases for horrible loops, the resulting cases are not definitive and are usually
too many to executive. The thinking required checking the end points and
looping values for intertwined loops appears to be unique for each program. It‘s
also difficult at times to see how deeply nested the loops are, or indeed whether
there are any nested loops. The use of code that jumps into and out of loops,
makes iteration-value selection for test cases an awesome and ugly task, which
is another reason such structures should be avoided.

Fig: Horrible Loops

Prepared by: Dept. of CSE, RGMCET Page 22

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

3. PREDICATES, PATH PREDICATES, AND ACHIEVABLE PATHS:

Predicates:

The logical function evaluated at a decision is called a predicate.

Some examples are: A>0, x+y >=90.......

The direction taken at a decision depends on the value of decision variable.

Path Predicate:

A predicate associated with a path is called a Path Predicate. For example, "x is
greater than zero", "x+y>=90", "w is either negative or equal to 10 is true" is a
sequence of predicates whose truth values will cause the routine to take a
specific path.

Multiway Branches:

The path taken through a multiway branch such as a computed GOTO's, case
statement, or jump tables cannot be directly expressed in TRUE/FALSE terms.

Although, it is possible to describe such alternatives by using multi valued

logic, an expedient (practical approach) is to express multiway branches as an
equivalent set of if..then..else statements.

For example a three way case statement can be written as: If case=1 DO A1
ELSE (IF Case=2 DO A2 ELSE DO A3 ENDIF)ENDIF.

Inputs:

 In testing, the word input is not restricted to direct inputs, such as variables
in a subroutine call, but includes all data objects referenced by the routine
whose values are fixed prior to entering it.
 For example, inputs in a calling sequence, objects in a data structure,
values left in registers, or any combination of object types.

Prepared by: Dept. of CSE, RGMCET Page 23

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

 The input for a particular test is mapped as a one dimensional array called
as an Input Vector.

Predicate interpretation:
The simplest predicate depends only on input variables.

For example if x1,x2 are inputs, the predicate might be x1+x2>=7, given the
values of x1 and x2 the direction taken through the decision is based on the
predicate is determined at input time and does not depend on processing.

Another example, assume a predicate x1+y>=0 that along a path prior to

reaching this predicate we had the assignment statement y=x2+7. Although our
predicate depends on processing, we can substitute the symbolic expression for
y to obtain an equivalent predicate x1+x2+7>=0.

The act of symbolic substitution of operations along the path in order to

express the predicate solely in terms of the input vector is called predicate
interpretation.

Independence of variables and predicates:

 The path predicates take on truth values based on the values of input
variables, either directly or indirectly.
 If a variable's value does not change as a result of processing, that
variable is independent of the processing.
 If the variable's value can change as a result of the processing, the
variable is process dependent.
 A predicate whose truth value can change as a result of the processing is
said to be process dependent and one whose truth value does not
change as a result of the processing is process independent.

Prepared by: Dept. of CSE, RGMCET Page 24

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

 Process dependence of a predicate does not always follow from

dependence of the input variables on which that predicate is based.

Correlation of variables and predicates:

 Two variables are correlated if every combination of their values cannot

be independently specified.
 Variables whose values can be specified independently without restriction
are called uncorrelated.
 A pair of predicates whose outcomes depend on one or more variables in
common are said to be correlated predicates.
For example, the predicate X==Y is followed by another predicate X+Y ==
8. If we select X and Y values to satisfy the first predicate, we might have
forced the 2nd predicate's truth value to change.
 Every path through a routine is achievable only if all the predicates in
that routine are uncorrelated.

Path predicate expressions:

 A path predicate expression is a set of Boolean expressions, all of which

must be satisfied to achieve the selected path.

Example: X1+3X2+17>=0

X3=17

X4-X1>=14X2

 Any set of input values that satisfy all of the conditions of the path
predicate expression will force the routine to the path.

Prepared by: Dept. of CSE, RGMCET Page 25

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

Compound Predicate:

Predicates of the form A OR B, A AND B and more complicated Boolean

expressions are called as compound predicates.

Sometimes even a simple predicate becomes compound after interpretation.

Example: the predicate if (x=17) whose opposite branch is if x.NE.17 which
is equivalent to x>17 . Or. X<17

Predicate Coverage:

Predicate coverage is being the achieving of all possible combinations of

truth values corresponding to the selected path have been explored under
some test.

Testing Blindness:

Testing Blindness is a pathological (harmful) situation in which the desired

path is achieved for the wrong reason.

There are three types of Testing Blindness:

1. Assignment Blindness
2. Equality Blindness
3. Self-Blindness

1. Assignment Blindness:

 Assignment blindness occurs when the buggy predicate appears to work

correctly because the specific value chosen for an assignment statement
works with both the correct and incorrect predicate.

Prepared by: Dept. of CSE, RGMCET Page 26

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

For Example:

Correct Buggy

X=7 X=7
........ ........
if Y > 0 then ... if X+Y > 0 then ...

 If the test case sets Y=1 the desired path is taken in either case, but there
is still a bug.

2. Equality Blindness:

 Equality blindness occurs when the path selected by a prior predicate

results in a value that works both for the correct and buggy predicate.

For Example:

Correct Buggy

if Y = 2 then if Y = 2 then
........ ........
if X+Y > 3 then ... if X > 1 then ...

 The first predicate if Y=2 forces the rest of the path, so that for any
positive value of x. the path taken at the second predicate will be the
same for the correct and buggy version.

3. Self-Blindness:

 Self-blindness occurs when the buggy predicate is a multiple of the

correct predicate and as a result is indistinguishable along that path.

Prepared by: Dept. of CSE, RGMCET Page 27

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

For Example:

Correct Buggy

X=A X=A
........ ........
if X-1 > 0 then ... if X+A-2 > 0 then ...

 The assignment (X=A) makes the predicates multiples of each other, so

the direction taken is the same for the correct and buggy version.

4. PATH SENSITIZING:

Review: Achievable and unachievable paths:

 We want to select and test enough paths to achieve a satisfactory notion

of test completeness such as C1+C2.
 Extract the programs control flow graph and select a set of tentative
covering paths.
 For any path in that set, interpret the predicates along the path as
needed to express them in terms of the input vector. In general individual
predicates are compound or may become compound as a result of
interpretation.
 Trace the path through, multiplying the individual compound predicates
to achieve a Boolean expression such as

(A+BC) (D+E) (FGH) (IJ) (K) (L).

 Multiply out the expression to achieve a sum of products form:

ADFGHIJKL+AEFGHIJKL+BCDFGHIJKL+BCEFGHIJKL

 Each product term denotes a set of inequalities that if solved will yield an
input vector that will drive the routine along the designated path.

Prepared by: Dept. of CSE, RGMCET Page 28

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

 Solve any one of the inequality sets for the chosen path and you have
found a set of input values for the path.
 If you can find a solution, then the path is achievable.
 If you can‘t find a solution to any of the sets of inequalities, the path is
unachievable.
 The act of finding a set of solutions to the path predicate expression is
called PATH SENSITIZATION.

Heuristic Procedures for Sensitizing Paths:

 This is a workable approach, instead of selecting the paths without

considering how to sensitize, attempt to choose a covering path set that is
easy to sensitize and pick hard to sensitize paths only as you must to
achieve coverage.
 Identify all variables that affect the decision.
 Classify the predicates as dependent or independent.
 Start the path selection with un correlated, independent predicates.
 If coverage has not been achieved using independent uncorrelated
predicates, extend the path set using correlated predicates.
 If coverage has not been achieved extend the cases to those that involve
dependent predicates.
 Last, use correlated, dependent predicates.

5. PATH INSTRUMENTATION:

Path instrumentation is what we have to do to confirm that the outcome was

achieved by the intended path.

Co-incidental Correctness: The coincidental correctness stands for

achieving the desired outcome for wrong reason.

Prepared by: Dept. of CSE, RGMCET Page 29

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

The above figure is an example of a routine that, for the (unfortunately)

chosen input value (X = 16), yields the same outcome (Y = 2) no matter
which case we select. Therefore, the tests chosen this way will not tell us
whether we have achieved coverage. For example, the five cases could be
totally jumbled and still the outcome would be the same. Path
Instrumentation is what we have to do to confirm that the outcome was
achieved by the intended path.

The types of instrumentation methods are:

1. Interpretive Trace Program

2. Traversal Marker or Link Marker
3. Two Link Marker Method
4. Link Counter
1. Interpretive Trace Program:

 An interpretive trace program is one that executes every statement in

order and records the intermediate values of all calculations, the
statement labels traversed etc.

Prepared by: Dept. of CSE, RGMCET Page 30

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

 If we run the tested routine under a trace, then we have all the
information we need to confirm the outcome and, furthermore, to confirm
that it was achieved by the intended path.
 The trouble with traces is that they give us far more information than we
need. In fact, the typical trace program provides so much information
that confirming the path from its massive output dump is more work
than simulating the computer by hand to confirm the path.

2. Traversal Marker or Link Marker:

 A simple and effective form of instrumentation is called a traversal

marker or link marker.
 Name every link by a lower case letter.
 Instrument the links so that the link's name is recorded when the link is
executed.
 The succession of letters produced in going from the routine's entry to its
exit should, if there are no bugs, exactly correspond to the path name.

Why Single Link Markers aren't enough: Unfortunately, a single link

marker may not do the trick because links can be chewed by open bugs.

Prepared by: Dept. of CSE, RGMCET Page 31

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

We intended to traverse the ikm path, but because of a rampaging GOTO

in the middle of the m link, we go to process B. If coincidental correctness
is against us, the outcomes will be the same and we won't know about
the bug.

3. Two Link Marker Method:

 The solution to the problem of single link marker method is to implement

two markers per link: one at the beginning of each link and on at the end.
 The two link markers now specify the path name and confirm both the
beginning and end of the link.

4. Link Counter:

A less disruptive (and less informative) instrumentation method is based on

counters. Instead of a unique link name to be pushed into a string when the
link is traversed, we simply increment a link counter. We now confirm that
the path length is as expected. The same problem that led us to double link
markers also leads us to double link counters.

Prepared by: Dept. of CSE, RGMCET Page 32

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

6. APPLICATIONS OF PATH TESTING:

Integration, Coverage and Paths in called Components:

 Path testing methods are mainly used in unit testing, especially for new
software
 The new component is first tested as an independent unit with all called
components and co-requisite components replaced by stubs. A simulator of
low-level components that is more reliable than the actual component
 Path testing clarifies the integration issues
 C1 coverage at the system level ranges from 50% to 85%
 We gave no statistics for C2 coverage in system testing because it is
impossible to monitor C2 coverage without disrupting the system's
operation

New Code:
 New code should always be subjected to enough path testing to achieve C2
 Stubs are used where it is clear that the bug potential for the stub is
significantly lower than that of the called components
 Old, trusted components will not be replaced by stubs
 Some consideration is given to paths within called components
 Typically, we will try to use the shortest entry/exit path that will do the task

Maintenance:
 There is a great difference between maintenance testing and new code
testing
 Maintenance testing is a completely different situation
 It involves modifications which are accommodated in the system, as
required
 Path testing is used firstly on the modified component

Prepared by: Dept. of CSE, RGMCET Page 33

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

Rehosting:
 Path testing with C1+C2 coverage is a powerful tool for rehosting old software
 We get a very powerful, effective, rehosting process when C1+C2 coverage is
used in conjunction with automatic or semiautomatic structural test
generators
 Software is rehosted because it is no longer cost effective to support the
environment in which it runs
 The objective of rehosting is to change the operating environment and not
the rehosted software
 Rehosting from one COBOL environment to another is easy by comparison
 Rehosted software can be modified to improve efficiency and/or to
implement new functionality, which had been difficult in the old
environments
 The test suites(collection) and all outcomes of the old environment become
the specification for the rehosted software

Prepared by: Dept. of CSE, RGMCET Page 34

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

Prepared by: Dept. of CSE, RGMCET Page 35