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.
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.
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.
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.
The Requests tab lets you drill into a tree view of every HTTP step that was executed, to view the full requests and responses.
It is pretty common to receive one or two errors the first time you play your script.
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.
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:
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.
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.
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.
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.
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.
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.