lOMoARcPSD|48526483

STM UNIT 2 - notes

Software Engineering (Central University of Haryana)

Scan to open on Studocu

Studocu is not sponsored or endorsed by any college or university

Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

UNIT 2
Dynamic testing: Black-Box Testing Techniques:
Black-box technique is one of the major techniques in dynamic testing for designing effective
test cases. This technique considers only the functional requirements of the software or module. In
other words, the structure or logic of the software is not considered. Therefore, this is also known
as functional testing. The software system is considered as a black box, taking no notice of its
internal structure, so it is also called as black-box testing technique.
It is obvious that in black-box technique, test cases are designed based on functional
specifications. Input test data is given to the system, which is a black box to the tester, and results
are checked against expected outputs after executing the software, as shown in Fig. 4.1.

Black-box testing attempts to find errors in the following categories: „

 To test the modules independently. „
 To test the functional validity of the software so that incorrect or missing functions can be
recognized.„
 To look for interface errors. „
 To test the system behaviour and check its performance. „
 To test the maximum load or stress on the system. „
 To test the software such that the user/customer accepts the system within defined acceptable
limits.
There are various methods to test a software product using black-box techniques. One method
chooses the boundary values of the variables, another makes equivalence classes so that only one
test case in that class is chosen and executed. Some methods use the state diagrams of the system to
form the black-box test cases, while a few other methods use table structure to organize the test
cases. It does not mean that one can pick any of these methods for testing the software. Sometimes
a combination of methods is employed for rigorous testing. The objective of any test case is to have
maximum coverage and capability to discover more and more errors.

BOUNDARY VALUE ANALYSIS (BVA)

An effective test case design requires test cases to be designed such that they maximize the
probability of finding errors. BVA technique addresses this issue. With the experience of testing
team, it has been observed that test cases designed with boundary input values have a high chance
to find errors. It means that most of the failures crop up due to boundary values.
BVA is considered a technique that uncovers the bugs at the boundary of input values. Here,
boundary means the maximum or minimum value taken by the input domain. For example, if A is
an integer between 10 and 255, then boundary checking can be on 10(9, 10, 11) and on 255(256,
255, 254). Similarly, B is another integer variable between 10 and 100, then boundary checking can
be on 10(9, 10, 11) and 100(99, 100, 101), as shown in Fig. 4.2.

1
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

BVA offers several methods to design test cases
1. BOUNDARY VALUE CHECKING (BVC)
2. ROBUSTNESS TESTING METHOD
3. WORST-CASE TESTING METHOD

BOUNDARY VALUE CHECKING (BVC): -

In this method, the test cases are designed by holding one variable at its extreme value and
other variables at their nominal values in the input domain.
The variable at its extreme value can be selected at:
(a) Minimum value (Min)
(b) Value just above the minimum value (Min+ )
(c) Maximum value (Max)
(d) Value just below the maximum value (Max−)
Let us take the example of two variables, A and B. If we consider all the above combinations
with nominal values, then following test cases (see Fig. 4.3) can be designed:

It can be generalized that for n variables in a module, 4n + 1 test cases can be designed with
boundary value checking method.

ROBUSTNESS TESTING METHOD: -

The idea of BVC can be extended such that boundary values are exceeded as:
 A value just greater than the Maximum value (Max+) „
 A value just less than Minimum value (Min−)
When test cases are designed considering the above points in addition to BVC, it is called
robustness testing.
Let us take the previous example again. Add the following test cases to the list of 9 test cases
designed in BVC:

2
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

It can be generalized that for n input variables in a module, 6n + 1 test cases can be designed
with robustness testing.

WORST-CASE TESTING METHOD: -

We can again extend the concept of BVC by assuming more than one variable on the
boundary. It is called worst-case testing method.
Again, take the previous example of two variables, A and B. We can add the following test
cases to the list of 9 test cases designed in BVC as:

It can be generalized that for n input variables in a module, 5n test cases can be designed
with worst-case testing.
BVA is applicable when the module to be tested is a function of several independent
variables. This method becomes important for physical quantities where boundary condition
checking is crucial. For example, systems having requirements of minimum and maximum
temperature, pressure or speed, etc. However, it is not useful for Boolean variables.

Example 4.1
A program reads an integer number within the range [1,100] and determines whether it is a prime
number or not. Design test cases for this program using BVC, robust testing, and worst-case testing
methods.
Solution
(a) Test cases using BVC: - Since there is one variable, the total number of test cases will be 4n + 1
= 5.
In our example, the set of minimum and maximum values is shown below:

3
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

(b) Test cases using robust testing: - Since there is one variable, the total number of test cases
will be 6n + 1 = 7. The set of boundary values is shown below:

