LOOP TESTING

Notes taken from Boris Beizer books:

Two major categories:

End point bugs
Initialization bugs
Single loops test minima:
Bypassing the loop altogether - that is, a set of input values that will cause an immediate exit or that attempts to
cause an immediate exit if the immediate exit case is supposedly impossible
One pass through the loop - many initialization problems are caught by this test
Two passes through the loop before exiting. Some initialization problems will surface only with two or more
passes through the loop
A typical number of passes through the loop, unless covered by some other test
One less than the maximum number of tests
The maximum allowable number of passes
Attempt one or more than the maximum number
One less than any forbidden value, the forbidden value, and one more than the forbidden value
Nested Loops:

Set all but one loop to a typical value and run through the single-loop cases for that loop. Repeat for all loops.
Do minimum values for all loops simultaneously
Set all loops but one to the minimum value and repeat the test cases for that loop. Repeat for all loops.
Do maximum looping values for all loops simultaneously (time permitting)

Unstructured loops:
Suggest redesigning to create structure
Application Indicators:
Every repetitive process deserves loop testing. Any graph with loops should be loop tested, with the possible
exception of finite-state machine graphs because there are too many loops, and domain testing, here the presence of
loops makes the technique effectively impractical.
Bug Assumptions:
No deep assumptions here; just the empirical observation that repetitive processes are difficult to start correctly
and even more difficult to stop. We do one too many or one too few. Also, many bugs come about because someone
assumes that certain preconditions are met when I fact they need not be: for example, assuming that all files have at
least one record.
Limitations and Caveats:
Loop bugs show up mostly in low-level software and tend to have limited impacts. Symptoms tend to show up in
time and place close to where the bug is. Many of these bugs will be caught by the operating system or the runtime
resident portion of the compiler because they will cause memory boundary violations, detectable pointer errors,
reading beyond end of file, and stuff like that. The bugs caught by loop testing are not very subtle, and we would
hope that programmers find and correct them in low-level unit testing, where they often can be found by loop
testing. Don't expect too much from loop testing on mature software.