Testing Flashcards
(23 cards)
is a critical process within any
software development and maintenance life
cycle model
Testing
Testing implementations is often referred to as
software testing, or simply testing.
Only _____ can guarantee full
coverage.
exhaustive testing
is impractical since it may
take years to complete even for testing small size
programs.
Exhaustive testing
difficulty in software testing
the inability
to quantify the errors existing in software, and
hence predict how many errors are left
undiscovered.
- Test the software by executing it and applying
test inputs - Observe the output and make a judgment to
take a verdict
Dynamic testing
- Check code without executing it
- Automatic static testing: Code as an input to a
static analysis tool - Non-automatic static testing: review,
walkthrough, inspection
Static testing
is a set of organized test cases
test suite
includes a test suite
Test plan
are obtained using known testing
techniques and strategies
Test cases
module or unit testing
White-box:
module testing and system testing
Black-box:
a bit of both (partial knowledge of
internal structure)
Grey-box:
Source Code + Functional Specifications
White box based test generation
Functional Specifications only
Black box based test generation
Design Document + Functional Specifications
Grey box based test generation
Black-box unit/module testing techniques
- Boundary value analysis
- Equivalence class testing
- Decision table / decision tree based testing
- State based testing
- Robustness testing
test inputs
obtained from the boundaries
Serious errors hide at the boundaries.
For example, simple boundary values for an
input of integer data type would include
-INT_MAX, -INT_MAX + 1, -1, 0, +1, INT_MAX -1 and
INT_MAX.
Boundary Value Analysis (BVA):
- Partitioning input domain into disjoint
subsets or partitions - Partition includes related values
- Consider one test input from each partition
- Example: “all positive numbers”
Equivalence class testing
- Decision table: each column denoting a rule
becomes the basis of a test case - Conditions produce inputs
- Actions produce expected outputs
Decision table-based testing
- Each distinct path from the root node to a leaf
node is the basis of a test case - If along the path, a variable input value does
not exist, the test input for that variable can be
assigned any valid value.
Decision tree-based testing
An implemented finite state machine (FSM)
conforms to its specification, if the observed
output sequence matches the expected output
according to the specification
State-based testing