Using these values, test cases can be designed as shown below:

(c) Test cases using worst-case testing: - Since there is one variable, the total number of test
cases will be 5n = 5. Therefore, the number of test cases will be same as BVC.

Example 4.2
A program computes ab where a lies in the range [1, 10] and b within [1, 5]. Design test cases for
this program using BVC, robust testing, and worst-case testing methods.
Solution: -
(a) Test cases using BVC Since there are two variables, a and b, the total number of test cases will be
4n + 1 = 9. The set of boundary values is shown below:

Using these values, test cases can be designed as shown below:

4
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

(b) Test cases using robust testing: - Since there are two variables, a and b, the total number of
test cases will be 6n + 1 = 13. The set of boundary values is shown below:

Using these values, test cases can be designed as shown below:

(c) Test cases using worst-case testing: - Since there are two variables, a and b, the total number
of test cases will be 5n = 25.

5
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

Example 4.3
A program reads three numbers, A, B, and C, within the range [1, 50] and prints the largest number.
Design test cases for this program using BVC, robust testing, and worst-case testing methods.
Solution
(a) Test cases using BVC: - Since there are three variables, A, B, and C, the total number of test
cases will be 4n + 1 = 13. The set of boundary values is shown below:

Using these values, test cases can be designed as shown below:

(b) Test cases using robust testing: - Since there are three variables, A, B, and C, the total number
of test cases will be 6n + 1 = 19.
The set of boundary values is shown below:

6
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

Using these values, test cases can be designed as shown below:

(c) Test cases using worst-case testing: - Since there are three variables, A, B, and C, the total
number of test cases will be 5n = 125.
The set of boundary values is shown below:

There may be more than one variable at extreme values in this case. Therefore, test cases can be
design as shown below:

7
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

Example 4.4

8
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

9
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

10
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

11
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

EQUIVALENCE CLASS TESTING

We know that the input domain for testing is too large to test every input. So we can divide
or partition the input domain based on a common feature or a class of data. Equivalence
partitioning is a method for deriving test cases wherein classes of input conditions called
equivalence classes are identified such that each member of the class causes the same kind of
processing and output to occur. Thus, instead of testing every input, only one test case from each
partitioned class can be executed. It means only one test case in the equivalence class will be
sufficient to find errors. This test case will have a representative value of a class which is equivalent
to a test case containing any other value in the same class. If one test case in an equivalence class
detects a bug, all other test cases in that class have the same probability of finding bugs. Therefore,
instead of taking every value in one domain, only one test case is chosen from one class. In this way,
testing covers the whole input domain, thereby reduces the total number of test cases. In fact, it is
an attempt to get a good hit rate to find maximum errors with the smallest number of test cases.
Equivalence partitioning method for designing test cases has the following goals:
Completeness: - Without executing all the test cases, we strive to touch the completeness of testing
domain.
Non-redundancy: - When the test cases are executed having inputs from the same class, then there
is redundancy in executing the test cases. Time and resources are wasted in executing these
redundant test cases, as they explore the same type of bug. Thus, the goal of equivalence
partitioning method is to reduce these redundant test cases.
To use equivalence partitioning, one needs to perform two steps:
1. Identify equivalence classes
2. Design test cases
1. IDENTIFICATION OF EQUIVALENT CLASSES: -
How do we partition the whole input domain? Different equivalence classes are formed by
grouping inputs for which the behaviour pattern of the module is similar. The rationale of
forming equivalence classes like this is the assumption that if the specifications require exactly
the same behaviour for each element in a class of values, then the program is likely to be
constructed such that it either succeeds or fails for each value in that class. For example, the
specifications of a module that determines the absolute value for integers specify different
behaviour patterns for positive and negative integers. In this case, we will form two classes: one
consisting of positive integers and another consisting of negative integers
Two types of classes can always be identified as discussed below:
Valid equivalence classes: - These classes consider valid inputs to the program.
Invalid equivalence classes: - One must not be restricted to valid inputs only.
We should also consider invalid inputs that will generate error conditions or unexpected
behaviour of the program, as shown in Fig. 4.4.
12
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

There are no well-defined rules for identifying equivalence classes, as it is a heuristic process.
However, some guidelines are defined for forming equivalence classes:
 If there is no reason to believe that the entire range of an input will be treated in the same
manner, then the range should be split into two or more equivalence classes.
 If a program handles each valid input differently, then define one valid equivalence class per
valid input.
 Boundary value analysis can help in identifying the classes. For example, for an input
