3. Test coverage by instrumentation. Use a code instrumentation tool to instrument a build, and
then test that build using the system tests already prepared. The tool output should be able to
indicate how much coverage in code terms the system had. Note that this need not occur for every
build once sufficient code coverage is assured. See section 12.9
for more on this.
4. Test coverage by structure. When unit testing you need to be sure you have exercised some
minimum part of the code. Testing should include Statement coverage, Decision (branch) coverage,
Condition coverage, All-DU-paths coverage, and Linear Code Sequence and Jump (LCSAJ)
(see Chapter 12).
Beware of anyone claiming ???code coverage??? when all they are doing is running
Ncover when building: they may have filtered out unexercised lines and will only have exercised
at best all the statements in the unit. Decision, branch, DU-paths, etc., will probably
not
have
been covered.
5. Test coverage by scenario. Users have a number of goals which they want to achieve. They achieve
them using a number of (parts of) features. In doing so they set up subtle feature interactions,
which no other coverage approach will mimic. Use user action logs (if necessary) to validate your
proposed scenarios, and user profiles to identify scenario sets. Naturally use cases form the baseline
of such an approach. See section A.1 in Appendix A.
6. Test coverage by transition.
Pages:
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132