When a recording is first uploaded, it behaves the same as when it was recorded; That is, it makes all the same requests, with no differentiating qualities. Until you parameterize it, our application will simply repeat all of the GETs, POSTs, and occasional PUT requests the same way they were recorded, but we handle a few things automatically such as cookies and most form tokens.

Often new scripts can have a bundle of requests and only a few of which that need parameterization to work as expected for every VUser that makes that request. These problems are often found when a request’s recorded status code does not match its status code from the last script execution. Problems such as a failed login request can cause subsequent requests to fail, causing a domino effect. For this reason, it’s always a good idea to start from the earliest requests and work your way down, checking that requests are behaving as expected during a single script execution. Even after it’s all fixed, a small load test is a good way to check that it is also working as expected for concurrent users.

When parameterizing a script, here are the key recommendations:

  • Manage servers
  • Start with first requests and proceed sequentially
  • Examine POSTs to make sure you are getting the response you expect (e.g. login)
  • Check script Settings such as Think Times, Timeouts, etc.
  • Re-execute the script after changes
  • Run a small load test to confirm your script is working as expected (debug test)

Tips and Tricks to Troubleshooting

Where to Begin

Switch to the Manage Server sub-tab and ignore all non-essential third-party servers. The goal is to test your web application, not someone else’s. If you feel the service they’re providing you is critical, please contact [email protected] for help with server verification. After these have been ignored, execute the script again. This will make things easier when determining which requests you need to work on because the unnecessary requests will now show a status of ignored instead of a response code.

Filtering

You can make it easier to find problematic requests by using our filtering options. To quickly bring all of the apparent errors to your attention click the All Errors radio button.

For the less obvious errors you’ll need to look for mismatched status codes by clicking the Recorded vs Last drop down and selecting the Status Code Mismatch option. As you begin looking at the Recorded Status column and comparing it to the Last Status column for each request you should disregard requests if they show cached or ignored for their last status. Typically the less obvious ones to look for change from a status 200 to a 302, or they were meant to be a 302 and now give a status 200.

If you’re unfamiliar with status code these are some of the most common:

  • 200 = OK (usually delivers some content)
  • 302 = Found (asks the browser to redirect to a response header called Location)
  • 400 = Bad Request (often this means the URL has invalid syntax)
  • 401 = Not Authorized (you need permission such as a login to proceed)
  • 403 = Forbidden (does not allow the target to be viewed with or without authentication)
  • 404 = Not Found (missing the file at this target location)
  • 500 = Internal Server Error (often means LoadStorm made a request that has something the server wasn’t expecting like a static token that should’ve been dynamic)

Another option to filter down to what could be considered your most crucial requests is changing the All mime-types drop down and selecting the text/html option. These requests usually represent each page of text content that your users would need to read and interact with.

Request Details Window

Once you’ve identified a request that you feel is causing problems double-click that request to open the details window. From here you can compare all of the details of a request from its recorded values with the values in the last execution. Any values that differ in the last execution will appear in red. Usually there are values that must appear in red because they need to be dynamic per user. Often these are tokens of some kind such as authentication, userIDs, sessionIDs, viewstates, incremental values, etc. If you find that something appears like a randomly generated token, but is colored black for the last execution then that indicates it was repeated as a static copy of the recorded value. This can often be the cause of problems with a request and cause a domino effect of problems with subsequent requests that rely on passing that token around or other chain of a events that need to occur. To fix this you’ll need to look at prior requests to see where this token is being set, and then modify the problematic request to grab the token from the prior request that would assign it.

Response Content tab in the Details Window

You can often find important information regarding the behavior of a request in the response content. This information could let you know many things such as why your login attempt failed, if you received a stack trace from .NET, or if the page contains some dynamic tokens that are needed in later requests.

Previewing Response Content in a New Browser Tab

We also provide you with a hyperlink near the top-right above the last execution half of the response text. This link will let you preview the text of the last execution in a new browser tab. It is especially useful if you’d prefer to read what’s on the page instead of scrolling through HTML code.

Response Content Validation

If you’re concerned that a request is going to deliver a custom error page that shows a status code 200 which isn’t shown as an error during a load test, then fear not. We have a feature that will allow you to put in place a validation that will flag it as an error under the conditions that you specify. Let’s say you’re expecting a login to send you back to the homepage with some message at the top welcoming the user, but in this case the login failed and now the server is still giving us a status 200 delivering us to the homepage without a welcome message such as “Welcome to our store, Michael!”. You can select the homepage request that comes after the login POST request, and then click the Validate Response Content button. This will display a modal window that allows you to choose text that you expect to see, or that you do not wish to see. So following my example we would expect to see the words Welcome to our store in every response we get for this request, and that’s what you would enter in the expected string field. Now even though this request isn’t appearing as an error under normal conditions we can flag it as an error during a load test.

Utilizing Custom Data to find Dynamic Tokens, URLs, and Strings

Whenever you identify a request that needs something changed to a dynamic value you’ll need to parameterize it to make use of our custom data selector. Depending on the need you’ll have to select the request and click the appropriate modification button to get started. Then in the next modal window that appears you’ll have to select the parameter that you wish to modify and change the modification type to custom and click the Select Data button. Now you’ll be in the custom data window where we gather all kinds of data for you to parameterize with from a convenient location. I’ll leave out the User Data and Generated Data tabs for now because this is really meant to focus on dynamic data that we’re grabbing from the responses to requests in your script.

  • Form Input tab – Here we offer you all extracted names and values of hidden input fields that we find from the responses of requests that come prior to the selected request.
  • Response Headers tab – This provides you with all of the unique response headers from older requests and if there were any duplicate response headers we’ll only display the most recent ones prior to the selected request.
  • Response Text tab – While this is the most complicated one, it also allows the most control over what you wish to use. We have a drop-down that allows you to select the response text from any request prior to the selected of course. Once selected the preview box displays the appropriate content. Now comes the hard part, finding what you need. My trick for to make this go quickly is to use the browser’s find feature which can be opened by pressing the Command and F keys together, or the CTRL and F keys for Windows users. Now you should see a miniature search bar appear within the browser window. Begin typing some identifying text that will lead you to the string, but remember not to enter the string itself since it will be different each time. An example of this would be something like ASP.NET_SessionId=, JSESSION=, __VIEWSTATE=, form_id=, etc. I’ve also seen URL paths that are built dynamically into the anchor tags of links based on your session with the server. That could look like href=”/test/user/12JzntR93/profile” in which case you would want to look for the parts just before the string. Once you find it you’ll need to define a unique start string delimiter and an ending string delimiter to let our application now what the string is between. A quick example of this would be an anchor tag like link which we would then enter a Start String Delimiter of [link] which I’m using the [ ] brackets to represent the input box itself.
  • Cookies tab – The contents found here are rarely used, but in one occasion I needed to help someone parameterize a URL that was taking the JSESSION token set in the cookies and passing it allong with a URL of a later request. So in that case we needed to select the request and click the Modify URL button. Selected the token portion of the URL as the substring we wished to replace and copied it into the substring input field. Then using the custom data we selected the JSESSION token from the Cookies tab.

Similar Posts