In the test plan you need to establish the types of test and the coverage to be obtained therefrom. Criteria
range from the banal (but essential) all-statements-executed to the near-impossible all-paths-executed.
Before determining the amount of code level test coverage, it is useful to decide:
1. Whether any parts of the system have a high criticality (note that this excludes safety-critical parts,
all of which must have the highest-possible level).
2. Which features and code areas are likely to be the most-highly used.
3. Which units are the most complex.
4. Which units have been changed the most often since being submitted to configuration management.
5. Which units have generated the most bugs so far (this will clearly change; if the test plan is being
written at the high-level design stage, then, presumably, no units will have been coded so far;
however, as the test plan is revised later in the project cycle, experience will suggest that some
units are bug-prone).
6. What sort of inputs the system should withstand.
7. What the history of similar systems has suggested (this can be derived from bug reports; if they
can be related either to features or particular parts of the code, it will be possible to build a code
profile of the more problematic and use this as a guide to the type and quantity of tests to be run).
Having defined these issues it will be easier to relate the test types as shown in section 2.
Pages:
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134