1

Assume there is any program that is supposed to be tested and you like to perform an equivalence class analysis on it. Let's say you identified six valid and four invalid equivalence classes. Then, how many test-cases need to be created in each case at least?

I'm not sure about that but I think because every equivalence class of input files needs to be considered in at least one test-case, so you will need at least one test-case for each equivalence class? Or maybe even less because it might be possible to skip the invalid equivalence classes..? :S

  • 2
    What do you mean here with invalid equivalence classes? Are those equivalence classes of values that are illegal or invalid for the system being tested? – amon Jan 9 at 16:22
  • 1
    @amon valid equivalence classes you have valid input files while invalid equivalence classes have invalid input files. As example, we have a field where we can enter a date. The valid values (valid equivalence classes) are between 1 and 12 months, 1 to 31 days and starting from 2000, the year. All other values are invalid und therefor belong to invalid equivalence classes. So here the invalid equivalence class is the input the interval [-infinity, 0] while [1, 12] is valid and thus a valid equivalence class. – kathelk Jan 9 at 16:45
6

The number of test cases depends on the goal of these tests. Are we interested in demonstrating:

  • that the system can process valid input correctly, and/or
  • that the system will handle invalid input safely?

The latter is especially important in a security-sensitive context where input must not be able to bring the software into any unexpected state or to crash it. However, this might be irrelevant for internal components that only deal with trusted input.

I believe that instead of thinking in terms of valid or invalid input classes, it may be better to think in inputs that trigger specified or unspecified behavior. Depending on the security requirements there should not be unspecified behavior. This doesn't mean that the system has to process that data, it might be reasonable to throw an exception or abort the process when the inputs don't fit a particular schema. But whenever I decide that the software should behave in a particular way, then I should also test that it does demonstrate that behavior.

For your question this means that I will need at least one test case per “valid” equivalence class. If I have decided how the software should respond to “invalid” inputs, then I need to add at least one test case per “invalid” equivalence class as well.

I'm saying “at least” because you might also want to test edge cases, or may want to sample members of an equivalence class at random. Especially for integral parameters, it usually makes sense to test both the lower and upper bound.

Additionally, functions that take multiple inputs would have to be tested with all combinations of all their equivalence classes to obtain full coverage of the input space. This leads to a combinatorial explosion and is intractable except for trivial cases. Here it makes sense to either use white-box testing techniques to show that some inputs don't matter if other parameters have certain values, or to use common sense to use a subset. However, done carelessly this can hide bugs. E.g. for a function dealing with dates, it depends on the month and year whether the valid range of “day of month” is 1..31, 1..30, 1..29, or 1..28.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.