Page 204 - DCAP405_SOFTWARE_ENGINEERING
P. 204
Unit 12: Testing Tactics
exercised at least once; exercise all the logical decisions based on their true and false sides; (3) Notes
executing all loops at their boundaries and within them; and exercise internal data structures to
ensure their validity.
The reason of conducting white-box testing largely depends upon the nature of defects in software:
Logic errors and incorrect assumptions are inversely proportional to the probability that
a program path will be executed.
We often believe that a logical path is not likely to be executed when, in fact, it may be
executed on a regular basis.
Typographical errors are random.
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 visible 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.
Task Analyze why white box testing is known as glass box 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 — code that is of no use, or never get executed at all, which
can not 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. 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.
LOVELY PROFESSIONAL UNIVERSITY 197