| 
| | 
|
User Path Design process
- Record the Virtual User
To create a Virtual User, click the Record button in the NeoLoad toolbar. This launches an Internet browser for browsing the application and recording the required user behavior.
NeoLoad can record an application in proxy or tunnel mode:
- 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.
- Tunnel mode
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, processes requests and responses with the web server, allowing the recorder to catch transactions for the test scenario.
- proxy mode
- While browsing, we can create containers representing business transactions. 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.
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.
- 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".
- 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.
Steps involved in correcting a Virtual User behavior
- 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 value
This value must be extracted by NeoLoad. The flags function is 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.
- 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.
- 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.
- Validate the Virtual User behavior
The aim is to check to make sure that the problem in question has been corrected.
- 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.
- 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.
- 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, we 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).
For more information about setting up request validations,
- 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, we 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.
See Populations.