I would say that your test script should test every possible outcome where that is feasible. It should test everything that can reasonably be tested, and particular emphasis should be given to checking the things that are obviously bound to happen do in fact happen.

If you are new to writing tests, this might sound like a nit-picking waste of time. Having spent some years qa testing code written by far more talented developers than myself, I think that it's definitely worth the extra effort. Just about any code a programmer thinks is ready for testing will (appear to) work fine in most common use cases, otherwise it wouldn't have been submitted. Obviously you should still test for this, but bugs are more likely to be unearthed in corner cases, or in situations where the program isn't doing what it looks like it's doing. (If that doesn't make sense to you, start writing some rigorous test scripts and it soon will).

If you have the resources, aim to have additional test scripts written by someone other than the author and based purely on the documented interface. This not only results in a test unbiased by the implementation, but will quickly improve the quality of your documentation.

You can also look at the test scripts for some large CPAN based distributions with multiple authors (one of the web frameworks, for example), to get an idea of the scope and depth of testing that is possible.