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.