Typically on web applications, but also in more conventional applications,
there is a number of ???paths??? a user may take to achieve a goal. These paths need to be
identified possibly in the form of a state transition diagram (typically from URL to URL in the
case of a web test) such that a minimum number of paths can be identified and traversed. This
is something of a hybrid of test coverage by structure and test coverage by scenario, and is
invaluable when testing web applications.
7. Test coverage by web script, web page, application, and component. Having identified the risk
level of the website (see section 5.2), you can then decide the level of coverage necessary to mitigate
that risk by selecting the test types from section 5.5.
Why does this matter? Because you want to minimize the risk of not having covered all the possibilities
of having a fatal bug in the released system. Test coverage cannot be complete, any more than requirements
The Big Questions You Need Answers To
27
specifications can be (see section 1.4 for a discussion of this). But you can make a good engineering
decision on what sort of test coverage you need based on the risk the system poses.
The coverage type(s) you choose (should) relate to the probability of finding bugs, and thus to the
degree to which you are minimizing the risk the product poses.
2.8.1 Code Level Test Coverage Estimation
At the code level, test coverage is intimately related to test type, and there is no independent criterion
against which the various types of test (and therefore the various types of coverage) can be measured.
Pages:
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133