While and do-while loop in the white box method of loop testing

Question

I'm trying to understand how this method works and everywhere I check it I find there's something faulty or maybe it's that I'm not understanding something from the method.

Here there's an explanation of the method for reference.

Some things of the method don't make much of a sense for a while or do-while loop. I mean, if you use a while or do-while loop it's because you don't know how much iterations the loop is going to have.

In this case I don't see things like these ones to hold a meaning:

• Design a test in which a loop body is executed some "typical" number of times.

  What's the typical number of times for a while or do-while loop? Those loops usually depend on the user taking some action, so I don't think it makes any sense talking about executing a "typical" number of times as it's highly dependent on the user. Unless we consider "typical" the amount of times the user is likely to use the loop, which I find impossible to know under any reasonable standard.

• Work outward, conducting tests (as described above) for each loop, while holding the number of iterations of outer loops at the minimal nonzero values possible (that is, the minimal values that can be used when the inner loop body is to be executed the desired number of times)[...]

  What's a minimum value for a while or do-while loop, I can undersand that maybe if there where to be a condition like while (int_num>0) it could be tested for int_num=1, but how would it be done if the condition were a String comparison for example?

Thanks for your time.

Answer 1

First off, although the test method is only described in terms of do-while and while-do loops, the method applies equally to for and foreach loops. For- and foreach-loops can be seen as a syntactic sugar around a while-do loop.

---

Regarding the first question, you may not know exactly how many iterations the loop will go through, but you should have an idea if, in a normal situation

• the loop should not execute and it exists only to wait for a condition that normally will be true beforehand
• the loop should execute once and it exists mainly to retry the operation if is unexpectedly fails
• the loop should execute a few tens of cycles
• the loop should execute a few hundreds to thousands of cycles

This knowledge should be used to determine the "typical" number of times that a loop is executed. The number of iterations used in this test doesn't have to be spot on, but it is good to have it within an order of magnitude of the actual number of iterations that the loop executes in real life.

---

Regarding the second question, setting up such a test requires knowledge of exactly what those loops do, which is not a problem for white-box testing.

The idea here is that the number of iterations of the inner loop can depend on the outer loop. In many cases, the minimum number of iterations for the outer loops will be 1, but it could be that an inner loop is restricted to at most N times. If you then want to have 3N iterations in total of the inner loop body, you need to iterate 3 times over the outer loop.

Answer 2

A "typical" number of iterations is simply any other value than the "special" values, usually 0, 1 and maybe 2. 0 iterations means that whatever the loop does never gets done, so you want to make sure that no problems occur because of that (e.g. undefined value for counter, etc.). One iteration means that values written by the loop may never get read. Two iterations is the first case where the actions taken by the loop can have a cumulative effect, i.e. influence what happens the second time round. Therefore it makes sense to test what happens for 0, 1 and 2 iterations. The idea is that any problem with the loop is likely to become visible during at least one of these tests.

A test with a "typical" number of iterations, like 10 or so, is probably not going to expose additional errors in fundamental logic, but it may be useful to verify that the loop does exactly what it should, e.g. maintain a count of processed items, not overflow values, etc. All of this is true whether you have a for loop or a while loop.

With nested loops it makes sense to exercise these cases for each level of the loop. With three levels, you could in theory test 0x0x0 iterations, 1x0x0 iterations, 2x0x0 and 10x0x0 iterations etc. etc. up to 10x10x10 iterations. It's debatable whether you should need to test all 4³ = 64 combinations or just each possible count for each level, i.e. 12 combinations, but each of those checks slightly different conditions, so it's a good idea to have at least those.