Equivalence Class Part Ion Ing

Equivalence Class Partitioning Identify groups of system requirements, functions, behaviors. Select common classes of test case inputs. The premise is that a few test cases in each class is enough. It is more effective to test more classes than more test cases in the same class.

Example #1 – Sample Program Example program: Begin Read (AAAAAAAAA A) Print End

What are the equivalence classes?

Example #1 - Solution Equivalence classes for “positive” tests: All 10 inputs consist of the same character in upper case, repeated for each letter of the alphabet. ALL 10 inputs consist of the same character in lower case, repeated for each letter of the alphabet. All 10 inputs are different, mixed case.

Test Cases: TC01 - Input: AAAAAAAAAA TC24 - Input: ZZZZZZZZZZ TC25 - Input: aaaaaaaaaa TC48 - Input: zzzzzzzzzz TC49 - aBcDeFgHi TC50 - IhGfEdCbA

Example #1 - Solution (continued) Equivalence classes for “negative” tests: All 10 inputs are numeric. Mixed numeric and alphabetic inputs. Embedded blanks Input consists of one valid character. Input consists of one invalid character. Input includes special characters (*, & %, etc.) Input consists of 11 characters.

What would be a correct output for these cases?

Equivalence Class Partitioning If a tester is viewing the software-under-test as a black box with elldefined 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 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). 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: 1. It eliminates the need for exhaustive testing, which is not feasible. 2. It guides a tester in selecting a subset of test inputs with a high probability of detecting a defect. 3. It allows a tester to cover a larger domain of inputs/outputs with a smaller subset selected from an equivalence class. •

•

There are several important points related to equivalence class partitioning that should be made to complete this discussion. 1. The tester must consider both valid and invalid equivalence classes.Invalid classes represent erroneous or unexpected inputs. 2. Equivalence classes may also be selected for output conditions. 3. 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. 4. 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 of 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.’’ Example: To show how equivalence classes can be derived from a specification, consider an example in Figure 4.2. This is a specification for a module that calculates a square root.

The specification describes for the tester conditions relevant to the 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. 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. 1. Each equivalence class should be assigned a unique identifier. A

simple integer is sufficient. 2. 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. 3. 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.