Analyze errors in the Errors panel
This tutorial describes how to use the panel that displays details of the errors that occurred when executing the requests in NeoLoad. The Errors panel can be used to correct problems when fine-tuning a Virtual User, or to better understand a server behavior during a load test.
To gain the most from this tutorial, it is recommended to read Design process.
Understand the context
Problems or errors occurring during the execution of a test scenario will bias your results making them partially or at worst completely unusable. It is therefore important to identify and understand errors occurring during a scenario run. In some situations understanding the source of a problem can be a relatively complex task. To help you analyze causes of an error, NeoLoad provides extensive information on the context in which the error occurred. This tutorial details where and how NeoLoad provides this information.
The two main places NeoLoad indicates that errors have occurred and details them are in the Virtual User Check
dialog box and in the Errors
tab of the Results
mode. The following section presents the Virtual User Check
dialog box and goes into the details of understanding the information provided by NeoLoad. Because the information provided by NeoLoad and the way that information is presented are very similar, if not identical in both cases, the third section only details the slight differences and the information specific to the Results
mode.
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 theGET
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 Response code: 500 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 easily 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.
Analyze errors on a scenario run
Running a particular scenario will produce statistical results and provide a comprehensive list of all the errors (and assertions failures) occurring during the scenario run. The following screenshot shows the content of the Errors tab in Results mode after having run a particular scenario. As mentioned earlier, the information shown in this tab is very similar to that shown in the Check Virtual User dialog box:
Errors are also displayed by NeoLoad in Runtime mode during a scenario run, in the Runtime Errors tab.
The following points are where the Check Virtual User dialog box and the Errors tab differ:
-
The Errors tab lists lines for HTTP requests only, contrary to the dialog box which presents a line for the HTML page a request belongs to. This is mainly because the Errors tab displays an error line for each type and each instance of a Virtual User played during the scenario.
-
The Errors tab displays errors for each Virtual User played during the scenario, contrary to the dialog box which, by definition, concerns a unique user. A scenario defines a number of Virtual Users to be played. These users belong to different Populations and include different types of users. Hence, errors can occur for multiple users and multiple types of users.
In the example, the scenario has errors concerning two types of users,SimpleUser
andOccasionnalUser
. NeoLoad numbers the users in the order they ran. -
The Errors tab provides the response and request preceding the request causing the error. In some situations, an error occurring on a request may be caused by the previous request or response, so easy access to those elements greatly helps in understanding an error cause.
The rest of this section details how the new elements provided by the Errors tab can be used.
Filtering and Sorting by Virtual Users
In the example, you may want to analyze the 500 error generated on the OccasionnalUser
Virtual User. You may also want to concentrate on a particular user of this type, the OccasionalUser#5
.
-
Filtering: To only work with a particular type of user, the easiest way is to filter out the display of errors by selecting the type of user in the Virtual Users drop down list box.
-
Sorting: Working with a particular user is easily achieved by sorting errors by Virtual User: clicking on the Virtual User column header.
Using the Previous Request
In the example, the GET request /loadtest/error
has returned an HTTP 500 return code. This is the following error code : Internal Servlet error
.
If you take a look at the previous request by selecting the previous request radio button , you understand that the loadtest/redirect/simple.jsp
page has been requested.
You can now push your investigation a little further and display the response returned by the previous request by selecting the previous response radio button.
The response contains a 302 Moved Temporarily
code redirecting the client Agent to the page called loadtest/error
. The problem is therefore in the loadtest/redirect/simple.jsp
which redirects to an error page. This simple example shows you how to meaningfully use the information NeoLoad provides concerning the context in which an error occurs.
Related links
For more information about HTTP response codes and NeoLoad status codes, see section Neotys status codes and HTTP status codes.