Black Box Testing
Black Box Testing
Black Box Testing
Testing Objective
• Primary Objective
– Testing is a process of executing a program with the intent of finding
an error.
– A good test case is one that has a high probability of finding an as-
yet undiscovered error.
– A successful test is one that uncovers an as-yet-undiscovered error
• Objective is to design tests that systematically uncover different classes
of errors and to do so with a minimum amount of time and effort.
• Testing demonstrates that software functions appear to be working
according to specification, that behavioral and performance
requirements appear to have been met.
• Data collected as testing is conducted provide a good indication of
software reliability and some indication of software quality as a whole.
• But testing cannot show the absence of errors and defects, it can show
only that software errors and defects are present.
Testing Principles
• All tests should be traceable to customer
requirements
• Tests should be planned long before testing
begins
• The *Pareto principle applies to software testing.
• Testing should begin “in the small” and progress
toward testing “in the large.”
• Exhaustive testing is not possible
• To be most effective, testing should be
conducted by an independent third party
*for many events, roughly 80% of the effects come from 20% of the causes
Testability
System
• Equivalence
partitioning is the
process of
methodically System
reducing the huge (or
infinite) set of
possible test cases
into a small, but
equally effective, set
of test cases.
Outputs
To define equivalence classes follow
the guideline
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.
Formation of EC
– One valid EC and two invalid EC
– Input is 0<n<max
– Valid EC is (0-max)
– Invalid EC1 : all n < 0
– Invalid EC2 : all n > max
Boundary Value Analysis (BVA)
• 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.
• In other word, Rather than focusing solely on input
conditions, BVA derives test cases from the output
domain as well.
Guidelines for BVA
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.
4. If internal program data structures have prescribed
boundaries be certain to design a test case to exercise the
data structure at its boundary
Boundary Value Analysis