See Chapters 16 and 17 for more on this.
The sorts of bugs which
can
occur suggest the sorts of tests to be written to find them. By definition
no tests can be written for the type ???c??? bug, but because they exist, every effort should be made
to imagine them. Writing good tests means imagining the unimaginable.
??? Testing cannot prove the absence of bugs, only their presence.
??? If a program produces a correct output from many test inputs then it may produce correct output
from any input. Sometimes it doesn??™t. Even flawless software can generate drivel if the inputs are
corrupt enough.
??? A test can find a bug only in terms of some baseline; some specification which determines what
a bug is. This baseline can exist on paper or in someone??™s head (???It shouldn??™t have done
that!
???),
but to be useful it must be objective and evident. There are (almost) no oracles to determine the
correctness of every output in every circumstance. A good tester may have an instinctive knowledge
of what is ???incorrect??? behavior ??” he will then spend the time required to show why it is ???incorrect.???
??? Testing costs at least half of all the other project activities. Even if this hasn??™t been planned it??™s
what will happen anyway. Therefore it??™s better to plan. This requires that we set priorities and
make choices.
??? Testing cannot be complete. Any non-trivial system will use too many combinations of inputs to
allow for every one to be tested.
Pages:
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157