1. Black-box Testing

2. Contents Black-box Testing Black-box Testing Categories
Types of Black box testing
Equivalence class Partitioning
Boundary Value Analysis
Cause and Effect
Decision Table
Advantages of Black Box Testing
Disadvantages of Black Box Testing

3. Black-box Testing
Complements white-box testing by uncovering different classes of errors
Focuses on the functional requirements and the information domain of the software
Used during the later stages of testing after white box testing has been performed
The tester identifies a set of input conditions that will fully exercise all functional requirements for a program
The test cases satisfy the following:
Reduce, by a count greater than one, the number of additional test cases that must be designed to achieve reasonable testing
Tell us something about the presence or absence of classes of errors, rather than an error associated only with the specific task at hand
BACK

4. Black-box Testing Categories
Incorrect or missing functions
Interface errors
Errors in data structures or external data base access
Behavior or performance errors
Initialization and termination errors
BACK

5. Types of Black box testing
Equivalence class partitioning
Boundary value analysis
Decision Table based testing
Cause Effect Graph
BACK

6. Equivalence class Partitioning
A black-box testing method that divides the input domain of a program into classes of data from which test cases are derived
An ideal test case single-handedly uncovers a complete class of errors, thereby reducing the total number of test cases that must be developed
Test case design is based on an evaluation of equivalence classes for an input condition
An equivalence class represents a set of valid or invalid states for input conditions

7. From each equivalence class, test cases are selected so that the largest number of attributes of an equivalence class are exercise at once
Input values to a program are partitioned into equivalence classes.
Partitioning is done such that:
program behaves in similar ways to every input value belonging to an equivalence class.

8. If the input data to the program is specified by a range of values:
e.g. numbers between 1 to 5000.
one valid and two invalid equivalence classes are defined.
5000 1

9. Example 5000 1 There are three equivalence classes:
the set of negative integers,
set of integers in the range of 1 and 5000,
integers larger than 5000.
5000 1
BACK

10. Boundary Value Analysis
A greater number of errors occur at the boundaries of the input domain rather than in the "center"
Boundary value analysis is a test case design method that complements equivalence partitioning
It selects test cases at the edges of a class
It derives test cases from both the input domain and output domain

11. Some typical programming errors occur:
at boundaries of equivalence classes
might be purely due to psychological factors.
Programmers often fail to see:
special processing required at the boundaries of equivalence classes.
Programmers may improperly use < instead of <=
Boundary value analysis:
select test cases at the boundaries of different equivalence classes.

12. Example
For a function that computes the square root of an integer in the range of 1 and 5000:
test cases must include the values: {0,1,5000,5001}.
5000 1
BACK

13. Cause and Effect Testing would be a lot easier:
if we could automatically generate test cases from requirements.
Work done at IBM:
Can requirements specifications be systematically used to design functional test cases?

14. Cause and Effect Examine the requirements:
restate them as logical relation between inputs and outputs.
The result is a Boolean graph representing the relationships
called a cause-effect graph.
Convert the graph to a decision table:
each column of the decision table corresponds to a test case for functional testing

15. Steps to create cause-effect graph
Study the functional requirements.
Mark and number all causes and effects.
Numbered causes and effects:
become nodes of the graph.
Draw causes on the LHS
Draw effects on the RHS
Draw logical relationship between causes and effects
as edges in the graph.
Extra nodes can be added
to simplify the graph

16. Cause-Effect Graphs A B
If A then B A C B
If (A and B)then C

17. Cause-Effect Graphs A C B
If (A or B) then C A C ~ B
If (not(A and B)) then C

18. Cause-Effect Graphs A C B A B~ B
If (not (A or B))then C ~ A B
If (not A) then B
BACK

19. Decision Table
Two dimensional mapping of condition against actions to be performed
Conditions evaluate to Boolean
Action corresponds to expected activity
They can be derived from Cause Effect graph too
Map cause as condition
Map effect as action

20. Cause effect graph- Decision table
Test 1
Test 2
Test 3
Test 4
Test 5
Cause 1 I I I S I I I X S
Cause 2 I S X
Cause 3 I S X X I S X
Cause 4 S X X
Cause 5 S S I
Effect 1 P P A A A A
Effect 2 A P A A
Effect 3 A A A P P
Cause effect graph- Decision table

21. Cause effect graph- Example
Put a row in the decision table for each cause or effect:
in the example, there are five rows for causes and three for effects.
The columns of the decision table correspond to test cases.
Define the columns by examining each effect:
list each combination of causes that can lead to that effect.
We can determine the number of columns of the decision table
by examining the lines flowing into the effect nodes of the graph.

22. Cause effect graph- Example
Theoretically we could have generated 25=32 test cases.
Using cause effect graphing technique reduces that number to 5.

23. Cause effect graph Not practical for systems which:
include timing aspects
feedback from processes is used for some other processes.
BACK

24. Advantages of Black Box Testing
more effective on larger units of code than glass box testing
tester needs no knowledge of implementation, including specific programming languages
tester and programmer are independent of each other
tests are done from a user's point of view
will help to expose any ambiguities or inconsistencies in the specifications
test cases can be designed as soon as the specifications are complete
BACK

25. Disadvantages of Black Box Testing
only a small number of possible inputs can actually be tested, to test every possible input stream would take nearly forever
without clear and concise specifications, test cases are hard to design
there may be unnecessary repetition of test inputs if the tester is not informed of test cases the programmer has already tried
may leave many program paths untested
cannot be directed toward specific segments of code which may be very complex (and therefore more error prone)
most testing related research has been directed toward glass box testing
BACK

26. THANKS
BACK TO INDEX