Contents ▼

Getting Started

Loadster is a cloud-hybrid solution for distributed load testing of web applications, web services, and static websites from either side of the firewall.

Load Testing Terms

Let’s take a second get familiar with a few of the terms you will see within this manual, as they are used in Loadster.

  • Virtual User or V-User - A simulated user. Imagine a pretend user sitting in a chair somewhere with a web browser. Now imagine thousands of them! Each virtual user has its own session state, cookie store, etc. A load test typically consists of many virtual users hitting your site at once.
  • Virtual User Group - A group of virtual users, all running the same script with the same playback options. You can have multiple groups in a load test if you need to simulate multiple user behaviors simultaneously.
  • Script - A sequence of repeatable steps. Steps normally represent an HTTP(S) request for or web page or API endpoint (optionally with static content resources, capturing rules, and more). They can also represent wait times between requests.
  • Scenario - A test scenario, made up of one or more virtual user groups. Think of it as a recipe for a load test. Each group within the scenario can have its own settings and behavior, such as simulated network bandwidth, randomized wait times, etc.
  • Dataset - Datasets contain unique parameterized values for each virtual user. When multiple virtual users are submitting web forms or other transactional data, a dataset can make your script a lot more realistic.
  • Test Run - Archived results from a load test that was previously run. From a test run, you can export a report and share results with your team.

Load Testing Process

The process for load testing with Loadster generally goes like this:

  1. Create a script to simulate your actual user path through the site or application you’re testing, as realistic as possible.

  2. Build a test scenario describing how many virtual users (v-users) should run your script, from which cloud region or engine, and for how long.

  3. Run a test and observe in real time how quickly your site is responding and what errors Loadster is encountering.

  4. Analyze the results of your test and figure out what went wrong.

Creating Your Scripts

A script simulates the path of a single user through your site. You can create multiple scripts if you want to simulate multiple user paths in the same test (recommended for most sites).

It probably goes without saying that the more realistic your set of test scripts, the more valid and useful your load testing results are going to be. The results of a load test are only as valid as the assumptions going into it.

With Loadster, you can record scripts in an ordinary web browser. For more about this, please see Recording Scripts.

You can also add steps to a script manually or edit them after recording (see Editing Scripts).

Handling Dynamic Data

Unless your site is very simple, you’ll have to deal with unique data coming from each user. If each of your users has a unique username/password, email address, or fills in forms with some other personal data, you will need to parameterize your scripts to pull from Dynamic Datasets.

There will also be times when the application returns dynamic data. A prime example of this would be account creation: if your script registers a new account, the application will probably assign a user id or something that would need to be captured and reused later in the script. Have a look at Capturing Rules and Validation Rules for more info on dealing with responses from the application.

Running Load Tests

To run multiple users at once, you’ll need to create one or more Load Test Scenarios. Scenarios can include one or more virtual user groups, each of which contains some number of users executing the same script. Scenarios can be configured with many different options, such as the total number of virtual users, instructions for ramping the user load up/down, simulating network bandwidth, etc.

Once you’ve configured a scenario, it’s time for Running Load Tests. Make sure to keep an eye on the test as it runs, to see how your application is doing under load. You can always stop a test prematurely, tweak it, and repeat if you need to.

Analyzing Results

Last but not least, once Loadster has collected and processed your test results, you’ll need to analyze and interpret them. Loadster makes this pretty easy with its HTML reporting. For more info on how to do this with Loadster, see Analyzing Results.