When you start load testing a web site (especially if this is the first load test in your life) you may see a lot of errors in the report. Possibly you will even have to stop the test before it completes, because at some point in time it becomes clear that something goes wrong. If the problem is not so obvious, it is still recommended to check the report for the errors related to each virtual user profile (i.e. to each different type of virtual users) before looking at any performance data.
Usually you do not create a high load in the very first test of a web site, so if you see any errors in the report, most probably they appear because of the test design problems. In other words, the emulation of the real user activity is performed incorrectly. Your web application may produce errors and even refuse connections because it receives incorrect data from your load testing tool. Why this may happen?
There is no exact algorithm on how to find all places where the parameterization is required. WAPT can do some automatic parameterization, but only for standard cases. The remaining work depends on your web site, so you have to do it manually. At the same time WAPT provides a convenient interface for this task. So, the general approach is as follows.
After recording a profile click the “Verify test” button to verify it. The profile will be executed as is, without any modifications (except for the automatic parameterization made by WAPT). When the verification is finished you can check the “Logs” folder for errors and find the first request that produced an error. The goal is to find dynamic session-specific values inside that request. You can do this by comparing different sessions. Usually such session-specific values are contained inside the request parameters, but they can also be passed inside the main part of the URL. When you find such value you also need to find a place (the body of one of the previous responses) from which you can extract it. You can use the “Edit | Find and Replace…” feature for that.
In WAPT you can select any request and switch to the “Response processing” tab in the right view. Here you can see the recorded request and server response to it. You can add a variable by clicking the “Add” button near the list of variables. The goal is to specify how to extract all session-specific values from the server response and assign them to variables.
These variables can be inserted to the parameters and URLs of subsequent requests instead of initially recorded static values. That is how the parameterization works.
After you make all necessary modifications to the profile you can enable the full logging (on the “Log and Report Settings” page in WAPT) to check that all user names and passwords are passed correctly. By default logging is enabled only for verification, but if you run test with just few users, you can switch to full logging without any significant performance overhead.
For example, it may be that each user of your system has a special ID which is passed in some parameter of each request. If you use a different user name, you also need to change that ID. As usual the right value can be extracted from some response and assigned to a variable.
Each of the remaining problems is less common, but it is still worth mentioning about them.
Note also that you may see HTTP responses with code 401 even after you enter the credentials. This is not an error. If a web site requires authentication, it always responds with that code expecting to receive the authentication data in return. When everything is done correctly, it finally ends with the “200 Ok” message.
If you start recording from the middle of a user session, your load testing tool will not be able to reproduce that session correctly. Even if you click a link on a page already open in your browser instead of manually entering the address, this can produce incorrect recording.
Finally, if you do not delete browser cache, all requests to cached elements will be skipped on recording. This is the least important problem, because any session-specific requests will be sent in any case, but to create a realistic load you will probably want to load page elements as well.
What I am trying to say is that if you see some error in the verification log, first of all you should check if that error was present in the initially recorded session. This can be easily done with help of “Compare with recorded” feature in WAPT.
In some cases AJAX requests complete with 404 or 5XX codes, but this is ignored by the client part of your web application, so you do not see any problems in the browser window. These requests may be obsolete and unnecessary for the correct work in general. Still it is preferable to remove them, but this is rather a small functional bug.
If you need to load test a web site with such “normal” errors, you can either delete those requests or convert them to page elements, so that they would not influence the session execution.
One final very important note. If you see errors in the report, you should definitely research the problem as described above. However even if you do not see any red lines in the log, this does not mean that everything works correctly. Your web site can produce errors in a “user friendly” manner or just redirect to a different page if it cannot provide valid content for a request containing incorrect parameters. This means that you need to read the actual response to see if it is correct. Again, you can use the “Compare with recorded” function and check all responses step by step.