Contents ▼

Editing Scripts

Scripts are a series of steps to be executed by a virtual user. You can view and modify them in the Script Editor.

Adding a Step

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

Manually add an HTTP step

Manually add a Wait step

An HTTP step makes an HTTP request to a server. A Wait step causes the virtual user to wait for a specified amount of time before continuing with the script. We’ll talk more about each of these soon.

Copying and Duplicating Steps

Predictably, to copy a step, simply select it and do the usual Copy and Paste function.

Duplicating a step

You can also duplicate the selected steps with the Duplicate option in the editor.

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, but it can be re-enabled at any time.

Removing Steps

You can also remove one or more steps from your script. Simply click once on the step to highlight it, and then use the Delete key on your keyboard or the corresponding button in the Script Editor.

To delete a step, select it and hit delete

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.

While working in the Script Editor, however, you can Fast Play your script to bypass the wait times.

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. Traditionally, POST and PUT requests tend to have bodies, while other types do not.

Expand the Request Body to view the body and content type

Loadster supports both text and binary request bodies.

If the body is a typical web form, you can edit it as key-value pairs with Edit as form….

Editing the contents of a web form submission

If it’s a typical web form or some other text format, you can view and edit the raw body with Edit as text….

For any content type, including binary, you can replace the body directly from a file with Replace from file….

It is important that the Content Type of your request body is correct. Loadster sends this so that the server knows what kind of content to expect. 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 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.

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.