Designing a test for a web site with essentially dynamic content may be a rather complex and time consuming task. It is similar to programming in some respect. Even though there are good testing tools that let you automate the process and make it more transparent, still it is hardly possible to parameterize a profile in one step. In practice it is rather an iterative process when you parameterize the requests one by one. In this process you need to see what you get on each step. For this purpose you don’t need to launch the partially prepared test. Instead, you can verify it.
Verification is done by running the test with only one virtual user to simulate only one user session. Of course, this will not create any significant load on the web site. So, we will not verify the specified load, but we can check if the profile works correctly or not. If everything is ok (which means that we completed the parameterization), we can proceed to the full test run.
Let’s see how this is done in practice using a small and easy to demonstrate example. I will record a simple profile using the following web forum: http://www.loadtestingtool.com/forum
Our virtual user will simply click a link on the main forum page to open a sub-forum and then click another link to open a topic. As usual, I will use the WAPT tool for this purpose. I click the “Rec” button on the toolbar, enter the above URL to the address bar, and make couple clicks on the site inside the embedded browser window.
When this is done, I click the “Stop Rec” button to stop recording, and then click “Verify test” to perform the verification. It takes some time to complete the user session. After that a short report is shown. It contains the response codes for all pages requested during the user session.
Even though this report provides some useful information, it is not sufficient for the verification purposes. What we really need is the complete information related to each request and response. It can be found in logs.
I do not mean reading huge text files. WAPT provides a very convenient way to get all the logged information in a structured form. I expand the “Logs” folder in the left view and select the only user session available here after the test verification. This is what I see in the right view.
All the requests of the verification session are listed here. I can select any of them and see the details in the lower part of the window:
Each tab contains the content of the corresponding part of the request and response. So, for each request we can see what exactly was sent to the server and received in reply.
For example, we see that page_2 request contains the showforum parameter, which obviously specifies the number of sub-forum that I opened from the start page. Similarly, page_6 request contains the showtopic parameter that specifies the number of topic we opened in the sub-forum. The values of these parameters (11 and 2148) are also shown here.
Now let’s make couple experiments. First, I will change the URL of the last request to an incorrect one and verify the test again. This is what I see in the log now:
WAPT marked the corresponding response with red color because server returned an error in reply. The “HTTP Response” column in the log now contains the “404 Not Found” line for this request. The 404 status code indicates an error.
In my second experiment I will try to change the topic number in the last request and verify the test again. I intentionally use a wrong number for which the topic does not exist, so we may expect the server to return an error again. However, surprisingly the log shows that the verification completed successfully (note that the topic number in the request is different now):
In fact, this is a very common situation and it is very important to know about that. If server receives incorrect data in request, it can either reply with an HTTP error code, or return an error in the human readable form. Let’s take a look at the page content of the page_6 response. It is available on the “Browser view” tab below.
Even though the status code for this response is 200, meaning the successful request completion, its body contains an error message. So, it is important to review all server responses to all requests in order to make sure that the test is correct and can be launched at full capacity.
Why is this so important? Believe it or not, but many people do not care if user sessions in their load tests are executed correctly or not. It seems that they think that in “Load Testing” the main word is “Load”. They record a user session, specify the number of virtual users and just click the “Run” button. In WAPT this can be done within a minute and you will even get a test report with all the usual data, including response times, bandwidth usages, etc.
Web sites have to reply to all requests, even to incorrect ones. However loading a web site with such requests is not useful at all, because this does not emulate the real load received by the server in production. Note that it takes much less system and database resources to send an error message in reply to an incorrect request, than to serve a good one.