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, (4) behavior or performance errors, and (5) initialization and termination errors.
Unlike white-box testing, which is performed early in the testing process, "black-box testing tends to be applied during later stages of testing. Because black-box testing purposely disregards control structure, attention is focused on the information domain. Tests are designed to answer the following questions:
• How is functional validity tested?
• How are system behavior and performance tested?
• What classes of input will make good test cases?
• Is the system particularly sensitive to certain input values?
• How are the boundaries of a data class isolated?
• What data rates and data volume can the system tolerate?
• What effect will specific combinations of data have on system operation?
By applying black-box techniques, we derive a set of test cases that satisfy the following criteria: (1) test cases that reduce, by a count that is greater than one, the number of additional test cases that must be designed to achieve reasonable testing and (2) test cases that tell us something about the presence or absence of classes of errors, rather than an error associated only with the specific test at hand.
Graph-Based Testing Methods
The first step in black-box testing is to understand the objeCtS6 that are modeled in software and the relationships that connect these objects. Once this has been accomplished, the next step is to define a series of tests that verify "all objects have the expected relationship to one another ." Stated in another way, software testing begins by creating a graph of important objects and their relationships and then devising a series of tests that will cover the graph so that each object and relationship is exercised and errors are uncovered.
To accomplish these steps, the software engineer begins by creating a graph-a collection of nodes that represent objects; links that represent the relationships between objects; node weights that describe the properties of a node (e.g., a specific data value or state behavior); and link weights that describe some characteristic of a link.
Equivalence partitioning is a black-box testing method that divides the input domain of a program into classes of data from which test cases can be derived. An ideal test case single-handedly uncovers a class of errors (e.g., incorrect processing of all character data) that might otherwise require many cases to be executed before the general error is observed. Equivalence partitioning strives to define a test case that uncovers classes of errors, thereby reducing the total number of test cases that must be developed.
Test case design for equivalence partitioning is based on an evaluation of equivalence for an input condition. Using concepts introduced in the preceding section if a set of objects can be linked by symmetric relationships, transitive,e, and reflexive, an equivalence class is present. An equivalence class represents valid or invalid states for input conditions. Typically, an input condition is a specific numeric value, a range of values, a set of related values, or a Boolean condition. Equivalence classes may be defined according to the following guidelines:
1. If an input condition specifies a range, one valid and two invalid equivalence classes are defined.
2. If an input condition requires a specific value, one valid and two invalid equivalence classes are defined.
3. If an input condition specifies a member of a set, one valid and one invalid equivalence class are defined.
4. If an input condition is Boolean, one valid and one invalid class are defined.
As an example, consider data maintained as part of an automated banking application. The user can access the bank using a personal computer, provide a six-digit password and follow with a series of typed commands that trigger various banking functions. During the log-on sequence, the software supplied for the banking applications data in the form
Area code - blank or three-digit number
Prefix - three-digit number not beginning with 0 or 1 Suffix - a four-digit number
Password - a six-digit alphanumeric string
Commands - check, deposit, bill pay, and the like
The input conditions associated with each data element for the banking applications can be specified as
area code: Input condition, Boolean-the area code may or may not be present.
Input condition, range-values defined between 200 and 999, with specific exceptions.
prefix: Input condition, range-specified value >200 Input condition, value-four-digit length
password: Input condition, Boolean-a password may or may not be present.
Input condition, value-six-character string.
Command: Input condition, set-containing commands noted previously.
Applying the guidelines for the derivation of equivalence classes, test cases for each main data item can be developed and executed. Test cases are selected so that the largest number of attributes of an equivalence class is exercised at once.