If a tester is viewing the software-under-test as a black box with well- defined inputs and outputs, a good approach to selecting test inputs is to use a method called equivalence class partitioning.

**Equivalence
Class Partitioning**

If a tester is viewing the software-under-test as a
black box with well- defined inputs and outputs, a good approach to selecting
test inputs is to use a method called equivalence class partitioning.
Equivalence class partitioning results in a partitioning of the input domain of
the software under test. The technique can also be used to partition the output
domain, but this is not a common usage. The finite number of partitions or
equivalence classes that result allow the tester to select a given member of an
equivalence class as a representative of that class. It is assumed that all
members of an equivalence class are processed in an equivalent way by the
target software.

Using
equivalence class partitioning a test value in a particular class is equivalent
to a test value of any other member of that class. Therefore, if one test case
in a particular equivalence class reveals a defect, all the other test cases
based on that class would be expected to reveal the same defect. We can also
say that if a test case in a given equivalence class did not detect a
particular type of defect, then no other test case based on that class would
detect the defect (unless a subset of the equivalence class falls into another
equivalence class, since classes may overlap in some cases). A more formal
discussion of equivalence class partitioning is given in Beizer.

Based on
this discussion of equivalence class partitioning we can say that the
partitioning of the input domain for the software-under-test using this
technique has the following advantages:

It
eliminates the need for exhaustive testing, which is not feasible.

It guides
a tester in selecting a subset of test inputs with a high probability of
detecting a defect.

It allows
a tester to cover a larger domain of inputs/outputs with a smaller subset
selected

from an
equivalence class.

Most
equivalence class partitioning takes place for the input domain. How does the
tester identify equivalence classes for the input domain? One approach is to
use a set of what Glen

Myers
calls ―interesting‖ input
conditions. The input conditions usually come from a description in the
specification of the software to be tested. The tester uses the conditions to
partition the input domain into equivalence classes and then develops a set of
tests cases to cover (include) all the classes. Given that only the information
in an input/output specification is needed, the tester can begin to develop
black box tests for software early in the software life cycle in parallel with
analysis activities (see Principle 11, Chapter 2). The tester and the analyst
interact during the analysis phase to develop (i) a set of testable
requirements, and (ii) a correct and complete input/output specification. From
these the tester develops, (i) a high-level test plan, and (ii) a preliminary
set of black box test cases for the system. Both the plan and the test cases
undergo further development in subsequent life cycle phases. The V-Model as
described in Chapter 8 supports this approach.

There are
several important points related to equivalence class partitioning that should
be made to complete this discussion.

The
tester must consider both valid and invalid equivalence classes. Invalid
classes represent erroneous or unexpected inputs.

Equivalence
classes may also be selected for output conditions.

The
derivation of input or outputs equivalence classes is a heuristic process. The
conditions that are described in the following paragraphs only give the tester
guidelines for identifying the partitions. There are no hard and fast rules.
Given the same set of conditions, individual testers may make different choices
of equivalence classes. As a tester gains experience he is more able to select
equivalence classes with confidence.

In some
cases it is difficult for the tester to identify equivalence classes. The
conditions/boundaries that help to define classes may be absent, or obscure, or
there may seem to be a very large or very small number of equivalence classes
for the problem domain. These difficulties may arise from an ambiguous,
contradictory, incorrect, or incomplete specification and/or requirements
description. It is the duty of the tester to seek out the analysts and meet
with them to clarify these documents. Additional contact with the user/client
group may be required. A tester should also realize that for some software
problem domains defining equivalence classes is inherently difficult, for
example, software that needs to utilize the tax code.

Myers
suggests the following conditions as guidelines for selecting input equivalence
classes [1]. Note that a condition is usually associated with a particular
variable. We treat each condition separately. Test cases, when developed, may
cover multiple conditions and multiple variables.

**List o f Conditions**

1. If an
input condition for the software-under-test is specified as a range of values,
select one valid equivalence class that covers the allowed range and two
invalid equivalence classes, one outside each end of the range.‘‘

For
example, suppose the specification for a module says that an input, the length
of a widget in millimeters, lies in the range 1-499; then select one valid
equivalence class that includes all values from 1 to 499. Select a second
equivalence class that consists of all values less than 1, and a third
equivalence class that consists of all values greater than 499.

2. If an
input condition for the software-under-test is specified as a number of values,
then select one valid equivalence class that includes the allowed number of
values and two invalid equivalence classes that are outside each end of the
allowed number.‘‘

For
example, if the specification for a real estate-related module say that a house
can have one to four owners, then we select one valid equivalence class that
includes all the valid number of owners, and then two invalid equivalence
classes for less than one owner and more than four owners.

3. If an
input condition for the software-under-test is specified as a set of valid
input values, then select one valid equivalence class that contains all the
members of the set and one invalid equivalence class for any value outside the
set.‘‘

For
example, if the specification for a paint module states that the colors RED,
BLUE, GREEN and YELLOW are allowed as inputs, then select one valid equivalence
class that includes the set RED, BLUE, GREEN and YELLOW, and one invalid
equivalence class for all other inputs.

4. If an
input condition for the software-under-test is specified as a ―must be‖ condition, select one valid
equivalence class to represent the ―must be‖
condition and one invalid class that does not include the ―must be‖ condition.‘‘

For
example, if the specification for a module states that the first character of a
part identifier must be a letter, then select one valid equivalence class where
the first character is a letter, and one invalid class where the first
character is not a letter.

5. If the
input specification or any other information leads to the belief that an
element in an equivalence class is not handled in an identical way by the
software-under-test, then the class should be further partitioned into smaller
equivalence classes.‘‘

To show
how equivalence classes can be derived from a specification, consider an
example

in Figure. This is a specification for a module that calculates a square
root. The specification describes for the tester conditions relevant to the

**Function**

**square_root message (x:real) when x>**_**0.0**

**reply (y:real)**

**where y >**_**0.0 & approximately (y*y,x)**

**otherwise
reply exception imaginary_square_root end function**

A
specification of a square root function.

input/output
variables *x* and *y.* The input conditions are that the variable *x* must be a real number and be equal to or greater than 0.0. The
conditions for the output variable *y*
are that it must be a real number equal to or greater than 0.0, whose square is
approximately equal to *x.* If *x* is not equal to or greater than 0.0,
then an exception is raised. From this information the tester can easily
generate both invalid and valid equivalence classes and boundaries. For
example, input equivalence classes for this module are the following:

EC1. The
input variable *x* is real, valid. EC2.
The input variable *x* is not real,
invalid. EC3. The value of *x* is
greater than 0.0, valid. EC4. The value of *x*
is less than 0.0, invalid.

Because
many organizations now use some type of formal or semiformal specifications,
testers have a reliable source for applying the input/output conditions
described by Myers.

After the
equivalence classes have been identified in this way, the next step in test
case design is the development of the actual test cases. A good approach
includes the following steps.

Each
equivalence class should be assigned a unique identifier. A simple integer is
sufficient. Develop test cases for all valid equivalence classes until all have
been covered by (included

in) a
test case. A given test case may cover more than one equivalence class.

Develop
test cases for all invalid equivalence classes until all have been covered
individually. This is to insure that one invalid case does not mask the effect
of another or

prevent
the execution of another.

An
example of applying equivalence class partitioning will be shown in the next
section.

Study Material, Lecturing Notes, Assignment, Reference, Wiki description explanation, brief detail

Software Testing : Test Case Design : Equivalence Class Partitioning |

**Related Topics **

Privacy Policy, Terms and Conditions, DMCA Policy and Compliant

Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.