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 v-user, where it is easy to diagnose errors.
There are two ways to play a script: 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 through each step, you will see some flashing lights and a status displayed when the step finishes.
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.
You can stop script playback at any time by clicking on the Stop Button in the toolbar.
At the bottom of the Script Editor, you will see the Logs and Requests tabs, which tell you about the script that just played.
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 occurred.
The Requests tab lets you drill into a tree view of every HTTP step that was played, so you can view the full requests and responses.
Diagnosing Script Errors
It is pretty common to receive one or two errors the first time you play your script. If this happens to you, don’t worry! You can determine the cause of the error and (most likely) make adjustments to your script or site to fix the error.
Diagnosing Script Errors with the Playback Logs
As your script plays, Loadster shows you a realtime log of the requests being 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.
The error displayed above is a simple HTTP 404, due to the URL pointing to a non-existent resource. Errors can occur for many reasons.
It is helpful to have knowledge of the HTTP Status Codes and how your application uses them.
Here are a few of the HTTP status codes you will commonly see when load testing:
- 200 - Successful
- 201 - Created
- 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
- 502 - Bad Gateway
- 503 - Service Unavailable
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 the last time you played your script.
You can drill down to see details about the request and response. You can even view the entire request or response body by clicking on the magnifier.
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.
This is particularly important sites that hide the details of errors and instead surface opaque error messages to the client.
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 possible 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.
Once your script is playing correctly with a single user, you’re ready to run a load test! Create a Load Test Scenario to specify how to run your script with multiple concurrent v-users.