Path testing is a structural testing method that involves using the source
code of a program to attempt to find every possible executable path. The idea is
that we are then able to test each individual path in as many ways as possible in
order to maximize the coverage of each test case.
If the source code contains loop like for/while/do-while etc the number of test path become larger. My question is, how can one avoid these kinds of looping problem/iteration problem in testing?
.
you can't "avoid" those problems ; you've got to cope with them : loops are there to stay !
my latest reference on this topic is far from up to date but it might be helpful :
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.13.8399
.
Well, with loops the number of possible paths become unbounded, if not infinite. But since you do testing, you do not insist on testing them all. Instead, you can divide the whole set of paths into a finite number of equivalence classes, with some sensical concept of equivalence, and choose to just test one sample from each class. McCabe for example essentially proposes to test linearly independent paths. Ammann and Offutt (their book Introduction to Software Testing) propose to test prime paths. The latter is more thorough, their number can be exponential.
1. You shouldn't avoid them. Loops are just a compact closed form of what your vision of testing would ordinarily test as open code. You aren't off the hook to test loops.
2. Path testing is a very weak indication of coverage and corresponds in no way to the quality of the delivered software. About all it can do is point to possibly dead code. 100% coverage is that you have reproduced every value of the program counter and at each such value you have reproduced all possible bit patterns in data memory. Anything short of that is to ignore half of the Von Neumann paradigm and to fool yourself that you have something of value.
- Badges
- Science topic
- Similar topics
- Human-Computer Interaction
- Collaboration