Contents ▼

Editing Scripts

A Loadster script is a sequence of steps to be executed by a v-user.

Types of Steps

There are several types of steps that form the building blocks for your load testing scripts.

HTTP Steps

An HTTP step makes a single HTTP request. You specify the method, URL, and headers to be sent. If it’s a method that supports a body (like a POST or PUT) you can supply a body too.

You can think of each HTTP step rather like a visual representation of a curl command.

Wait Steps

A wait step pauses the v-user and waits, much like a real user might do when viewing a page and before navigating to the next page.

Wait steps are important for a realistic load test: if you create a script without wait times, your test will probably not be representative of normal user behavior, so you’ll have to discount the validity of the results. Try to include realistic wait times in your script.

Code Blocks

Advanced code blocks are far more powerful than ordinary HTTP steps, and they’re meant for complicated scripting situations that require control flow or conditional logic.

In a code block, you can write your own JavaScript to make requests and parse responses, together with loops, if statements, etc.

It’s important to note that this JavaScript doesn’t run in a web browser; it is run in a sandboxed environment on Loadster’s engines.

In code blocks, you have access to modern ECMAScript syntax like the () => {} arrow functions and const and let, as well as common parsing functionality like JSON.parse and XML.parse. You also have Loadster’s own user object that is basically a user agent for making HTTP requests.

Adding a Step

You can manually add a step to your script by clicking on the relevant step type.

Duplicating Steps

To duplicate a step, hover over it and hit the duplicate icon.

Duplicating a step

Disabling and Enabling Steps

Sometimes when scripting, you want to temporarily disable or “comment out” a step. You can do this with the toggle.

Toggling a step to disabled

The step will become partly transparent and will be skipped when you play the script or run a load test, but you can re-enable it at any time.

Removing Steps

You can also remove one or more steps from your script, with the delete icon.

Deleting a step

If you delete a step by mistake, you can bring it back with Undo.

Reordering Steps

Reordering steps is as simple as selecting one or more contiguous steps you want to move, and dragging them to their new location in the script.

Drag steps to reorder them

When testing dynamic applications, the order of steps is often important.

Wait Steps

Wait Steps are simple. They simply tell the virtual user to pause execution of the script for the specified number of seconds.

A Wait step

Having realistic wait times is important! You should try to make your scripts behave much like a real user would. If your wait times are unrealistic, your load test results will be too.

HTTP Steps

HTTP Steps are a bit more complicated. They represent an HTTP request to the server, much like your user’s browser or client would make. When many virtual users run your script at the same time, it is these concurrent HTTP requests that put a load on your server.

An HTTP step

HTTP Method

The HTTP Method (or verb) is a standard part of every HTTP request. The commonly used methods are GET and POST, but many apps (especially REST APIs) make use of others such as PUT and DELETE also.

Changing the HTTP Method

If you’ve recorded your script, you will rarely need to change the method of a step. However, if you’re creating steps manually, it is important that they have the correct method.

Request URL

The Request URL is critical to each request. These will look rather familiar.

Editing the HTTP URL

Edit the URL inline by clicking on it. If you’re editing query string parameters, make sure they are URL encoded!

Remember to use URL encoding in the query params!

Request Body

The request body is an optional part of certain types of HTTP requests. Usually, POST and PUT requests have request bodies and other methods like GET and DELETE do not.

Loadster supports pretty much any Content-Type you want to use. Content types that are usually text-based (JSON, XML, form fields, text, etc) are directly editable in your script.

Editing the request body and content type

If the body is a typical web form, you can edit it as key-value pairs with the Form Fields tab, or edit the raw encoded body with the Raw Body tab.

Editing form fields

Editing the raw body

You can also replace the body directly from a local file with Load…. This is useful for binary (non-text) content such as images.

It is important that the Request Content Type matches what your server is expecting. The most common type for a web form is application/x-www-form-urlencoded. However, some forms (such as file upload forms) typically send multipart/form-data. REST APIs frequently expect application/json, application/xml or even text/xml.

Last of all, take notice of the Interpolate variables in request body option. This setting determines whether any string in the body that matches Loadster’s ${variable} syntax should be interpolated into a value. Unless you are knowingly using variables in your script, it is safest to disable this option. Learn more about variable interpolation in Variables and Expressions.

Request Headers

Request Headers are sent with every HTTP request. Most of the time, Loadster sends generic default headers for you. In some cases, you may need to specify one yourself.

Setting a custom Content-Type header for a request

The example above sets an Authorization header with an OAuth token.

Page Resources

Loadster can optionally request additional Page Resources with a primary request. If your step includes additional resources, they will be requested in parallel after the main request completes, much like a web browser would load an HTML page and then load the associated images, CSS, JS, etc.

Requesting additional resources along with the primary request

Loadster’s reported response time for this step will include the time it takes to load these resources.

Page Resources only make sense if the request is for a web page. You should not use them when testing an API.

Basic Authentication

One of the ways some websites and APIs authenticate requests is with HTTP Basic Authentication. While you could also use a custom request header to pass this information with each request, Loadster also has a shortcut.

Passing a username and password

If you make use of Basic Authentication, the username and password will need to be set on all HTTP steps that require authentication.

Actually, Basic Authentication is not all that common nowadays; it is more likely you will be passing the credentials with an HTTP POST form submission.

Validation Rules

Validation Rules are a way to assert that the server responds to a step the way you want it to. You can add one or more of these to any HTTP step.

Adding a Validation Rule to a step

Read all about them in Validation Rules.

Capturing Rules

Capturing Rules are a way to capture data from a step’s response, so you can reuse that value later in your script.

Adding a Capturing Rule to a step

Read all about them in Capturing Rules.

Scripting Best Practices

Loadster scripts should represent a single user’s usage pattern as realistically as possible. A load test’s results are only as accurate as the traffic patterns you simulate.


  • Include all relevant HTTP steps and page resources, so your virtual users make the same requests a real user would.
  • If you’re testing an API or dynamic web application, make sure to parameterize any request data that should be unique per virtual user.
  • Play the script to make sure it runs properly with a single user, before launching a load test with multiple users.


  • Remove wait times or leave inaccurate wait times in your script, because unrealistic wait times will cause unrealistic results.
  • Load test someone else’s site without their permission.

Next Steps

Need to parameterize your steps to send unique values for each virtual user? See Variables and Expressions.

Ready to run a load test? Check out Load Test Scenarios.