Contents ▼

Playing Scripts

Playing a script in the Script Editor lets you discover and fix any errors in your script before running a load test. It is always a good idea to play the script first in the Script Editor, with just a single virtual user, where it is easy to diagnose errors.

There are two ways to play a script in the Script Editor: Fast Play and Play.

Fast Play and Play

Either button will play each step in the script sequentially; however, Fast Play shortens all wait times, while Play keeps them as-is. Wait times are generally unnecessary when scripting, but important when running an actual load test.

As your script plays each step, you will see some flashing lights and a status displayed when the step finishes.

Steps with green lights indicate success

Steps with red lights indicate errors

Successful steps will appear with three green dots showing underneath the type of HTTP command (GET, POST, etc.). If an error is encountered, these same three dots will appear in red, as shown below:

You can stop script playback at any time by clicking on the Stop (Square) Button in the toolbar.

Stopping a script when it is still playing

At the bottom of the Script Editor, you will see the Logs and Requests tabs, which tell you about the script that just ran.

The Logs tab displays output from each step, such as the URL, processed response body size (in bytes), info about additional page resources, and any errors that may have happened.

Use the log to see how the script ran

The Requests tab lets you drill into a tree view of every HTTP step that was executed, to view the full requests and responses.

Use the Requests tab to drill down into specific steps

Diagnosing Script Errors

It is pretty common to receive one or two errors the first time you play your script.

Diagnosing Script Errors with the Playback Logs

As a script is played, Loadster displays a log of what requests are made, their response codes, and other information. This can be really helpful in determining what went wrong. Errors show up in red under each step.

Script errors show up in the log

The error displayed above is a simple HTTP 404, due to the URL within the HTTP step being incorrect. Errors can occur for many reasons. It is helpful to have knowledge of the HTTP Response Codes and how they are used by your application. A few of the more common response codes are as follows:

  • 200 - Successful
  • 301 - Moved Permanently (a type of redirect)
  • 302 - Moved Temporarily (another type of redirect)
  • 404 - Not Found (the URL is probably incorrect or the resource is missing on the server)
  • 500 - Internal Server Error

Skimming through the logs can often give you all the information you need to know if your script is playing correctly, and if not, to diagnose and fix script errors.

Diagnosing Script Errors with the Playback Details

If you are unable to spot what went wrong from the Logs, Loadster also provides a more detailed way to view script results. The Requests tab shows a tree-like view of every HTTP step that was executed.

Drill down into individual steps to see the requests and responses

You can drill down to see details about the request and response. By double-clicking, you can even view the entire request or response body in a separate window.

Diagnosing Script Errors from Your Application Logs

On the rare occasions that you are getting script errors and still cannot figure out what is going on from within Loadster, you should look to your application and server logs. Since load testing is specific to your application, these will often provide the details you need to figure out what went wrong.

Fixing Script Errors

So you have found the source of script errors… now what?

You can now edit your script to fix whatever may be wrong with it, add extra validation logic, etc.

Very often, script errors are data-related. Your application might expect unique, non-duplicate form data to be submitted each time the script is run. It is also likely that your application is generating a new session identifier or some other key each time, and expects the client to regurgitate that identifier just like a normal browser. See Dynamic Datasets and Capturing Rules for a couple ways to handle dynamic data.

Next Steps

Once your script is playing correctly with a single user, you’re ready to run a load test. Create a Load Test Scenario to run the same script with multiple concurrent users.