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.
In This Chapter
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:
NeoLoad can record an application in proxy or tunnel mode:
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.
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.
The main steps involved in correcting a Virtual User behavior are:
For more information about the procedure for handling dynamic parameters, see Handle an application dynamic parameters.
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.
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.
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:
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.
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.
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..