Functional Testing - Software Testing: Testing Across the Entire Software Development Life Cycle - page 112

This is one of the areas in which your background and experience as a software
developer will tend to guide you toward zero-causing areas of the software because
that is where you would place it if you were coding it.
7.5.6.3 BufferOverflow
Buffer overfl ow is a particularly insidious programming problem because it does
not manifest itself until the software is relatively busy. The problem arises when
an area in memory called a buffer is set aside to manage transient data like user
input or report output or database records or internet packets. When that buffer
area becomes full of data, something must happen to empty part of the buffer and
accommodate more data. Some refi ll strategies dictate that a full buffer must be
completely emptied before more data can be accommodated. Other refi ll strategies
wrap the data around the buffer, accommodating more data while emptying what it
has. So, you can be fi lling and emptying a buffer a number of different ways when
the buffer overfl ows its area. This can make buffer overfl ow errors exceptionally
challenging to repeat.
The symptoms of buffer overflow are as insidious as the event itself because
when a buffer overflows, it overwrites adjacent areas in the computer's memory.
If that adjacent area also holds data, then the data become corrupt for no apparent
reason. If that adjacent area holds instructions, then the software begins bizarre
behavior that might implicate perfectly correct code under normal conditions.
The buffer overfl ow problem takes on a higher level of testing criticality when
you realize that many computer viruses are introduced by forcing buffer overfl ow
into the software's instructions.
One of the most effective ways to test for buffer overfl ow is to drive the software
with a large volume of input data, force a large volume of internal fi le processing
or database processing, and force a large volume of output for specifi c buffer areas.
As with the date calculation situation, the tester must collaborate with the devel-
oper to identify the specifi c inputs, outputs, fi le processing, and database processing
that rely on specifi c buffers that need to be tested. It may make sense to combine
some of the buffer overfl ow white box testing with later performance black box
testing described in Chapter 9 to get the volume of buffer traffi c necessary to cause
overfl ow.
All of the white box testing techniques presented here attempt to increase the logical
coverage of source code debugging/testing. The underlying premise is that unexecuted
source code is one of the most frequent and predictable sources of defects.
7.6 DETAILED BLACK BOX TESTING TECHNIQUES
The objective of black box testing is to verify the correctness of the software's
behavior that directly supports daily business activity. This objective is often
referred to as behavior coverage. The requirements for black box testing are the