BLACK-BOX TESTING

Black-Box Testing Strategy

• Black-box testing also called behavioral testing focuses on the functional requirements of the software.
• It is not an alternative to white-box testing.
• It is a complementary approach that is likely to uncover a different class of errors than white-box testing.
• It attempts to find errors in the following categories:

i. Incorrect or missing functions

ii. Interface errors

iii. Errors in data structures or external database access

iv. Behavior or performance errors

v. Initialization and termination errors

• Since we are looking at procedural details / internal logic in white-box testing it is performed on components and hence during the early part of testing.
• Black-box testing is applied at the later stages of testing.

            Graph-Based Testing Methods

• Black-box methods based on the nature of the relationships (links) among the program objects (nodes), test cases are designed to traverse the entire graph
• In this testing we have to define objects and relationships between them, represent them in graphical form and designing tests to make sure that all objects and the relationships are covered.
• The graph consists of nodes (objects), node weights (property of node – specific data value), links (relationships) and link weights (characteristic of a link).
• There is a number of behavioral testing methods that can make use of graphs:

                                                               i.      Transaction flow testing (nodes represent steps in some transaction and links represent logical connections between steps that need to be validated)

                                                             ii.      Finite state modeling (nodes represent user observable states of the software and links represent transitions between states)

                                                            iii.      Data flow modeling (nodes are data objects and links are transformations from one data object to another)

                                                           iv.      Timing modeling (nodes are program objects and links are sequential connections between these objects, link weights are required execution times)

            Equivalence Partitioning

• Black-box technique that divides the input domain into classes of data from which test cases can be derived
• An ideal test case uncovers a class of errors that might require many arbitrary test cases to be executed before a general error is observed
• Equivalence class guidelines:

                                                             v.      If input condition specifies a range, one valid and two invalid equivalence classes are defined

                                                           vi.      If an input condition requires a specific value, one valid and two invalid equivalence classes are defined

                                                          vii.      If an input condition specifies a member of a set, one valid and one invalid equivalence class is defined

                                                        viii.      If an input condition is Boolean, one valid and one invalid equivalence class is defined

            Boundary Value Analysis

• Black-box technique that focuses on the boundaries of the input domain rather than its center
• For reasons that are not completely clear, a greater number of errors tend to occur at the boundaries rather than in the “center”.
• For this reason boundary value analysis (BVA) has been defined as a testing technique.
• Here we give more emphasis to the values near the boundary.
• If an input condition specifies a range of values between a and b, test cases are designed with values a and b and just above and below a and b.
• Instead of range if the input condition specifies a number of values, test cases are designed with minimum value, maximum value and numbers just above and below them.
• Apply guidelines 1 and 2 to output conditions, test cases should be designed to produce the minimum and maxim output reports
• If internal program data structures have boundaries (e.g. size limitations), be certain to test the boundaries

            Comparison Testing

• There are some situations (aircraft avionics, automobile braking system) in which the reliability of software is absolutely critical.
• In such applications redundant hardware and software are often used to minimize the possibility of error. When redundant software is developed, separate software engineering teams develop independent versions of an application using the same specification.
• In such situations, each version can be tested with the same test data to ensure that all provide identical output.
• Then all versions are executed in parallel with real-time comparison of results to ensure consistency. This is called comparison testing or back-to-back testing.

          Orthogonal Array Testing

• Black-box technique that enables the design of a reasonably small set of test cases that provide maximum test coverage
• Focus is on categories of faulty logic likely to be present in the software component (without examining the code)
• There are many applications in which the input domain is relatively small i.e. number of input parameters is small and values that each parameter can take are bounded.
• For example 3 variables x, y, z and each can take 3 values. In this case there are 27 different combinations and exhaustive testing may be possible but will be time consuming and hence we can apply a technique called orthogonal array testing.
• With only 9 test cases dispersed uniformly we can cover input domain more completely.