Black-Box Testing

requirements

output

input

events

Black Box testing Understanding the algorithm used. Checking the solution functional testing

Black-Box Testing

Black-box testing, also called behavioral testing (Functional 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.
2

Tries to find following types of errors

Tries to find following types of errors:

incorrect or missing functions interface errors errors in data structures or database access behavior or performance errors initialization or 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.

Black-Box Testing
Tests are designed to answer the following questions:

How is functional validity tested? How is 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?
4

Graph-Based Methods
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 relation-ship is exercised and errors are uncovered

To accomplish these steps, the software engineer begins by creating a grapha 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.
5

Simple example

As a simple example, consider a portion of a graph for a word-processing application (Figure B) where Object #1= new file menu select Object #2= document window Object #3= document text. Corresponding relations are shown in fig : B
The software engineer then derives test cases by traversing the graph and covering each of the relationships shown. These test cases are designed in an attempt to find errors in any of the relationships A number of behavioral testing methods that can make use of graphs:

They are:
1.

Transaction flow modeling:The nodes represent steps in some transaction and the the logical connection between steps. links represent

2. Finite state modeling:The nodes represent different user observable states of the software and the links represent the transitions that occur to move fr.om state to state.

3. Data flow modeling:The nodes are data objects and the links are the transformations that occur to translate one data object into another.

4. Timing modeling:The nodes are program objects and the links are the sequential connections between those objects. Link weights are used to specify the required execution times as the program executes. 8

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.

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 classes for an input condition If a set of objects can be linked by relationships that are symmetric, transitive, and reflexive, an equivalence class is present.

An equivalence class represents a 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 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.

10

Equivalence Partitioning

user queries

mouse picks

output formats prompts

FK input data

11

Sample Equivalence Classes

Valid data user supplied commands responses to system prompts file names computational data physical parameters bounding values initiation values output data formatting responses to error messages graphical data (e.g., mouse picks) Invalid data data outside bounds of the program physically impossible data proper value supplied in wrong place
These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005

12

Boundary Value Analysis

user queries

mouse picks

output formats prompts

FK input data

input domain

output domain
13

Boundary Value Analysis

For reasons that are not completely clear, a greater number of errors tends to occur at the boundaries of the input domain rather than in the "center. It is for this reason that boundary value analysis(BVA) has been developed as a testing technique.

Boundary value analysis leads to a selection of test cases that exercise bounding values.
Boundary value analysis is a test case design technique that complements equivalence partitioning. Rather than selecting any element of an equivalence class, BVA leads to the selection of test cases at the "edges" of the class. Rather than focusing solely on input conditions, BVA derives test cases from the output domain as well. 14

Guidelines for BVA are similar in many respects to those provided for equivalence partitioning: 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 vs. pressure table 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. 4. If internal program data structures have prescribed boundaries (e.g., an array has a defined limit of 100 entries), be certain to design a test case to exercise the data structure at its boundary.

15

Back to Back testing or Comparison Testing

There are some situations (e.g., aircraft avionics, automobile braking systems) 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.

16

Independent versions of software be developed for critical applications. Even when only a single version will be used in the delivered computer-based system. These independent versions form the basis of a blackbox testing technique called comparison testing or backto-back testing .
When multiple implementations of the same specification have been produced , test cases designed using other black-box techniques ,are provided as input to each version of the software.

If the output from each version is the same, it is assumed that all implementations are correct. If the output is different, each of the applications is investigated to determine if a defect in one or more versions is responsible for the difference. In most cases, the comparison of output scan be performed by an automated tool.
17