The key question here is the allocation of time and effort. For anything other than a very tiny, trivial embedded controller, the things you COULD test go quickly into the billions and trillions if you start trying to enumerate them. Randomly thinking up cool and clever obscure things to test might be emotionally satisfying, but you may not be helping anyone by doing so. In fact, given your limited time budget, you might actually be hurting.
The better approach is:
1) How much time to I have available and how many tests can I perform in that time?
2) Given the extremely tiny percentage of "total coverage" involved, what are the most valuable things I can test with that time?
This second one is very difficult and will change depending on where you are in the development path. For example, early in the program you will want to identify particular tests which if failed eliminate large parts of the functionality of the product (a whole subsystem won't come to life at all) You certainly don't want to be fiddling around with some clever "out of the box" test in some obscure corner of the product if you have not yet verified that all the major subsystems are up and running.
If and when you get to a stage in the program at which all the predefined tests of major functions pass and you have extra time on your hands (very few projects ever ewch this stage) then you might to start to be creative. Even then, however, the focus should be on some careful thought about what matters to the customer and attack that in some sort of priority order.
The FMEA framework mentioned above is an excellent place to start. Although most FMEA material is hardware focused, you can certainly produce a sensible, simple framework for examining your software system as well. I usually recommend something like this:
A) list all inputs at a high, functinal level (get ocean water temperature)
B) list all outputs (command rudder to turn, print weather report, sound fire alarm)
C) list transformations ie: big blocks of function that turn inputs into outputs
D) list underlying platform services your software is dependent on.
Then go throught this list and ask "what would happen to my customer if this item was totally missing" or (usually worse!) if the item was there, but was erroneous.
Go through that list and get some sense of how severly the customer would be hurt. Focus the little bit of extra time you might have on the top few most severe impact items on the list. For these items, do all the things that everyone else mentioned. Try to make it fail. Stress test it. Use yiur creativity..
Hope this helps,