Black – box testing

Black – box testing: also called behavioral testing, focuses on the functional requirements of the software. That is black-box testing techniques enable you 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. 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 data class isolated? ·        What data rates and data volume can the system tolerate ·        What effect will specific combinations of data have on system operator? Graph – Based Testing Methods :  The first step in black-box testing is to understand the objects5 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, you begin 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. The symbolic representation of a graph is shown in Figure 18.8a. Nodes are represented as circles connected by links that take a number of different forms. A directed link (represented by an arrow) indicates that a relationship moves in only one direction. A bidirectional link also called a symmetric link, implies that the relationship applies in both directions. Parallel links are used when a number of different relationships are established between graph nodes. As a simple  example, consider a portion of a graph for a word-processing application (figure 18.8b) where. Object # 1 = new File (menu selection) Object # 2 = document Window Object # 3 = document Text Referring to the figure, a menu select on new file generates a document window. The node weight of document Window provides a list of the window attributes that are to be expected when the window is generated. The link weight indicates that the window must be generated in less than 1.0 second. An underlined link establishes a symmetric relationship between the new file menu selection and document Text , and parallel links indicate relationships between document Window and document Text Equivalence partitioning : 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. Test-case design for equivalence partitioning is based on an evaluation of equivalence classes for an input condition. If a set or objects can be linked by relationships that are symmetric transitive, and reflexive, an equivalence class is present an equivalence class represents are set of valid or invalid states for input conditions. Typically, an input condition is either 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 member 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. Boundary Value Analysis : A greater number of errors at the boundaries of the input domain rather than in the “centre”. It is for this reason that boundary value analysis (BVA) has been developed as a testing technique. Boundary value analysis leads to al selection of test cases that exercise bounding values. 1. If an input condition specifies a range bounded by values a and b, test cases should be designed with values a and b and just above and just below a and b. 2. If an input condition specifies a number of values, test cases should be developed that exercise the minimum and maximum numbers. Values just above and below minimum and maximum are also tested. 3. Apply guidelines 1 and 2 to output conditions. For example, assume that a temperature versus pressure tables is required as output from an engineering analysis program. Test cases should be designed to create an output report that produces the maximum (and minimum) allowable number of table entries. Orthogonal Array Testing : Orthogonal array testing can be applied to problems in which the input domain is relatively small but too large to accommodate exhaustive testing. The orthogonal array testing method is particularly useful in finding region faults – an error category associated with faulty logic with in a software component. To illustrate the difference between orthogonal array testing and more conventional “one input item at a time” approached, consider a system that has three input items, X,Y, and Z. Each of these input items has three discrete values associated with it. There are 33 = 27 possible test cases. Geometric view of the possible test cases associated with X, Y, and Z illustrated in Figure 18.9. Referring to the figure, one input item at a time may be varied in sequence along each input axis. This results in relatively limited coverage of the input domain (represented by the left-hand cube in the figure) When orthogonal array testing occurs, and L9 orthogonal array of test cases is created. The L9 orthogonal array has a “ balancing property” [Pha 97]. That is test cases (represented by dark dots in the figure) are “ dispersed uniformly throughout the test domain”, as illustrated in the right-hand cube in figure 18.9. Test coverage across the input domain is more complete.            To illustrate the use of the L9 orthogonal array, consider the send function for a fax application. Four parameters, P1, P2, P3 and P4, are passed to the send function. Each takes on three discrete values. For example, P1 takes on values. P1 = 1, send it now P1 = 2, send it one hour later P1 = 3, send if after midnight. P2, P3, and P4 would also take on values of 1,2, and 3, signifying other send functions. If a “one input item at a time” testing strategy were chosen, the following sequence of tests (P1, P2, P3, P4) would be specified: (1,1,1,1), (2,1, 1, 1), (3,1,1,1), (1,2,1,1) (1,3,1,1), (1,1,2,1), (1,1,3,1), (1,1,1,2), and (1,1,1,3).