condition, say 0 <= a <= 100, one valid equivalent class can be formed from the valid range of
a. And with BVA, two invalid classes that cross the minimum and maximum values can be
identified, i.e. a < 0 and a > 100.
 If an input variable can identify more than one category, then for each category, we can make
equivalent classes. For example, if the input is a character, then it can be an alphabet, a
number, or a special character. So we can make three valid classes for this input and one
invalid class.
 If the requirements state that the number of items input by the system at some point must lie
within a certain range, specify one valid class where the number of inputs is within the valid
range, one invalid class where there are very few inputs, and one invalid class where there are
too many inputs. For example, specifications state that a maximum of 4 purchase orders can
be registered against a product. The equivalence classes are: the valid equivalence class (1 ≤
no. of purchase orders ≤ 4), the invalid class (no. of purchase orders > 4), and the invalid class
(no. of purchase orders < 1).
 If an input condition specifies a ‘must be’ situation (e.g., ‘first character of the identifier must
be a letter’), identify a valid equivalence class (it is a letter) and an invalid equivalence class (it
is not a letter).
 Equivalence classes can be of the output desired in the program. For an output equivalence
class, the goal is to generate test cases such that the output for that test case lies in the output
equivalence class. Determining test cases for output classes may be more difficult, but output
classes have been found to reveal errors that are not revealed by just considering the input
classes.
 Look for membership of an input condition in a set or group and identify valid (within the set)
and invalid (outside the set) classes. For example, if the requirements state that a valid
province code is ON, QU, and NB, then identify: the valid class (code is one of ON, QU, NB) and
the invalid class (code is not one of ON, QU, NB).
 If the requirements state that a particular input item match a set of values and each case will
be dealt with differently, identify a valid equivalence class for each element and only one
invalid class for values outside the set. For example, if a discount code must be input as P for a
preferred customer, R for a standard reduced rate, or N for none, and if each case is treated
differently, identify: the valid class code = P, the valid class code = R, the valid class code = N,
the invalid class code is not one of P, R, N.
 If an element of an equivalence class will be handled differently than the others, divide the
equivalence class to create an equivalence class with only these elements and an equivalence
class with none of these elements. For example, a bank account balance may be from 0 to Rs
10 lakh and balances of Rs 1,000 or more are not subject to service charges. Identify: the valid
class: (0 ≤ balance < Rs 1,000), i.e. balance is between 0 and Rs 1,000 – not including Rs 1,000;

13
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

