Page 215 - DCAP405_SOFTWARE_ENGINEERING

Software Engineering

Notes

Task No implementation details of the code are considered. Analyze this statement.

It is obvious that the more we have covered in the input space, the more problems we will find
and therefore we will be more confident about the quality of the software. Ideally we would be
tempted to exhaustively test the input space. But as stated above, exhaustively testing the
combinations of valid inputs will be impossible for most of the programs, let alone considering
invalid inputs, timing, sequence, and resource variables. Combinatorial explosion is the major
roadblock in functional testing. To make things worse, we can never be sure whether the
specification is either correct or complete. Due to limitations of the language used in the
specifications (usually natural language), ambiguity is often inevitable. Even if we use some
type of formal or restricted language, we may still fail to write down all the possible cases in the
specification. Sometimes, the specification itself becomes an intractable problem: it is not possible
to specify precisely every situation that can be encountered using limited words. And people
can seldom specify clearly what they want — they usually can tell whether a prototype is, or is
not, what they want after they have been finished. Specification problems contributes
approximately 30 percent of all bugs in software.
The research in black-box testing mainly focuses on how to maximize the effectiveness of
testing with minimum cost, usually the number of test cases. It is not possible to exhaust the
input space, but it is possible to exhaustively test a subset of the input space. Partitioning is one
of the common techniques. If we have partitioned the input space and assume all the input
values in a partition is equivalent, then we only need to test one representative value in each
partition to sufficiently cover the whole input space. Domain testing partitions the input domain
into regions, and consider the input values in each domain an equivalent class. Domains can be
exhaustively tested and covered by selecting a representative value(s) in each domain. Boundary
values are of special interest. Experience shows that test cases that explore boundary conditions
have a higher payoff than test cases that do not. Boundary value analysis requires one or more
boundary values selected as representative test cases. The difficulties with domain testing are
that incorrect domain definitions in the specification can not be efficiently discovered.

Notes Good partitioning requires knowledge of the software structure. A good testing
plan will not only contain black-box testing, but also white-box approaches, and
combinations of the two.
12.2.1 Black-box Testing Techniques

Black-box testing, also called behavioral testing, focuses on the functional requirements of the
software. That is, black-box testing enables the software engineer to derive sets of input conditions
that will fully exercise all functional requirements for a program. Black-box testing is not an
alternative to white-box techniques. Rather, it is a complementary approach that is likely to
uncover a different class of errors than white-box methods.
Black-box testing attempts to find errors in the following categories:
1. incorrect or missing functions,
2. interface errors,

3. errors in data structures or external database access,

208 LOVELY PROFESSIONAL UNIVERSITY