15).
??“ Review the test inputs for these and all the other tests.
??“ Assess the structural coverage of the unit tests.
??? Estimate the remaining number of bugs to be found and the time to be spent testing.
Apply the following controls:
??? Relate each unit test to a unit specification (which can simply be the unit header).
??? Test the unit tests by bug seeding (see section 18.10.5).
??? Peer-review each unit before unit-testing.
??? Relate unit test severity to code complexity (see section 18.8.4) and expected unit use.
??? Relate unit test execution time to the expected use of the unit.
??? Review unit tests. Re-review those which found no bugs if bugs are found later during integration
and system testing time.
??? Review the unit test environment (tools, etc.).
??? Modify any unit test which has found a bug (otherwise there will be a tendency for the tests to
train the code to pass them).
??? Get the code size and details to help in determining bug numbers (see section 18.10).
When a unit passes a unit test, put the code under configuration control. Access to and control of the
unit-tested code should be with the project librarian.
Unit testing is not a clearly-delimited phase and so apply these controls whenever a unit is ready for
submission (as soon as a program declares some unit to be ready for a build). See section 4.4.6 for the
Microsoft approach and Chapter 14 for more details generally.
6.5 Software/Hardware Integration
Sometimes new software needs to be integrated with new hardware.
Pages:
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241