00833333 times. Rounded up this gives us 0.01.
b. Look in the logs of the various servers to see which transactions failed. Create a load on the
browser, and see how many http requests arrive at the web server.
2. How do we help improve the reliability of the legacy application?
a. Create a test harness which will:
i. Annotate the code so you know what module is being called when
ii. Punish the code
iii Tell you:
A. Where the bottlenecks are
B. Which units were being used when the failure occurred.
3. How do we calculate the reliability of code outside our control?
Give it a 10??“9 probability3 of failure and ignore it unless you have any reason to doubt that
probability, in which case get the log data. If you are paying the bank a fee for the privilege of
using their system, they should be able to give you some reliability figures.
5.5.11 Web Test Coverage
We can use:
1. All URLs and transitions between them within the website
2. All transaction types ({ navigation | data | order creation and submission })
3. A set of scenarios which users are expected to take possibly (preferably) culled from user action logs
4. All servlets
5. All applets
6. All scripts
7. All applications (legacy, COTS, and new)
8. All components
There remains the problem of state. Apart from the possibility that browser variables may affect browser
behavior, the ostensibly stateless behavior of the browser (it just submits requests and displays whatever
it??™s sent) masks the reality that the website taken as a whole has a state which may affect the browser??™s
behavior in that (for example) having established that some item is in stock user A orders it.
Pages:
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229