EQUIVALENCE CLASS PARTITIONING
9.4 EQUIVALENCE CLASS PARTITIONING
An input domain may be too large for all its elements to be used as test input (Figure 9.8a). However, the input domain can be partitioned into a finite number of subdomains for selecting test inputs. Each subdomain is known as an equivalence class (EC), and it serves as a source of at least one test input (Figure 9.8b). The objective of equivalence partitioning is to divide the input domain of the system under test into classes, or groups, of inputs. All the inputs in the same class have
a similar effect on the system under test [14, 15]. An EC is a set of inputs that the system treats identically when the system is tested. It represents certain conditions, or predicates, on the input domain. An input condition on the input domain is a predicate over the values of the input domain. A valid input to a system is an element of the input domain that is expected to return a nonerror value. An invalid input is an input that is expected to return an error value. Input conditions are used to partition the input domain into ECs for the purpose of selecting inputs.
Guidelines for EC Partitioning Equivalence classes can be derived from an input domain by a heuristic technique. One can approximate the ECs by identifying classes for which different program behaviors are specified. Identification of ECs becomes easier with experience. Myers suggests the following guidelines to identify ECs [16].
1. An input condition specifies a range [a, b] : Identify one EC for a ≤ X ≤ b and two other classes for X < a and X > b to test the system with invalid inputs.
2. An input condition specifies a set of values : Create one EC for each ele- ment of the set and one EC for an invalid member. For example, if the input is selected from a set of N items, then N + 1 ECs are created:
(i) one EC for each element of the set {M 1 }, {M 2 }, . . . , {M N } and (ii) one EC for elements outside the set {M 1 ,M 2 ,...,M N }.
3. Input condition specifies for each individual value : If the system handles each valid input differently, then create one EC for each valid input. For
(a) Input domain
(b) Input domain partitioned
into four subdomains
Figure 9.8 (a) Too many test inputs; (b) one input selected from each subdomain.
245 example, if the input is from a menu, then create one EC for each menu
9.4 EQUIVALENCE CLASS PARTITIONING
item.
4. An input condition specifies the number of valid values (say N ) : Create one EC for the correct number of inputs and two ECs for invalid inputs—one for zero values and one for more than N values. For example, if a program can accept 100 natural numbers for sorting, then three ECs are created: (i) one for 100 valid input of natural numbers, (ii) one for no input value, and (iii) one for more than 100 natural numbers.
5. An input condition specifies a “must-be” value : Create one EC for a must-be value and one EC for something that is not a must-be value. For example, if the first character of a password must be a numeric char- acter, then we are required to generate two ECs: (i) one for valid values,
{pswd | the first character of pswd has a numeric value}, and (ii) one for invalid values, {pswd | the first character of pswd is not numeric}.
6. Splitting of EC : If elements in a partitioned EC are handled differently by the system, then split the EC into smaller ECs.
Identification of Test Cases from ECs Having identified the ECs of an input domain of a program, test cases for each EC can be identified by the following:
Step 1: Assign a unique number to each EC. Step 2: For each EC with valid input that has not been covered by test cases yet,
write a new test case covering as many uncovered ECs as possible. Step 3: For each EC with invalid input that has not been covered by test cases,
write a new test case that covers one and only one of the uncovered ECs. In summary, the advantages of EC partitioning are as follows:
A small number of test cases are needed to adequately cover a large input domain.
• One gets a better idea about the input domain being covered with the selected test cases.
• The probability of uncovering defects with the selected test cases based on EC partitioning is higher than that with a randomly chosen test suite of the same size.
• The EC partitioning approach is not restricted to input conditions alone; the technique may also be used for output domains.
Example: Adjusted Gross Income. Consider a software system that computes income tax based on adjusted gross income (AGI) according to the following rules:
If AGI is between $1 and $29,500, the tax due is 22% of AGI. If AGI is between $29,501 and $58,500, the tax due is 27% of AGI. If AGI is between $58,501 and $100 billion, the tax due is 36% of AGI.
246 CHAPTER 9 FUNCTIONAL TESTING
TABLE 9.10 Generated Test Cases to Cover Each Equivalence Class Test Case
Equivalence Class Number
Test Value
Being Tested TC 1 $22,000
Expected Result
TC 4 $-20,000 Rejected with an error message
EC2
TC 5 $150 billion Rejected with an error message
EC5
In this case, the input domain is from $1 to $100 billion. There are three input conditions in the example:
1. $1 ≤ AGI ≤ $29,500.
2. $29,501 ≤ AGI ≤ $58,500.
3. $58,501 ≤ AGI ≤ $100 billion. First we consider condition 1, namely, $1 ≤ AGI ≤ $29,500, to derive two ECs:
EC1 : $1 ≤ AGI ≤ $29,500; valid input. EC2 : AGI < 1; invalid input.
Then, we consider condition 2, namely, $29,501 ≤ AGI ≤ $58,500, to derive one EC:
EC3 : $29,501 ≤ AGI ≤ $58,500; valid input. Finally, we consider condition 3, namely, $58,501 ≤ AGI ≤ $100 billion, to derive
two ECs: EC4 : $58,501 ≤ AGI ≤ $100 billion; valid input.
EC5 : AGI > $100 billion; invalid input. Note that each condition was considered separately in the derivation of ECs. Con-
ditions are not combined to select ECs. Five test cases are generated to cover the five ECs, as shown in Table 9.10.
In the EC partition technique, a single test input is arbitrarily selected to cover a specific EC. We need to generate specific test input by considering the extremes, either inside or outside of the defined EC partitions. This leads us to the next technique, known as boundary value analysis, which focuses on the boundary of the ECs to identify test inputs.