Information Technology Reference
In-Depth Information
10.13.1 Black-Box Testing
Black-box testing demonstrates that software functions are operational, that output
is correctly produced from input and that databases are properly accessed and
updated. It requires knowledge of the user requirements to conduct such tests.
Black-box testing thus does not directly examine the syntax and internal logical
structure of the software and is therefore not an alternative to white-box testing.
Black-box test cases consist of sets of inputs conditions, either intentionally valid
or invalid, that fully exercise all functional requirements of a program (Schach
2007
). The goal is to verify the specified behavior in the interface of the unit; we
are not interested in how the unit solves this. We send stimuli with different
parameters to the unit, and as output we receive responses or perhaps we see a
change in some attribute. In traditional testing, the equivalence sets are based upon
the parameters, since parameters in object-oriented languages are often references
to objects. A common mistake when you test the code is not to check the output
data. Just to receive output data is not sufficient; we must also make sure that it is
correct. This may involve much work (Jacobson et al.
1992
). Both white-box and
black-box testing uncover errors that occur during coding, but only black-box
testing is focused on uncovering errors that occur in implementing user require-
ments and systems design specifications. Unlike white-box testing, which is per-
formed early in the testing process, black-box testing tends to be conducted during
later stages of testing. Black-box test cases are therefore more appropriate at
integration, systems, and acceptance testing levels (Schach
2007
).
10.13.2 White-Box Testing
White-box testing is based on the direct examination of the internal logical
structure of the software. It uses knowledge of the program structure to develop
efficient and defective tests of the program's functionality. One could assume that
white-box testing can result in a totally correct program. But, logical paths through
a program can become overwhelming even in fairly simple programs. Therefore,
exhaustive white-box testing is impracticable (Schach
2007
). White-box testing is
also called program-based testing, glass-box testing or structural testing. To
examine the effectiveness of our test cases we can use measures of test coverage.
The least coverage is to exercise each decision-to-decision path at least once. A
decision is typically an IF-statement. The minimum requirement should be that all
statements have been executed. Normally this is a reasonable goal for test cov-
erage. A more ambitious goal is exercise all pairs of DD paths. It is hardly ever
possible to test all the possible paths in the system, regardless of parameters or
variable values. Complete path testing can often only be made locally (Jacobson
et al.
1992
).
