The equivalence partitions are usually derived from the requirements specification for input attributes that influence the processing of the test object.
Given an input test vector some instructions of that algorithm get covered, ( see code coverage for details ) others do not.
This would evidently mean that the relation cover C would partition the domain of the test vector into multiple equivalence class.
To solve the input problem, we take refuge in the inequation There is a fixed size of Integer (computer science) hence, the z can be replaced with:- and with x ∈ { INT_MIN , ... , INT_MAX } and y ∈ { INT_MIN , ... , INT_MAX } The values of the test vector at the strict condition of the equality that is INT_MIN = x + y and INT_MAX = x + y are called the boundary values, Boundary-value analysis has detailed information about it.
In other words, it is sufficient to select one test case out of each partition to check the behaviour of the program.
An additional effect of applying this technique is that you also find the so-called "dirty" test cases.
An inexperienced tester may be tempted to use as test cases the input data 1 to 12 for the month and forget to select some out of the invalid partitions.
Regarding the input and output interfaces to the component this difference will not be noticed, however in your grey-box testing you would like to make sure that both paths are examined.
For this example this would be: To check for the expected results you would need to evaluate some internal intermediate values rather than the output interface.
Blanket test coverage can reveal bugs that would not be caught using the equivalence partitioning method, if the software includes sub-partitions which are unknown to the tester.