of decision/condition/
outcome combinations
Mutant analysis Finds bugs similar to the
mutation
Depends on mutant strategy
approximating reality
See section 13.6
Path analysis Computational, path, and
missing path bugs
Wrong paths At least one per path
Random data selection The probability of failure given
some random input
Any case not tested for As required
Statement coverage Incorrect processing Some decision, or decision/
condition outcomes, e.g.,
incorrect logic flow
No. of paths
Symbolic evaluation Equivalence classes of inputs Feasible paths excluded by
manual intervention (e.g., in
path pruning)
As the symbols evaluated
20
Manage Software Testing
4. At various times (as soon as possible) when we test the human??“computer interfaces to see if the
system is usable.
Additionally we exercise some form of validation on a specification which needs some form of validation
by creating an executable model. Other informal tests may occur at any time throughout software projects,
but are outside the scope of this book.
This is called
getting stitched-up
. Avoid it early by sending all relevant parties a memo identifying the
entry criteria you will adopt for deciding when you are ready to start system testing (see section 8.5.9).
Stand to one side and admire the smoke, flames, and bangs with equanimity. Remember that this way
you will focus much-needed attention on the exit criteria.
2.4 When Do We Stop Testing?
We stop testing when we realize that the system is so buggy that testing it anymore is pointless, or when
all the following are true:
1.
Pages:
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119