Analysis

Analysis
< Prev	Chapter 16. Tutorials	Next >

Table of contents

Analyzing 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's behavior during a load test.

To gain the most from this tutorial, it is recommended to have read the Chapter 10, Design User Guide beforehand.

Understanding 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 and in the Errors tab of the Results mode. The following section presents the Virtual User Check dialog 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.

Checking a Virtual User's 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's Design mode and working in the Virtual Users tab:

In our example, the virtual user called SimpleUser navigates through three pages that logs 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 we'll keep it simple to illustrate error situations.

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

Information provided by the Check Virtual User dialog

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 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 (see below) associated to an error or has a failed assertion, NeoLoad tags the associated line with the icon rather than the check mark. If any one 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. We will detail a little further in this section how essential assertions can prove to be.
In our example, the HTTP request to /loadtest/error has failed. It has a 500 response code but no failed assertions. By selecting that line, we 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 virtual user profile 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 virtual user profile 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.

Tip

Navigating back from the virtual user profiles to the request in the Check Virtual User dialog is easily achieved by right clicking on the request in the Virtual User profiles and selecting the Select in "Check Virtual User" 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.
1. 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.
2. 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 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 our 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:

	Tip
	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.

The following screen shot depicts a situation where something in the network layer has gone wrong. In this case rather than an HTTP response code, a NeoLoad status code is associated to the error and the HTTP response contains the description of the NeoLoad error:

A word on assertions

In our 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 our 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.

The following screen shot illustrates how an assertion can be used to detect that the login process has failed. Note that the HTTP response code is 200, thus indicating a perfectly correct HTTP response.

For more details on using assertions, refer to the section called “Validating a Server Response”.

Analyzing 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's 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 our example, the scenario has errors concerning two types of users, SimpleUser and OccasionnalUser. 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's 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 our example, we want to analyze the 500 error generated on the OccasionnalUser virtual user, we 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.

The following screen shot depicts the result of having filtered on OccasionnalUser and sorted by Virtual User:

Using the Previous Request

In our example, the GET request /loadtest/error has returned an HTTP 500 return code. This is the following error code : Internal Servlet error.

If we take a look at the previous request by selecting the previous request radio button , we understand that the loadtest/redirect/simple.jsp page has been requested:

We now push our 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. Our problem is therefore in the loadtest/redirect/simple.jsp which redirects to a an error page. This simple example shows you how to meaningfully use the information NeoLoad provides concerning the context in which an error occurs.

< Prev	Up	Next >
Oracle Forms: Designing a Scenario with Iterations	Home	Comparing Several Test Results