- black box testing should make use of randomly generated inputs (only a test range should be specified by the tester), to eliminate any guess work by the tester as to the methods of the function
- data outside of the specified input range should be tested to check the robustness of the program
- boundary cases should be tested (top and bottom of specified range) to make sure the highest and lowest allowable inputs produce proper output
- the number zero should be tested when numerical data is to be input
- stress testing should be performed (try to overload the program with inputs to see where it reaches its maximum capacity), especially with real time systems
- crash testing should be performed to see what it takes to bring the system down
- test monitoring tools should be used whenever possible to track which tests have already been performed and the outputs of these tests to avoid repetition and to aid in the software maintenance
- other functional testing techniques include: transaction testing, syntax testing, domain testing, logic testing, and state testing.
- finite state machine models can be used as a guide to design functional tests
- According to Beizer 2 the following is a general order by which tests should be designed:
- Clean tests against requirements.
- Additional structural tests for branch coverage, as needed.
- Additional tests for data-flow coverage as needed.
- Domain tests not covered by the above.
- Special techniques as appropriate–syntax, loop, state, etc.
- Any dirty tests not covered by the above.