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
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
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
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
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
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
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
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
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!
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
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 form fields
Editing the raw body
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
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
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.

Authentication

There are a few types of built-in authentication that are common with a lot of sites. Loadster supports Basic, Bearer, and NTLM authentication out of the box. If you want to use something else, chances are you can make it work with custom headers.

Basic Authentication

HTTP Basic Authentication has been around for decades, and provides a simple way to encode a username and password in an HTTP Authorization header.

Basic Authentication
Basic Authentication

This approach has mostly fallen out of favor with web applications, but remains popular with APIs where a simple stateless authentication mechanism is desirable.

Bearer Authentication

HTTP Bearer Authentication is commonly used with OAuth, and other situations where authenticating with a single API key is desired. The Bearer token is passed in an Authorization header by itself without any kind of encoding.

NTLM Authentication

Some Microsoft servers, particularly for in-house applications, use the NTLM protocol to authenticate users. This is a challenge-response protocol that involves some kind of identity manager such as Active Directory. It requires a Windows “domain” and a username and password.

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
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
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.

Do:

  • 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.

Don’t:

  • 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.