Skip to content

Virtual User Validation

The virtual user validation tool helps you ensure that your Virtual User runs fine before starting a test. It is available in the Main tab of every virtual user or using the Run validation button always visible on the upper right:

Virtual User Validation

You can select the region where the Virtual User will run (You can add your own On-Premise Agents in the Private Hosts page). In order to then run a Virtual User Validation simple Click on the Validate button:

validation-running

The Validate button becomes a Stop button and a progress bar is displayed. Wait a few seconds, while OctoPerf runs a single instance of the Virtual User and records the requests sent, and the responses received. You can configure your validate to run several iterations from the Advanced Configuration section.

While the validate is running, clic Open Logs to opens the Logs panel.

Note

In the interest of time, Think times are not replayed during a Virtual User validation.

Configuration

In this section, select how many iterations to run and browser settings:

Virtual User Debug Browser

Info

An iteration is a complete run of the virtual user, up until its last element is executed. By running several iterations you can check if datasets and other variables are properly updated.

Validation analysis

Color code

Validation Icons

Once the execution starts, the Virtual User Validation displays colored dots on the left of each VU tree node that was executed:

  • green-dot The response is OK,
  • red-dot The response is KO,
  • orange-dot At least one occurrence or children is KO.

Info

The absence of any dot indicates that this element was either not executed or that it doesn't have a result in itself (for example if actions do not have results).

Debug panel

You can also use the debug panel to analyze response codes, or compare your results with the recording:

debug-compare-mode

Error matrix

The following table indicates the situations considered as KO/Red during a validation. Each line represents the validate response for a category of response time. For instance 2XX for 200 and similar response codes. Unknown response codes refers to codes that are outside the list of standard codes.

Each column represents the recorded response code in a similar fashion.

Validation code No recorded Recorded 2XX Recorded 3XX Recorded 4XX Recorded 5XX Recorded unknown
2XX green-dot green-dot red-dot red-dot red-dot red-dot
3XX green-dot red-dot green-dot red-dot red-dot red-dot
4XX red-dot red-dot red-dot red-dot red-dot red-dot
5XX red-dot red-dot red-dot red-dot red-dot red-dot
Unknown red-dot red-dot red-dot red-dot red-dot red-dot

If you want more details on how to analyze the errors, please check the error table report item page.

Warning

During runtime, the responses will be evaluated based only on their response code, as if there was no recorded response. Please refer to the first column of the table in that case.

Logs

Using the log panel you can look for issues with your validation that are not visible in the tree. For instance if a JSR Script failed the error message will be in the JMeter log:

log

Sanity check

The sanity check is a prerequisite to any Virtual User validation. In most situation it will not raise any issue and you won't even see it. It scans your virtual user to check if anything can break its execution (i.e. missing files) or can make your load testing results hard to analyze (i.e. empty or unnamed containers).

sanity-invalid

If invalid, it will prevent you from running validations and even tests.

Sanity Check

It displays a table that lists all errors with:

  • The error level: INFO, WARNING or ERROR,
  • A short message to help you identify the issue,
  • An Inspect button to be redirected to the element causing the issue.

Once you fixed all the issues, you might need to hit "Refresh" and then "Next" to go back to the validation screen.

ERROR

If any error sanity-red is detected, the debugging of the virtual user is canceled. You need to fix it before running the validation once again.

Message Description
A file is missing for CSV variable In JMeter, the behavior for a missing file would be to stop the test and log a message. Instead we use this opportunity to warn about the missing file.
CSVVariable has a conflicting column names CSV variables using the same column names will be impossible to differentiate at runtime. Instead we recommend to use a prefix on column names.
JSR223Action is empty An empty JSR223 action can generate a lot of logging for no purpose. It is better to remove unnecessary JSR223 actions.
No Server Found If you remove a server without removing the corresponding request, then it is impossible for us to launch the test. Note that this can only happen if you play with the API, otherwise we would remove all requests when removing the server.
Cyclic Dependency Detected! When using fragments, it is possible to configure a cyclic reference by using a fragment within a fragment. This behavior would prevent us from parsing the virtual user before runtime which is why it is forbidden.

WARNING

Warning sanity-orange message are meant to get your attention on potential issues.

Message Description
Clear Cookies before recording or manually remove Cookie header If you haven't properly remove cookies before recording, you may end up reusing invalid session IDs. This can lead to unrealistic tests, so we recommend to remove the cookie header on your first request or make sure to clean cookies before recording.
Empty file for CSVVariable If a CSV variable has an empty file, then there will be no values to distribute during the test. This can happen when the file you provided cannot be parsed, for instance if it is not a UTF-8 file.
End Of Value Policy is 'Stop VU' In this situation, the test will stop when out of values. Make sure that's the expected behavior and that the files contains enough values.
file is missing for POST request In this case a multipart POST request needs a file, but we cannot find it. Make sure the file name is correct, the path to the file (/resources) doesn't need to be specified.

INFO

Information sanity-blue messages are pointing out problems that can become inconvenient later but that can usually be disregarded.

Message Description
Host header and server host are differing Some web servers will refuse your request if Host header and URL have different values. If required, use the search and replace to change the Host header of all requests.
Using a JMeter generic action You have imported a generic action from JMeter, that's not an issue at all but you may have to check if its configuration is ok in OctoPerf. Path to files is /resources by default and any JAR file provided will be in /lib/ext.
XXX sec thinktime is high You have configured a very high think time or imported an HAR with a large pause somewhere. This may result in a long period of inactivity during your tests, which is why we prefer to warn you about it.
xxxxx should have a name Unnamed elements will be displayed as Unnamed in the report. If you have several of them that could make the report difficult to understand. It is better to provide a proper name to every element.
xxxxx is empty Empty nodes like controllers or other logic actions will never be executed, it is better to remove them.
HTTP Action has empty query parameter Empty name and value for a parameter means you either misclicked and created one by mistake or you imported an HAR from a source that tends to add these unnecessary parameters. Either way, some web servers will fail your request in this situation so we prefer to warn you.