Equivalence Partitioning:
To keep down our testing costs, we don’t want to write several test cases that test the same aspect of our program. A good test case uncovers a different class of errors (e.g., incorrect processing of all character data) than has been uncovered by prior test cases.
Equivalence partitioning is a strategy that can be used to reduce the number of test cases that need to be developed. Equivalence partitioning divides the input domain of a program into classes. For each of these equivalence classes, the set of data should be treated the same by the module under test and should produce the same answer. Test cases should be designed so the inputs lie within these equivalence classes. For example, for tests of “Go to Jail” the most important thing is whether the player has enough money to pay the $50 fine. Therefore, the two equivalence classes can be partitioned, as shown in Figure.
Equivalence Classes for Player Money
Once you have identified these partitions, you choose test cases from each partition. To start, choose a typical value somewhere in the middle of (or well into) each of these two ranges. See Table 6 for test cases written to test the equivalent classes of money. However, you will note that Test Cases 6 (Player 1 has $1200) and 7 (Player 1 has $100) are both in the same equivalence class. Therefore, Test Case 7 is unlikely to discover any defect not found in Test Case 6.
Test Plan #2 for the Jail Requirement
For each equivalent class, the test cases can be defined using the following guidelines:
To keep down our testing costs, we don’t want to write several test cases that test the same aspect of our program. A good test case uncovers a different class of errors (e.g., incorrect processing of all character data) than has been uncovered by prior test cases.
Equivalence partitioning is a strategy that can be used to reduce the number of test cases that need to be developed. Equivalence partitioning divides the input domain of a program into classes. For each of these equivalence classes, the set of data should be treated the same by the module under test and should produce the same answer. Test cases should be designed so the inputs lie within these equivalence classes. For example, for tests of “Go to Jail” the most important thing is whether the player has enough money to pay the $50 fine. Therefore, the two equivalence classes can be partitioned, as shown in Figure.
Equivalence Classes for Player Money
Once you have identified these partitions, you choose test cases from each partition. To start, choose a typical value somewhere in the middle of (or well into) each of these two ranges. See Table 6 for test cases written to test the equivalent classes of money. However, you will note that Test Cases 6 (Player 1 has $1200) and 7 (Player 1 has $100) are both in the same equivalence class. Therefore, Test Case 7 is unlikely to discover any defect not found in Test Case 6.
Test Plan #2 for the Jail Requirement
For each equivalent class, the test cases can be defined using the following guidelines:
- If input conditions specify a range of values, create one valid and one or two invalid equivalence classes. In the above example, this is (1) less than 50/invalid; (2) 50 or more/valid.
- If input conditions require a certain value (for example R and L for the side in our train example), create an equivalence class of the valid values (R and L) and one of invalid values (all other letters other than R and L). In this case, you need to test all valid values individually and several invalid values.
- If input conditions specify a member of a set, create one valid and one invalid equivalence class.
- If an input condition is a Boolean, define one valid and one invalid class.
Equivalence class partitioning is just the start, though. An important partner to this partitioning is boundary value analysis.
No comments:
Post a Comment