Table of Contents
This guide describes how to design Virtual User profiles efficiently. It is a methodological guide, the points discussed here being detailed further on in the reference guide and in the tutorials. We strongly recommend that you read this guide before you start your first tests, after having first acquainted yourself with NeoLoad by reading the Quick Start Guide.
Load testing requires that particular attention be paid to a number of points if meaningful results are to be obtained. It is important to reproduce the many varied ways a web application can be used and to make sure that they are played back correctly. This involves the following key steps:
Recording the Virtual User. A Virtual User simulates the actions of a real user browsing
the web application. To create a Virtual User, click the
"Record" button in the NeoLoad toolbar. This will
launch an Internet browser to allow you to browse the application
and record the required user behavior.
NeoLoad acts as a proxy for the Internet browser and therefore records the HTTP requests exchanged with the server. The requests are grouped into pages that generally correspond to one click in the application.
While browsing, you may create containers representing the business transactions that are carried out. These containers group together the requests and pages relating to a same transaction, such as a login or the purchase of an item in an e-business application for example. You may create business transactions in a Virtual User after finishing the recording. For more details on this, see the section called “Creating Business Transactions”.
Once the recording is finished, NeoLoad searches for dynamic parameters, for example session id's, and automatically manages them so that the recorded user profile can be played back correctly.
For more information on recording, see the section called “Recording a Test Scenario”.
Validating the Virtual User's behavior. Simulating users is not just a matter of playing back the requests sent to the server. Even if most of the dynamic parameters are automatically handled by NeoLoad, thanks in particular to the dynamic parameter search, some still need special attention. By validating the Virtual User you ensure that NeoLoad plays back all these parameters correctly.
Validation involves playing out the Virtual User profile and playing the requests on the server. The graphical interface displays all the requests and the server's responses, their HTML rendering and the state of the variables within the scenario. This allows you to check the Virtual User's behavior and to make sure that it does not contain any errors.
Beware, NeoLoad does not detect all errors automatically. Even if HTTP error codes are detected by NeoLoad as a cause of a failed validation, functional errors (such as the incorrect playback of a business transaction) can escape detection. This is because applications often return pages in error that contain valid HTTP codes. Therefore, it is important to make sure that the content or HTML rendering does in fact correspond to the expected result. For example, an incorrectly played-back login often produces an HTML page stating that "the login or password is incorrect".
For more information on Virtual User validation see the section called “Checking a Virtual User”.
Correcting the Virtual User's behavior. When a check of the Virtual User's behavior reveals a problem, it is important to understand the cause of the problem, which is often linked to the incorrect playback of one or more parameters using incorrect values. To be able to correct the problem in an efficient manner, the parameters involved must be checked one by one, in the order they are used in the Virtual User profile.
The main steps involved in correcting a Virtual User's behavior are:
Identify the first request that returns an error: typically, this is a server response containing an HTTP error code or an unexpected HTML content.
Identify the parameter that requires attention: this can be any parameter in the pinpointed request whose value may change at each playback, for example a session ID.
Find the request whose response contains that parameter's value: this value must be extracted by NeoLoad. The Flags function is particularly useful for finding the request in question.
Decide on the appropriate method to handle the parameter: NeoLoad provides several tools for handling dynamic parameters, each adapted to a particular situation. To choose the most appropriate for the case in question, see the section called “Choosing a Data Extraction Method”.
Apply the selected method: depending on the method, the requests that appear after the request on which the extractor has been placed must be modified to use the extracted variable instead of inserting the recorded value.
Search for dynamic parameters: the error, since corrected, may have prevented the detection of other, subsequent dynamic parameters. We recommend therefore that you start a new dynamic parameter search (see the section called “Frameworks”).
Validate the Virtual User's behavior: the aim is to check to make sure that the problem in question as been corrected.
This procedure for handling dynamic parameters is explained in detail in the "Handling an Application's Dynamic Parameters" tutorial.
Changing behavior using logical actions. NeoLoad's logical actions allow you to change a Virtual User's behavior to adapt to the simulation's requirements:
Certain actions cause only a slight change to the behavior, for example inserting a pause, grouping several pages as a business transaction, modifying a variable or stopping a Virtual User.
Loops can be used to repeat typical user routines, for example a particular business transaction.
Conditional actions can be inserted to simulate certain actions that are conditional upon feedback from a server or an error occurrence.
JavaScript actions can be used to carry out simple functions in order to update variables or carry out specific tasks.
Rendez-Vous synchronize selected Virtual Users at a single point before releasing them to complete their scenarios.
Details of the various logical actions available can be found in the section called “Logical Actions”.
Using different login accounts and values. Variables may be used to dynamically change key values such as user logins or certain form parameters (for example, a productID in an e-business application).This is useful mainly for getting around the server's use of the cache, since:
playing the same requests using the same values results in abnormally high performance, due to the various caches (pre-loading into memory, connection pools, system optimization...)
completely disabling the caches (where possible) does not give a realistic view of performance either.
As before, when variables are used to modify a Virtual User's behavior, we recommend you check the Virtual User's validity again and make any necessary corrections.
Validating key pages. Under load, it's important to check that the server response is valid to make sure the scenario is working as predicted and the high load isn't resulting in errors on the application.
NeoLoad automatically detects the requests in error by using the returned HTTP code in particular. For example, a request that returns a '500 Internal Error' code will be flagged by NeoLoad as an error. However, many Web applications do not return an appropriate HTTP error code as part of their error management and NeoLoad is unable to detect the fault automatically.
These cases have to be managed individually by checking the validity of the content returned by the server at key points in the application. For example, you may verify the presence of an expected text string such as "The operation was successfully completed", or make sure the response does not contain "Error".
To define a content validation:
In the Virtual User, click on the request whose response needs to be validated.
Click the Validation... button in the
bottom right-hand corner.
Add a validation on the content.
Select the validation mode: search for the presence or absence of a simple text string, or use a regular expression.
At the end of the test, select the requests flagged in error or whose validation failed in the Errors pane, then analyze the content of the corresponding server response in order to find the cause of the problem.
Note that content validation uses up resources on the Load Generator (CPU, memory..), therefore it can be wiser to concentrate on testing key pages only (for example pages giving access to databases or those that are more likely to fail).
Setting up request validations is explained in more detail in the "Validating a Server Response" tutorial.
Defining several types of Virtual User. As not all users use a web application in the same way, it is important to define a Virtual User for each user profile, for example "just browsing", "browsing and editing" and "administrator". The aim is to cover the business transactions that are most common and the most representative for the application being tested.
These Virtual User profiles must then be grouped into Populations. Populations are used to maintain a ratio between users during the variation in load. For example, you may decide to maintain a ratio of 90% standard users and 10% administrators whatever the total simulated load.
Populations also allow you to select certain parameters such as maximum bandwidth for a Virtual User or how the cache is managed.
For more information, see the section called “Populations” in the Reference Guide.