Check a Virtual User validity

A Virtual User simulates a real user accessing a series of web pages. When you have created and defined a Virtual User, an essential step is to check this Virtual User. Making sure the Virtual User is valid before using it in scenario will guarantee that Virtual Users work at least on a per user basis. This is all the more true when the pages used by the Virtual User contain dynamic information such as parameters or form values. The following screen shot depicts a situation where a Virtual User has been defined with three pages. This has been achieved selecting NeoLoad Design mode and working in the Virtual Users tab.

In the example, the Virtual User called SimpleUser navigates through three pages which log the user on to the application. The first page /loadtest/welcome is the welcome page of the application, the /loadtest/signOn page is where the user will enter his or her identifier and password, finally the /loadtest/signedOn page is the page following the sign on and confirming that the user has successfully signed on. The example is simple and rather unrealistic—a Virtual User would obviously simulate a more complex behavior—but it will be kept simple to illustrate error situations.

Checking a Virtual User is achieved by selecting the Check button. NeoLoad displays the Check Virtual User dialog box. Launching the check, in other words executing the Virtual User, is achieved by selecting the Start checking button.

The following information is provided by the Check Virtual User dialog box:

• HTML pages and HTTP requests:

  NeoLoad plays the pages contained in the Virtual User and displays a sequence of lines, one for each HTML page and one for each HTTP request defined for that HTML page. For instance the HTML page /loadtest/signedOn is defined by a unique HTTP request to /loadtest/signon.shtml using the GET method. The Check Virtual User dialog box displays two lines, one for the HTML page and, immediately after it, another for the request. Had the page contained several requests, the Check Virtual User dialog box would have displayed a line for each request.

• Errors, response codes and assertion evaluations:

  Errors, response codes and assertion evaluations are only meaningful for HTTP requests, this is why only those lines corresponding to requests display information relative to those elements. When a request has a response code associated to an error or has a failed assertion, NeoLoad tags the associated line with the red icon rather than the check mark. If any request has failed, the dialog box displays a header with something like following: The Virtual User SimpleUser contains 2 error(s).

  An assertion validates a server response during a test by defining or asserting a condition that must be met. You will be shown in this section how essential assertions can prove to be.

  In the example, the HTTP request to /loadtest/error has failed. It has a 500 response code but no failed assertions. By selecting that line, you can display detailed information on the failed request.

• HTTP request details:

  When a failed request (or a successful request for that matter) is selected, the dialog box displays the following elements:

  • HTML Page:

    The HTML page to which the request belongs.

    This is a link; NeoLoad will jump to the specified page in the User Path if you follow the link.

  • HTTP request:

    The HTTP request that has failed.

    Again, this is a link and NeoLoad will jump to the specified request in the User Path if you follow the link. This feature is particularly useful when you want to check how the request is defined, especially with regard to dynamic values such as dynamic URLs or dynamic form parameters. Navigating back from the User Paths to the request in the Check User Path dialog box is easily achieved by right clicking on the request in the User Paths and selecting the Select in "Check User Path" Dialog item.

    This makes it easy to navigate back and forth between the definition of the recorded page and the error details.

  • Response details:

    Details include the time at which the response was received, the response code, the response duration and the number of bytes of the response.

    The response code is equally a hyper link, NeoLoad will bring up a pop up displaying the description of that particular response code.

    • HTTP Error Response Codes: HTTP response codes are standard codes, in the range of 400 and 500 they indicate error conditions and are automatically detected by NeoLoad. HTTP response codes give you a good indication of the type of error involved.
    • NeoLoad Error Codes: NeoLoad status codes are always prefixed by NL and are generated by NeoLoad because some client mechanism has prevented NeoLoad from actually sending a request. Errors due to connection failures or networking issues are typical examples of such situations.
    • Request, response and assertion contents: The Details group box lets you select which contents you want the dialog box to display.

    This feature is often essential when trying to understand the cause of an error. Viewing the request will, for instance, make it clear what is wrong (a dynamic parameter, an erroneous URL, ...). The response will contain the detailed reason of the error in the case of a server error, the description associated to the code in the case of a NeoLoad error.

    In the example, the returned response code is 500, an internal server error, the contents of the response clearly describes the cause of the error. It is due in this case to a compilation error on the requested JSP page.

    You can search for some specific text in the pane containing the error description or the actual request or response by right clicking in the pane and selecting the Search item.

In the example, when the login process fails, the application returns a page indicating that the operation has failed. This implies that no error, whether it be a server error or a NeoLoad error, has been detected. And yet, this situation is surely an error situation. Had your Virtual User contained additional pages depending on the fact that the login had succeeded, an error would most probably occur later on in one of those pages. It is therefore essential to use assertions to detect such situations. Assertions will help you identifying an error situation early in the scenario and avoid analyzing incomprehensible errors due to earlier misbehaviors.

For more information about using assertions, see Validate a server response<in_pdf_tuto>.

Home