Design process

This section describes how to design User Paths efficiently. It is a methodological guide, the points discussed here being detailed further on in the reference sections and in the tutorials. It is strongly advised to read this section before starting first tests, after having first been acquainted with NeoLoad, as documented in the Quick Start guide.

Key steps

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:

1. Record 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 can record an application in proxy or tunnel mode:

   • In proxy mode, 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.
   • The tunnel mode is useful when the application is too specific to be recorded in Proxy mode. The NeoLoad tunnel function captures the communication between the browser and the server. On one side, the Tunnel simulates the web server for the browser, and on the other side, it processes the requests and responses with the web server, allowing the Recorder to catch the transactions for the test scenario.

   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 information, see Create 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 Path can be played back correctly.

   For more information about recording, see Record a test scenario.
   

2. Validate the Virtual User 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 User Path and playing the requests on the server. The graphical interface displays all the requests and the server responses, their HTML rendering and the state of the variables within the scenario. This allows you to check the Virtual User 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 about Virtual User validation, see Check a Virtual User.
   

3. Correct the Virtual User behavior. 
   
   When a check of the Virtual User 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 User Path.

   The main steps involved in correcting a Virtual User behavior are:

   1. Identify the first request that returns an error: typically, this is a server response containing an HTTP error code or an unexpected HTML content.
   2. 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.
   3. Find the request whose response contains that parameter value: this value must be extracted by NeoLoad. The flags function is particularly useful for finding the request in question. For more information, see Flags.
   4. Decide on the appropriate method to handle the parameter: NeoLoad provides several tools for handling dynamic parameters, each adapted to a particular situation. For more information, see Choose a data extraction method.
   5. 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 the recorded value.
   6. Search for dynamic parameters: the error, since corrected, may have prevented the detection of other, subsequent dynamic parameters. You are advised to start a new dynamic parameter search. For more information, see Frameworks.
   7. Validate the Virtual User behavior: the aim is to check to make sure that the problem in question has been corrected.

   For more information about the procedure for handling dynamic parameters, see Handle an application dynamic parameters.
   

4. Change behavior using logical actions. 
   
   NeoLoad logical actions allow you to change a Virtual User behavior to adapt to the simulation 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.
   • Rendezvous synchronize selected Virtual Users at a single point before releasing them to complete their scenarios.

   When logical actions are introduced to modify a Virtual User behavior, it is recommended to check the Virtual User validity again and make any necessary corrections.

   For more information about logical actions, see Logical actions.
   

5. Use 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 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 behavior, it is recommended to check the Virtual User validity again and make any necessary corrections.
   

6. Validate key pages. 
   
   Under load, it is 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:

   1. In the Virtual User, click on the request whose response needs to be validated.
   2. Click the Validation button in the bottom right-hand corner.
   3. Add a validation on the content.
   4. 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).

   For more information about setting up request validations, see Validate a server response.
   

7. Define 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 Path, 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 selecting certain parameters in order to simulate realistic network conditions for a Virtual User or how the cache is managed.

   For more information, see Populations.

To learn more

For more information about load testing methodology, see Best practices.

Once the User Paths have been set up correctly, it is recommended to configure the Monitors that will allow you to monitor your server infrastructure during the load tests. For more information, see Monitors.

For more information about specific issues related to designing User Paths, analysis and other miscellaneous subjects, see Tutorials.

In the event of a problem, see Troubleshooting or F.A.Q..