| 
|
| 
|
Check a User Path
Checking a User Path validity is highly recommended prior to running a complete test, as the pages used may require fine tuning. This is almost always the case when the server generates links containing dynamic parameters such as /results?searchID=345365—here the corresponding request either should be converted into a link extractor or a variable extractor should be used.
The Check User Path dialog is accessible:
- in the Controller with the Run > Start Checking command, or
- in the Controller toolbar with a click on the Check a Virtual User button, or
- after selecting a Virtual User in the Virtual Users tab, with a click on the Check button, or
- with a right-click on a Virtual User in the Virtual Users tab and the Check this Virtual User contextual command.
In the Check User Path dialog, a click on the Start checking button launches a mock execution of the Virtual User. When inconsistencies in the Virtual User design are detected, the Execution Sanity Check dialog may pop up, which makes it possible to correct them preventively.
The Execution Sanity Check dialog lists and depicts the errors and warnings detected:
- Description describes the nature and the cause of the notice.
- Resolution gives a link, when available, to access the defective scenario component.
The Refresh button must be clicked to update the list whenever changes are brought to the test design. The Execution Sanity Check dialog is non-modal, making it possible to check and fix issues at the same time.
When checking a Virtual User, the following issues may be raised by the Execution Sanity Check dialog.
|
Message |
|
|
Description |
The Virtual User Y is invalid because it does not include any action. |
|
Resolution |
The test must use another Virtual User, as described in Load variation policy, or the empty Virtual User Y must be modified, as described in Customize a Virtual User. |
Empty Virtual User Y|
Message |
|
|
Description |
In the project, variable X is configured to call a file that is not available. |
|
Resolution |
Variable X must be modified, as described in Create a variable. |
File not found in variable X|
Message |
|
|
Description |
In the project, binary POST request X is configured to call a file that is not available. |
|
Resolution |
Request X must be modified, as described in POST requests with binary content. |
File not found in binary POST request X|
Message |
|
|
Description |
In the project, a Logical action is an X JavaScript file that fails to execute. |
|
Resolution |
X JavaScript file must be modified, as described in JavaScript. |
Modifications in Javascript X have not been applied|
Message |
|
|
Description |
A WebSocket action X requires a WebSocket channel which is missing to establish the connection to the WebSocket server. |
|
Resolution |
A WebSocket channel must be created as described in Create a WebSocket channel. |
|
Message |
|
|
Description |
An X JavaScript library file required by a Virtual User script is missing in NeoLoad. |
|
Resolution |
The JavaScript library file must be created or specified as described in JavaScript libraries. |
For more information about the Execution Sanity Check dialog, see Check the test sanity before execution.
In the Check User Path dialog, or from the Execution Sanity Check dialog when displayed, a click on the Start checking button launches the Virtual User consistency check.
The consistency progress is represented with a green progress bar.
When the Check User Path dialog raises errors, it is necessary to correct them in the User Path. During the checking process, NeoLoad runs a Virtual User and displays details of all the actions played, be they logical actions (pages, Container ...) or requests.
In the Check User Path dialog, the Flag requests button and contextual command makes it possible to set flags on a Virtual User requests. See Flag requests.
In the Check User Path dialog, the Advanced button gives access to the Virtual User parameters. See Advanced parameters.