What is Loop Testing? Methodology, Example

What is Loop Testing?

Loop Testing is a software testing type that focuses entirely on the validity of the loop constructs in a program. It is one part of control structure testing, alongside path testing, data validation testing and condition testing.

Loop testing is a white box testing technique, so it is applied by someone who can read the source code and see the loop condition, the counter and the exit path. The tester does not guess at behaviour from the user interface; the loop itself is the object under test.

The diagram below shows where loop testing sits inside the control structure testing family.

Types of loop Tested

Before choosing a strategy, identify which of the four loop classes you are looking at. Examples of types of loop tested are,

• Simple loop — a single loop with one entry and one exit, such as a plain for, while or do-while construct.
• Nested loop — one loop placed inside another, so the inner loop runs to completion on every pass of the outer loop.
• Concatenated loop — two or more loops running one after another in sequence.
• Unstructured loop — an unplanned combination of nested and concatenated loops, usually the result of jumps into or out of a loop body.

The class decides the effort. A simple loop needs a handful of iteration counts; an unstructured loop usually needs the code redesigned before it can be tested at all.

Why do Loop Testing?

Loop Testing is done for the following reasons

• Testing can fix the loop repetition issues
• Loops testing can reveal performance and capacity bottlenecks
• By testing loops, the uninitialised variables in the loop can be determined
• It helps to identify loop initialisation problems.

There is a commercial reason as well. A loop that runs one iteration too many corrupts a total; a loop that never terminates hangs a process. Both defects are cheap to find while the code is still on a developer machine and expensive to find in production.

How to do Loop Testing: Complete Methodology

While testing a loop, it has to be checked at three different levels:

• When the loop is entered
• During its execution, and
• When the loop is left

The testing strategy for all these loops is as follows.

Simple loop

A simple loop has a single entry and a single exit, as shown below.

A simple loop is tested in the following way:

1. Skip the entire loop
2. Make 1 pass through the loop
3. Make 2 passes through the loop
4. Make a passes through the loop where a < b, that is a typical mid-range iteration count
5. Make b, b-1 and b+1 passes through the loop where b is the maximum number of allowable passes through the loop.

The last two cases carry most of the value. Skipping the loop proves the exit condition is evaluated before the body runs, and the b+1 case proves the loop refuses work beyond its declared limit instead of overrunning an array.

Nested Loop

A nested loop multiplies the number of possible iteration combinations, so it is tested from the inside out rather than all at once.

For a nested loop, you need to follow the following steps.

1. Set all the other loops to their minimum value and start at the innermost loop
2. For the innermost loop, perform a simple loop test and hold the outer loops at their minimum iteration parameter value
3. Perform the test for the next loop and work outward
4. Continue until the outermost loop has been tested.

Concatenated Loops

Concatenated loops sit one after another in the same execution path, as the diagram shows.

In concatenated loops, if two loops are independent of each other then they are tested using the simple loop approach, otherwise they are tested as nested loops.

However, if the loop counter of one loop is used as the initial value for the other, the two loops are not considered independent.

Unstructured Loops

Unstructured loops are the hardest case, because control jumps in and out of the loop body at arbitrary points.

For unstructured loops, the design has to be restructured to reflect the use of structured programming constructs. Once the code has been reduced to simple, nested or concatenated forms, the matching strategy above applies.

Loop Testing Example with Test Cases

A worked example makes the iteration counts concrete. Consider a routine that multiplies a running result by every integer from 1 to n, a factorial calculation. The loop counter starts at 1, the exit condition is counter > n, and the loop is declared to accept a maximum of 12 passes before the result overflows the declared integer type.

Treating this as a simple loop, the iteration counts recommended above translate into the following test cases.

Test case	Value of n	Passes executed	What it proves
TC01	0	0 (loop skipped)	The exit condition is evaluated before the body runs, and the result stays at its initialised value of 1.
TC02	1	1	A single pass produces the correct result and the counter increments once.
TC03	2	2	The accumulator carries a value forward between two consecutive passes.
TC04	5	5	A typical mid-range count returns the expected 120, confirming ordinary behaviour.
TC05	11	11	One pass below the maximum still completes normally (b-1).
TC06	12	12	The declared maximum is accepted and the loop terminates (b).
TC07	13	rejected	One pass beyond the maximum is refused rather than silently overflowing (b+1).

Notice that TC01 and TC07 are the two cases developers most often leave out, and they are the two that expose skipped-initialisation and overflow defects. A negative value of n belongs in the same set if the specification allows it to be supplied, which links loop testing to negative testing.

Common Defects Found by Loop Testing

Loop testing keeps finding the same small family of faults, which is what makes the fixed iteration counts worth running every time.

• Off-by-one boundaries — a condition written as < where <= was intended, so the loop runs one pass too few or one too many.
• Uninitialised counters or accumulators — a total that carries a value left over from a previous call.
• Infinite loops — an exit condition that the loop body can never satisfy because the counter is updated on only some branches.
• Skipped-loop assumptions — code after the loop that reads a variable the loop body was expected to set, which fails when the loop runs zero times.
• Capacity and performance faults — a loop that is correct but re-reads the database on every pass, so cost grows with the iteration count.
• Nested-loop interference — an inner loop that reuses the outer loop counter and quietly changes the outer iteration count.

Because each fault maps to a specific iteration count, the defects surfaced here are easy to reproduce and quick to fix compared with defects found at higher test levels.

Loop Testing vs Other Control Structure Testing Techniques

Loop testing is one member of the control structure family, and it is easy to confuse with the neighbouring techniques. The table below separates them.

Technique	What it targets	Typical coverage goal
Loop testing	Loop constructs: entry, iteration counts and exit	Zero, one, typical, and boundary iteration counts for every loop
Condition testing	Boolean expressions inside decisions	Each condition evaluated both true and false
Data flow testing	Definition and use of each variable	Every definition-to-use pair exercised at least once
Basis path testing	Independent paths through the control flow graph	A number of paths equal to the cyclomatic complexity

In practice these techniques are complementary rather than competing. Cyclomatic complexity tells you how many independent paths exist, basis path testing covers them, and loop testing then adds the iteration counts that path coverage alone would not force. All of them are dynamic testing activities, since the code has to be executed for the results to be observed.

Limitation in Loop testing

The technique has real boundaries, and knowing them prevents overinvestment.

• Loop bugs show up mostly in low-level software
• The bugs identified during loop testing are not very subtle
• Many of the bugs might be detected by the operating system, as they cause memory boundary violations, detectable pointer errors and similar faults
• Identifying the class of every loop and testing it accordingly costs time, which is hard to justify on code paths that carry little risk.

FAQs