the valid class: (Rs 1,000 ≤ balance ≤ Rs 10 lakh, i.e. balance is between Rs 1,000 and Rs 10
lakh inclusive the invalid class: (balance < 0) the invalid class: (balance > Rs 10 lakh).
2. IDENTIFYING THE TEST CASES: -
A few guidelines are given below to identify test cases through generated equivalence classes:
 Assign a unique identification number to each equivalence class.
 Write a new test case covering as many of the uncovered valid equivalence classes as possible,
until all valid equivalence classes have been covered by test cases.
 Write a test case that covers one, and only one, of the uncovered invalid equivalence classes,
until all invalid equivalence classes have been covered by test cases. The reason that invalid
cases are covered by individual test cases is that certain erroneous-input checks mask or
supersede other erroneous-input checks. For instance, if the specification states ‘Enter type of
toys (Automatic, Mechanical, Soft toy) and amount (1–10000)’, the test case [ABC 0] expresses
two error (invalid inputs) conditions (invalid toy type and invalid amount) will not
demonstrate the invalid amount test case, hence the program may produce an output ‘ABC is
unknown toy type’ and not bother to examine the remainder of the input.

Example 4.5
A program reads three numbers, A, B, and C, with a range [1, 50] and prints the largest number.
Design test cases for this program using equivalence class testing technique.

14
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

Example 4.6: -

15
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

Example 4.7: -
A program takes an angle as input within the range [0, 360] and determines in which quadrant the
angle lies. Design test cases using equivalence class partitioning method.

White-Box Testing Techniques

White-box testing is another effective testing technique in dynamic testing. It is also known
as glass-box testing, as everything that is required to implement the software is visible. The entire
design, structure, and code of the software have to be studied for this type of testing. It is obvious
that the developer is very close to this type of testing. Often, developers use white-box testing
techniques to test their own design and code. This testing is also known as structural or
development testing.
In white-box testing, structure means the logic of the program which has been implemented
in the language code. The intention is to test this logic so that required results or functionalities can
16
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

be achieved. Thus, white-box testing ensures that the internal parts of the software are adequately
tested.
NEED OF WHITE-BOX TESTING: -
The supporting reasons for white-box testing are given below:
1. In fact, white-box testing techniques are used for testing the module for initial stage testing.
Black-box testing is the second stage for testing the software. Though test cases for black box can
be designed earlier than white-box test cases, they cannot be executed until the code is produced
and checked using white-box testing techniques. Thus, white-box testing is not an alternative but
an essential stage.
2. Since white-box testing is complementary to black-box testing, there are categories of bugs
which can be revealed by white-box testing, but not through black-box testing. There may be
portions in the code which are not checked when executing functional test cases, but these will
be executed and tested by white-box testing.
3. Errors which have come from the design phase will also be reflected in the code, therefore we
must execute white-box test cases for verification of code (unit verification).
4. We often believe that a logical path is not likely to be executed when, in fact, it may be executed
on a regular basis. White-box testing explores these paths too.
5. Some typographical errors are not observed and go undetected and are not covered by black-box
testing techniques. White-box testing techniques help detect these errors.

LOGIC COVERAGE CRITERIA: -

Structural testing considers the program code, and test cases are designed based on the logic of the
program such that every element of the logic is covered. Therefore the intention in white-box
testing is to cover the whole logic. The basic forms of logic coverage are
1. Statement Coverage: -
The first kind of logic coverage can be identified in the form of statements. It is assumed that if
all the statements of the module are executed once, every bug will be notified.

If we want to cover every statement in the above code, then the following test cases must be
designed:

Test case 1 just skips the while loop and all loop statements are not executed. Considering test
case 2, the loop is also executed. However, every statement inside the loop is not executed. So
two more cases are designed:

These test cases will cover every statement in the code segment, however statement coverage is
a poor criteria for logic coverage. We can see that test case 3 and 4 are sufficient to execute all
the statements in the code. But, if we execute only test case 3 and 4, then conditions and paths in
test case 1 will never be tested and errors will go undetected. Thus, statement coverage is a
necessary but not sufficient criteria for logic coverage.

17
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

2. Decision or Branch Coverage: -
Branch coverage states that each decision takes on all possible outcomes (True or False) at least
once. In other words, each branch direction must be traversed at least once. In the previous
sample code shown in Figure 5.1, while and if statements have two outcomes: True and False. So
test cases must be designed such that both outcomes for while and if statements are tested. The
test cases are designed as:

3. Condition Coverage: -
Condition coverage states that each condition in a decision takes on all possible outcomes at
least once. For example, consider the following statement:

In this loop statement, two conditions are there. So test cases should be designed such that
both the conditions are tested for True and False outcomes. The following test cases are
designed:

4. Decision/condition Coverage: -
Condition coverage in a decision does not mean that the decision has been covered. If the
decision

is being tested, the condition coverage would allow one to write two test cases:

But these test cases would not cause the THEN clause of the IF to execute (i.e. execution of
decision). The obvious way out of this dilemma is a criterion called decision/condition coverage.
It requires sufficient test cases such that each condition in a decision takes on all possible
outcomes at least once, each decision takes on all possible outcomes at least once, and each point
of entry is invoked at least once.

5. Multiple condition coverage: -

In case of multiple conditions, even decision/ condition coverage fails to exercise all
outcomes of all conditions. The reason is that we have considered all possible outcomes of each
condition in the decision, but we have not taken all combinations of different multiple
conditions. Certain conditions mask other conditions. For example, if an AND condition is False,
none of the subsequent conditions in the expression will be evaluated. Similarly, if an OR
condition is True, none of the subsequent conditions will be evaluated. Thus, condition coverage
and decision/condition coverage need not necessarily uncover all the errors.
Therefore, multiple condition coverage requires that we should write sufficient test cases
such that all possible combinations of condition outcomes in each decision and all points of entry
are invoked at least once. Thus, as in decision/condition coverage, all possible combinations of
multiple conditions should be considered. The following test cases can be there:

18
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

BASIS PATH TESTING

Basis path testing is the oldest structural testing technique. The technique is based on the control
structure of the program. Based on the control structure, a flow graph is prepared and all the
possible paths can be covered and executed during testing. Path coverage is a more general
criterion as compared to other coverage criteria and useful for detecting more errors. But the
problem with path criteria is that programs that contain loops may have an infinite number of
possible paths and it is not practical to test all the paths. Some criteria should be devised such that
selected paths are executed for maximum coverage of logic. Basis path testing is the technique of
selecting the paths that provide a basis set of execution paths through the program.
The guidelines for effectiveness of path testing are discussed below:
1. Path testing is based on control structure of the program for which flow graph is prepared.
2. Path testing requires complete knowledge of the program’s structure.
3. Path testing is closer to the developer and used by him to test his module.
4. The effectiveness of path testing gets reduced with the increase in size of software under test.
5. Choose enough paths in a program such that maximum logic coverage is achieved.

1 CONTROL FLOW GRAPH: -

The control flow graph is a graphical representation of control structure of a program. Flow
graphs can be prepared as a directed graph. A directed graph (V, E) consists of a set of vertices V
and a set of edges E that are ordered pairs of elements of V. Based on the concepts of directed
graph, following notations are used for a flow graph:
 Node: - It represents one or more procedural statements. The nodes are denoted by a circle.
These are numbered or labeled. „
 Edges or links: - They represent the flow of control in a program. This is denoted by an arrow
on the edge. An edge must terminate at a node. „
 Decision node: - A node with more than one arrow leaving it is called a decision node. „
 Junction node: - A node with more than one arrow entering it is called a junction. „
 Regions: - Areas bounded by edges and nodes are called regions. When counting the regions,
the area outside the graph is also considered a region.

2 FLOW GRAPH NOTATIONS FOR DIFFERENT PROGRAMMING CONSTRUCTS: -

Since a flow graph is prepared on the basis of control structure of a program, some
fundamental graphical notations are shown here (see Fig. 5.2) for basic programming constructs.
Using the above notations, a flow graph can be constructed. Sequential statements having no
conditions or loops can be merged in a single node. That is why, the flow graph is also known as
decision-to-decision-graph or DD graph.

3 PATH TESTING TERMINOLOGY: -

19
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

Path: - A path through a program is a sequence of instructions or statements that starts 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.

Segment: - Paths consist of segments. The smallest segment is a link, that is, a single process that
lies between two nodes (e.g., junction-process-junction, junctionprocess-decision, decision-
process-junction, and decision-process-decision). A direct connection between two nodes, as in
an unconditional GOTO, is also called a process by convention, even though no actual processing
takes place.

Path segment: - A path segment is a succession of consecutive links that belongs to some path.

Length of a path: - The length of a path is measured by the number of links in it and not by the
number of instructions or statements executed along the path. An alternative way to measure
the length of a path is by the number of nodes traversed. This method has some analytical and
theoretical benefits. If programs are assumed to have an entry and an exit node, then the number
of links traversed is just one less than the number of nodes traversed.

Independent path: - An independent path is any path through the graph that introduces at least
one new set of processing statements or new conditions. An independent path must move along
at least one edge that has not been traversed before the path is defined.

4 CYCLOMATIC COMPLEXITY: -
McCabe has given a measure for the logical complexity of a program by considering its control
flow graph. His idea is to measure the complexity by considering the number of paths in the
control graph of the program. But even for simple programs, if they contain at least one cycle, the
number of paths is infinite. Therefore, he considers only independent paths.

In the graph shown in Figure 5.3, there are six possible paths: acei, acgh, acfh, bdei, bdgh,
bdfj.
In this case, we would see that, of the six possible paths, only four are independent, as the
other two are always a linear combination of the other four paths. Therefore, the number of
independent paths is 4. In graph theory, it can be demonstrated that in a strongly connected
graph (in which each node can be reached from any other node), the number of independent
paths is given by

where n is the number of nodes and e is the number of arcs/edges.

However, it may be possible that the graph is not strongly connected. In that case, the above
formula does not fi t. Therefore, to make the graph strongly connected, we add an arc from the
last node to the fi rst node of the graph. In this way, the fl ow graph becomes a strongly
connected graph. But by doing this, we increase the number of arcs by 1 and therefore, the
number of independent paths (as a function of the original graph) is given by

This is called the cyclomatic number of a program. We can calculate the cyclomatic number only
by knowing the number of choice points (decision nodes) d in the program. It is given by
20
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

This is also known as Miller’s theorem. We assume that a k-way decision point contributes for
k−1 choice points.
The program may contain several procedures also. These procedures can be represented as
separate flow graphs. These procedures can be called from any point but the connections for
calling are not shown explicitly. The cyclomatic number of the whole graph is then given by the
sum of the numbers of each graph. It is easy to demonstrate that, if p is the number of graphs and
e and n are referred to as the whole graph, the cyclomatic number is given by

And Miller’s theorem becomes

Formulae Based on Cyclomatic Complexity

Based on the cyclomatic complexity, the following formulae are being summarized.

Guidelines for Basis Path Testing: -

We can use the cyclomatic complexity number in basis path testing. Cyclomatic number, which
defines the number of independent paths, can be utilized as an upper bound for the number of
tests that must be conducted to ensure that all the statements have been executed at least once.
Thus, independent paths are prepared according to the upper limit of the cyclomatic number.
The set of independent paths becomes the basis set for the flow graph of the program. Then test
cases can be designed according to this basis set.
21
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

The following steps should be followed for designing test cases using path testing: ƒ
 Draw the flow graph using the code provided for which we have to write test cases. ƒ
 Determine the cyclomatic complexity of the flow graph. ƒ
 Cyclomatic complexity provides the number of independent paths. Determine a basis set of
independent paths through the program control structure. ƒ
 The basis set is in fact the base for designing the test cases. Based on every independent path,
choose the data such that this path is executed.
Example 1

22
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

23
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

Example 2

24
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

25
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

Example 3: -

26
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

27
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

Example 4: -

28
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

29
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

Example 5: -

30
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

5. APPLICATIONS OF PATH TESTING: -

Path testing has been found better suitable as compared to other testing methods. Some of its
applications are discussed below.
Thorough testing / More coverage: - Path testing provides us the best code coverage, leading
to a thorough testing. Path coverage is considered better as compared to statement or branch
coverage methods because the basis path set provides us the number of test cases to be covered
which ascertains the number of test cases that must be executed for full coverage. Generally,
branch coverage or other criteria gives us less number of test cases as compared to path testing.
Cyclomatic complexity along with basis path analysis employs more comprehensive scrutiny of
code structure and control flow, providing a far superior coverage technique.
31
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

Unit testing: - Path testing is mainly used for structural testing of a module. In unit testing, there
are chances of errors due to interaction of decision outcomes or control flow problems which are
hidden with branch testing. Since each decision outcome is tested independently, path testing
uncovers these errors in module testing and prepares them for integration.
Integration testing: - Since modules in a program may call other modules or be called by some
other module, there may be chances of interface errors during calling of the modules. Path
testing analyses all the paths on the interface and explores all the errors.
Maintenance testing: - Path testing is also necessary with the modified version of the software.
If you have earlier prepared a unit test suite, it should be run on the modified software or a
selected path testing can be done as a part of regression testing. In any case, path testing is still
able to detect any security threats on the interface with the called modules.
Testing effort is proportional to complexity of the software: - Cyclomatic complexity number
in basis path testing provides the number of tests to be executed on the software based on the
complexity of the software. It means the number of tests derived in this way is directly
proportional to the complexity of the software. Thus, path testing takes care of the complexity of
the software and then derives the number of tests to be carried out.
Basis path testing effort is concentrated on error-prone software: - Since basis path testing
provides us the number of tests to be executed as a measure of software cyclomatic complexity,
the cyclomatic number signifies that the testing effort is only on the error-prone part of the
software, thus minimizing the testing effort.

LOOP TESTING
Loop testing can be viewed as an extension to branch coverage. Loops are important in the
software from the testing viewpoint. If loops are not tested properly, bugs can go undetected. Loop
testing can be done effectively while performing development testing (unit testing by the
developer) on a module. Sufficient test cases should be designed to test every loop thoroughly.
There are four different kinds of loops. How each kind of loop is tested, is discussed below.
1. Simple loops: - Simple loops mean, we have a single loop in the flow, as shown in Fig. 5.9.

The following test cases should be considered for simple loops while testing them:
 Check whether you can bypass the loop or not. If the test case for bypassing the loop is
executed and, still you enter inside the loop, it means there is a bug.
 Check whether the loop control variable is negative.
 Write one test case that executes the statements inside the loop.
 Write test cases for a typical number of iterations through the loop.
 Write test cases for checking the boundary values of the maximum and minimum number of
iterations defined (say min and max) in the loop. It means we should test for min, min+1,
min−1, max−1, max, and max+1 number of iterations through the loop.

2. Nested loops: - When two or more loops are embedded, it is called a nested loop, as shown in
Fig. 5.10. If we have nested loops in the program, it becomes difficult to test. If we adopt the
approach of simple tests to test the nested loops, then the number of possible test cases grows
geometrically. Thus, the strategy is to start with the innermost loops while holding outer loops to
their minimum values. Continue this outward in this manner until all loops have been covered.

32
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

3. Concatenated loops: - The loops in a program may be concatenated (Fig. 5.11). Two loops are
concatenated if it is possible to reach one after exiting the other, while still on a path from entry
to exit. If the two loops are not on the same path, then they are not concatenated. The two loops
on the same path may or may not be independent. If the loop control variable for one loop is
used for another loop, then they are concatenated, but nested loops should be treated like nested
only.

4. Unstructured loops: - This type of loops is really impractical to test and they must be
redesigned or at least converted into simple or concatenated loops.

DATA FLOW TESTING

In path coverage, the stress was to cover a path using statement or branch coverage.
However, data and data integrity is as important as code and code integrity of a module. We have
checked every possibility of the control flow of a module. But what about the data flow in the
module? Has every data object been initialized prior to use? Have all defined data objects been used
for something? These questions can be answered if we consider data objects in the control flow of a
module.
Data flow testing is a white-box testing technique that can be used to detect improper use of
data values due to coding errors. Errors may be unintentionally introduced in a program by
programmers. For instance, a programmer might use a variable without defining it. Moreover, he
may define a variable, but not initialize it and then use that variable in a predicate. For example
int a;
if(a == 67) { }
In this way, data flow testing gives a chance to look out for inappropriate data definition, its
use in predicates, computations, and termination. It identifies potential bugs by examining the
patterns in which that piece of data is used. For example, if an out-of-scope data is being used in a
computation, then it is a bug. There may be several patterns like this which indicate data anomalies.
33
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

To examine the patterns, the control flow graph of a program is used. This test strategy
selects the paths in the module’s control flow such that various sequences of data objects can be
chosen. The major focus is on the points at which the data receives values and the places at which
the data initialized has been referenced. Thus, we have to choose enough paths in the control flow
to ensure that every data is initialized before use and all the defined data have been used
somewhere. Data flow testing closely examines the state of the data in the control flow graph,
resulting in a richer test suite than the one obtained from control flow graph based path testing
strategies like branch coverage, all statement coverage, etc.
1. STATE OF A DATA OBJECT: -
A data object can be in the following states:
i. Defined (d): - A data object is called defined when it is initialized, i.e. when it is on the left
side of an assignment statement. Defined state can also be used to mean that a file has been
opened, a dynamically allocated object has been allocated, and something is pushed onto the
stack, a record written, and so on.
ii. Killed/Undefined/Released (k): - When the data has been reinitialized or the scope of a
loop control variable finishes, i.e. exiting the loop or memory is released dynamically or a file
has been closed.
iii. Usage (u): - When the data object is on the right side of assignment or used as a control
variable in a loop, or in an expression used to evaluate the control flow of a case statement, or
as a pointer to an object, etc. In general, we say that the usage is either computational use (c-
use) or predicate use (p-use).

2. DATA-FLOW ANOMALIES: -
Data-flow anomalies represent the patterns of data usage which may lead to an incorrect
execution of the code. An anomaly is denoted by a two-character sequence of actions. For
example, ‘dk’ means a variable is defined and killed without any use, which is a potential bug.
There are nine possible two-character combinations out of which only four are data anomalies,
as shown in Table 5.1.

It can be observed that not all data-flow anomalies are harmful, but most of them are suspicious
and indicate that an error can occur. In addition to the above two-character data anomalies,
there may be single-character data anomalies also. To represent these types of anomalies, we
take the following conventions:
~x : indicates all prior actions are not of interest to x.
x~ : indicates all post actions are not of interest to x.
34
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

All single-character data anomalies are listed in Table 5.2.

3. TERMINOLOGY USED IN DATA FLOW TESTING: -

Some terminology, which will help in understanding all the concepts related to data-flow testing,
is being discussed. Suppose P is a program that has a graph G(P ) and a set of variables V. The
graph has a single entry and exit node.
a) Definition node: - Defining a variable means assigning value to a variable for the very first
time in a program. For example, input statements, assignment statements, loop control
statements, procedure calls, etc.
b) Usage node: - It means the variable has been used in some statement of the program. Node n
that belongs to G(P ) is a usage node of variable v, if the value of variable v is used at the
statement corresponding to node n. For example, output statements, assignment statements
(right), conditional statements, loop control statements, etc.
A usage node can be of the following two types:
i. Predicate Usage Node: If usage node n is a predicate node, then n is a predicate usage
node.
ii. Computation Usage Node: If usage node n corresponds to a computation statement in a
program other than predicate, then it is called a computation usage node.
c) Loop-free path segment: - It is a path segment for which every node is visited once at most.
d) Simple path segment: - It is a path segment in which at most one node is visited twice. A
simple path segment is either loop-free or if there is a loop, only one node is involved.
e) Definition-use path (du-path): - A du-path with respect to a variable v is a path between the
definition node and the usage node of that variable. Usage node can either be a p-usage or a c-
usage node.
f) Definition-clear path (dc-path): - A dc-path with respect to a variable v is a path between
the definition node and the usage node such that no other node in the path is a defining node
of variable v.
The du-paths which are not dc-paths are important from testing viewpoint, as these are
potential problematic spots for testing persons. Those du-paths which are definition-clear are
easy to test in comparison to du-paths which are not dc-paths. The application of data flow
testing can be extended to debugging where a testing person finds the problematic areas in code
to trace the bug. So the du-paths which are not dc-paths need more attention.

