Loop Testing

  A typical spot for a semantic bug  in most programming languages are the loops. They make path testing difficult due to the significantly increased number of possible paths, and they often contain bugs within the loop condition which are hard to find. A even bigger danger conceals within nested loops . All this justifies to do an extra inspection  of a program's loops.

Introducing a small example which is a simplified version of a fault  found in chapter : 

#!/usr/local/bin/perl -w
open(DB, "filename");
$to_work_with = <DB>;
while (!eof(DB)) {
   print "$to_work_with";
   $to_work_with = <DB>;
}
close DB;

The program opens a certain file, reads it line by line, and processes this input. The problem is that the last line read is never used.

It might seem likely that most loops can be tested with two checks, but a lot of bugs  are not found this way. The condition of a loop has to be checked at three different times: when the loop is entered, during its execution, and when the loop is left. The  two borders are of special interest. See below in the ``domain testing'' section for more information, or read the loop testing chapter in [Beizer95].

Even more dangerous are partly nested loops:

label1:
instruction block A1
label2:
if C1 then goto label1:
instruction block A2
if C2 then goto label2:

Constructions of this kind normally only appear when the command goto  or a similar instruction is used, but in programming languages like assembler it is basically impossible to avoid those commands. Therefore it is necessary to check those programs for constructions of this kind.