Page 273 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Unit 13: Testing

13.5 White Box Testing Notes

Contrary to black box testing, software is viewed as a white box, or glass box in white box
testing, as the structure and flow of the software under test are noticeable to the tester. Testing
plans are made according to the details of the software implementation, such as programming
language, logic, and styles. Test cases are derived from the program structure. White box testing
is also called glass box testing, logic driven testing or design based testing. There are many
techniques available in white box testing, because the problem of intractability is eased by specific
knowledge and attention on the structure of the software under test. The intention of exhausting
some aspect of the software is still strong in white box testing, and some degree of exhaustion
can be achieved, such as executing each line of code at least once (statement coverage), traverse
every branch statements (branch coverage), or cover all the possible combinations of true and
false condition predicates (Multiple condition coverage).
Control flow testing, loop testing, and data flow testing; all maps the corresponding flow
structure of the software into a directed graph. Test cases are carefully selected based on the
criterion that all the nodes or paths are covered or traversed at least once. By doing so we
may discover unnecessary “dead” code that is of no use, or never get executed at all, which
cannot be discovered by functional testing. In mutation testing, the original program code is
perturbed and many mutated programs are created, each contains one fault. Each faulty version
of the program is called a mutant. Test data are selected based on the effectiveness of failing
the mutants. The more mutants a test case can kill, the better the test case is considered. The
problem with mutation testing is that it is too computationally expensive to use. The boundary
between black box approach and white box approach is not clear cut. Many testing strategies
mentioned above, may not be safely classified into black box testing or white box testing. It
is also true for transaction flow testing, syntax testing, finite state testing, and many other
testing strategies not discussed in this text. One reason is that all the above techniques will
need some knowledge of the specification of the software under test. Another reason is that
the idea of specification itself is broad it may contain any requirement including the structure,
programming language, and programming style as part of the specification content. We may
be reluctant to consider random testing as a testing technique. The test case selection is simple
and straightforward, they are randomly chosen. Study in indicates that random testing is more
cost effective for many programs. Some very subtle errors can be discovered with low cost.
And it is also not inferior in coverage than other carefully designed testing techniques. One
can also obtain reliability estimate using random testing results based on operational profiles.
Effectively combining random testing with other testing techniques may yield more powerful
and cost effective testing strategies.
13.5.1 Basis Path Testing

Each independent path in the code is taken for testing:
Data Flow Testing (DFT)

In this approach we track the specific variables through each possible calculation, thus defining
the set of intermediate paths through the code. DFT tends to reflect dependencies but it is mainly
through sequences of data manipulation. In short each data variable is tracked and its use is
verified. This approach tends to uncover bugs like variables used but not initialize, or declared
but not used, and so on.
Path Testing
Path testing is where all possible paths through the code are defined and covered. Its a time
consuming task.

LOVELY PROFESSIONAL UNIVERSITY 267