4. STATIC DATA FLOW TESTING: -

With static analysis, the source code is analysed without executing it. Let us consider an example
of an application given below.

35
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

Example 1: -

Find out the define-use-kill patterns for all the variables in the source code of this application.

36
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

From the above static analysis, it was observed that static data flow testing for the variable ‘hra’
discovered one bug of double definition in line number 1.

Static Analysis is not enough: -

It is not always possible to determine the state of a data variable by just static analysis of the
code. For example, if the data variable in an array is used as an index for a collection of data
elements, we cannot determine its state by static analysis. Or it may be the case that the index is
generated dynamically during execution, therefore we cannot guarantee what the state of the
array element is referenced by that index. Moreover, the static data-flow testing might denote a
certain piece of code to be anomalous which is never executed and hence, not completely
anomalous. Thus, all anomalies using static analysis cannot be determined and this problem is
provably unsolvable.

5. DYNAMIC DATA FLOW TESTING: -

Dynamic data flow testing is performed with the intention to uncover possible bugs in data usage
during the execution of the code. The test cases are designed in such a way that every definition
of data variable to each of its use is traced and every use is traced to each of its definition.
Various strategies are employed for the creation of test cases. All these strategies are defined
below.

All-du Paths (ADUP): - It states that every du-path from every definition of every variable to
every use of that definition should be exercised under some test. It is the strongest data flow
testing strategy, since it is a superset of all other data flow testing strategies. Moreover, this
strategy requires the maximum number of paths for testing.
All-uses (AU): - This states that for every use of the variable, there is a path from the definition
of that variable (nearest to the use in backward direction) to the use.
All-p-uses/Some-c-uses (APU + C): - This strategy states that for every variable and every
definition of that variable, include at least one dc-path from the definition to every predicate use.
If there are definitions of the variable with no p-use following it, then add computational use (c-
use) test cases as required to cover every definition.
All-c-uses/Some-p-uses (ACU + P): - This strategy states that for every variable and every
definition of that variable, include at least one dc-path from the definition to every

