For each user scenario, a test recorder is used to capture the user session and generate a test. The first step in
debugging the user session is to play this session back as it was recorded to make sure the server accepts the test as
generated. In the event that this does not provide the intended result, it can be caused by four main reasons: an
unsupported authentication mechanism is used by the server, the data correlation required by the server application is
not automatically handled, a data dependency exists in the user scenario that requires data variation, or some Java
applet operations must be programmed to permit the session to run properly. An experienced user of the performance
testing tool should be able to handle any of these four cases and tell them apart.
There are four further steps in debugging your test:
-
Add input data variation, verification points, and any flow of control constructs needed for your test when it is
run in multi-user mode. Run the test straight through with these changes and make sure it executes properly and all
verification points pass.
-
Create a test schedule and run the same test in a loop of three iterations. Make sure that no test start/end
boundary conditions cause failures. Contents of the cookie cache are often a source of trouble here.
-
Create a test schedule and run 3-5 virtual users running the same test in a loop of three iterations. This permits
data collisions, table locks, and other simultaneous user errors to be uncovered. Problems here are typically
solved by fixing single-threaded application modules and adding data variation where it is required.
-
Create a test schedule and run 20-30% of expected system capacity. With this test, server time-outs and basic
load-triggered timing dependencies can be uncovered. In general, these problems are due to application design and
tuning deficiencies. The important thing is to uncover these problems early and get application development help in
solving them before serious load testing begins.
|