The pragmatic shortcut to the second point is to define a range of valid inputs, and to only ensure that the code works for that range.

So, for your example, a reasonable initial definition would be "$a, $b are numbers". If the input does not comply with the specified criteria, then the user gets what they deserve (such as Argument "hello" isn't numeric in multiplication (*), if they've got warnings enabled.)

That way, the developer doesn't have to waste time testing that behaviour, and possibly more importantly, the code doesn't have to waste time sanity checking its inputs. Of course, if it turns out that the function is frequently called with nonsensical parameters, then it does become worth guarding against. But in this specific case, it's reasonable to realise that the arguments should not be strings. Obviously, there are case where it's not so intuitive.

Next you'll realise that I've reduced your test cases back down from 49 to 1. Hooray! Except that I'm wrong: large numbers will still cause potential problems. There are now two intepretations of this though: either there's an error in the code, or there's an error in the specification. In this case, it's probably easier to change the specification, to include the restriction that abs($a)<some value (such that the operation works). Then, when this condition is broken, the function is again free to do whatever it wishes. And it probably will :-) (This is a case, however, where it's probably worth the function actually checking it's inputs, so the specification can be extended with "and if these values are exceeded, then the function dies, in order to locate the erroneous call" unless part of the requirement is a low overhead.) By ensuring that $a and $b are treated symmetrically, we only have to add one test case. At least until we reach the point where both values are "quite large" so that the overflow happens at the addition stage, rather than multiplication.

As for your bonus question, no, there's no guaranteed database available. Instead, you should look at DBI->available_drivers and DBI->data_sources to find out what's around.