37
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

computational use. If there are definitions of the variable with no c-use following it, then add
predicate use (c-use) test cases as required to cover every definition.
All-Predicate-Uses (APU): - It is derived from the APU+C strategy and states that for every
variable, there is a path from every definition to every p-use of that definition. If there is a
definition with no p-use following it, then it is dropped from contention.
All-Computational-Uses (ACU): - It is derived from the strategy ACU+P strategy and states that
for every variable, there is a path from every definition to every c-use of that definition. If there
is a definition with no c-use following it, then it is dropped from contention.
All-Definition (AD): - It states that every definition of every variable should be covered by at
least one use of that variable, be that a computational use or a predicate use.

Example 1: -

38
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

39
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

40
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

6. ORDERING OF DATA FLOW TESTING STRATEGIES: -

While selecting a test case, we need to analyse the relative strengths of various data flow testing
strategies. Figure 5.15 depicts the relative strength of the data flow strategies. In this figure, the
relative strength of testing strategies reduces along the direction of the arrow. It means that all-
du-paths (ADPU) is the strongest criterion for selecting the test cases.

REVIEW QUESTIONS: -
1. What are the types of errors detected by black-box testing?
2. Which type of testing is possible with BVA?
3. Which type of testing is possible with equivalence class partitioning?
4. A program calculates the GCD of three numbers in the range [1, 50]. Design test cases for this
program using BVC, robust testing, and worst-case testing methods.
5. A program takes as input a string (5–20 characters) and a single character and checks whether
that single character is present in the string or not. Design test cases for this program using
BVC, robust testing, and worst-case testing methods.
6.

41
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

7.

8.

9. A program takes as input three angles and determines the type of triangle. If all the three angles
are less than 90, it is an acute angled triangle. If one angle is greater than 90, it is an obtuse
angled triangle. If one angle is equal to 90, it is a right angled triangle.
Design test cases for this program using equivalence class testing technique.
10. What is the need of white-box testing?
11. What are the different criteria for logic coverage?
12. What is basis path testing?
13. Distinguish between decision node and junction node?
14. What is an independent path?
15. What is the significance of cyclomatic complexity?
16. How do you calculate the number of decision nodes for switch-case?
17. How do you calculate the cyclomatic complexity number of the program having many
connected components?
18. Consider the program.

42
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

19. Consider the program to find the greatest number:

20. Consider the following program which multiplies two matrices:

43
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

21.

44
Downloaded by Harsha Priya Sunkara ([email protected])
 lOMoARcPSD|48526483

SOFTWARE TESTING METHODOLOGIES

22.

45
Downloaded by Harsha Priya Sunkara ([email protected])