Equivalence class test
An equivalence class test is used to check the quality of software .
purpose
The aim of creating equivalence classes is to achieve a high error detection rate with the lowest possible number of test cases. The equivalence classes are therefore similar classes or objects with regard to input and output data that are expected to behave in the same way. For example, in a fleet management program, vehicles have equivalent classes (“Ferrari” and “BMW” are comparable, “Ferrari” and “Employee” are not). The essence of equivalence class formation consists in dividing the entire input data and output data of a program into groups of equivalence classes, so that one can assume that the same errors are found with any object of a class as with any other object of this (equivalence) class ("Ferrari ENZO" would result in the same errors as "BMW M4").
Action
The formation of test cases into equivalence classes follows this sequence:
- Analysis and specification of the input data, the output data and the conditions according to the specifications
- Formation of the equivalence classes by classifying the value ranges for input and output data
- Determination of test cases by selection of values for each equivalence class
The test cases created apply to all objects of the created equivalence class, so that a separate test case does not have to be created for each occurrence.
A distinction is made between valid equivalence classes and invalid equivalence classes . In the case of valid equivalence classes, valid input data is used; in the case of invalid equivalence classes, invalid input data is used.
Equivalence classes are generally created from a logical point of view, paying particular attention to the similarity of the class or object properties and their determination. In the world of object-oriented programming, candidates for the formation of equivalence classes are in particular child and super classes . In the case of abstract classes, attention must be paid to the different implementation of the inherited methods / procedures , especially with regard to input and output parameters. Greatly different implementations for child classes of an abstract class (e.g. "LKW" and "PKW" as child classes of "KFZ") may not be suitable for the formation of equivalence classes (e.g. method: ermittleGueltigeAnzahlAchsen()→ PKW 2; LKW: 3 (only Tractor)).
example
It is shown how a limit value analysis differentiates between valid and invalid equivalence classes. To do this, the date is entered in the entry mask of a generally applicable transaction system. The valid values (valid equivalence classes) are between 1 and 12 for months, 1 and 31 for days and from 2000 for years. All other values are invalid and belong to negative equivalence classes. A test case for monthly values is defined for the test, i.e.:
- [-∞; 0] Input from minus infinity to 0 is rejected as invalid (invalid equivalence class),
- [1; 12] the entry from 1 to 12 is accepted as valid (valid equivalence classes) and
- [13; + ∞] the input / output from 13 to plus infinity is rejected as invalid (invalid equivalence class)
The same test cases are defined for the daily and annual values. Dependencies of the valid daily values on months are not taken into account in the example, as is the connection between different field types in a test case.