Terms & Definitions

Key Terms

Let’s take a moment to get familiar with a few of the terms you’ll encounter in the Loadster documentation.

Site

Here in the Loadster docs, we frequently use the term “site” broadly to describe a website, a web application, or an API… pretty much anything that’s served by a server to a client over the HTTP/S protocol. Depending on whether you’re testing a static site, a dynamic web application, or an API, your scripts will be different, but the overall load testing approach is similar.

Bot

A bot is a simulated user, sometimes called a virtual user or a v-user. Each bot maintains its own independent session state, cookie store, etc, just like a real user. A load test is when many bots are hitting your site at once.

Loadster has two types of bots: Protocol Bots with multithreaded HTTP clients, and Browser Bots with real headless web browsers. Protocol Bots are cheaper to run (see Pricing), but Browser Bots are more realistic and also easier for testing complex websites or web applications.

Script

A script tells bots what to do.

Normally, a script should simulate the path of a single user through your site. You can create multiple scripts if you want to test multiple user behaviors together in the same load test, which is often a good idea.

Each step in a script performs a single action, like loading a page or clicking on a link or sending an HTTP request. There are also wait steps to make the bot pause a while between actions, much like a real user would.

Loadster supports two types of scripts: Protocol Scripts (for Protocol Bots) and Browser Scripts (for Browser Bots).

Protocol Scripts are a sequence of HTTP/HTTPS requests for low-level testing. Since they let you fire off each request individually, protocol scripts are good for testing APIs and simple static websites.

Browser Scripts control real headless web browsers, similar to Selenium or Puppeteer or Playwright. With steps like “navigate to page” and “click on element”, browser scripts are ideal for complex web applications.

You’re free to choose protocol scripts or browser scripts (or both!) depending on your budget and what makes sense for the website, web application, or API that you are testing.

Once you’ve created a script, you can reuse it in many load tests.

Scenario

A scenario is a recipe for a load test, detailing how many bots and bot groups should run your scripts.

You can have multiple bot groups in a scenario if you need to simulate multiple user behaviors or configurations together, or to make the load test traffic come from multiple regions.

Each bot group in a scenario has its own configuration for what script the bots should run, the ramp pattern in which the bots should arrive and leave, how many iterations the bots should repeat the script, what region or engine the bots should run in, and so on.

Scenarios are reusable, so you can easily re-run the same load test multiple times to see how your site’s performance has changed.

Dataset

A dataset contains a table of unique values for each bot to use when executing a script.

For example, if you are load testing a login page, you could create a dataset full of usernames and passwords, and make each bot pull unique account details from the dataset.

A load test in which every bot submits the exact same data wouldn’t be ideal for testing dynamic web apps, because the application or database might cache a lot of things, leading to artificially good results. It’s better to supply dynamic data to your script using datasets.

Datasets might not be necessary for testing simple static sites where every request is the same.

Test

When you launch a load test, Loadster automatically creates bots on the engines or cloud locations you specified in your scenario, and tells the bots to run your scripts.

While the test runs, you can view a dashboard with aggregated results and observe any errors in real time.

After the test finishes, Loadster generates a test report for you to analyze the results and share them with your team.

Test reports remain on your account dashboard after the test finishes, so you can review the test results again later.

Load Testing Process

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

  1. Create a protocol script or browser script to simulate a user’s path through your site, as realistically as possible.

  2. Map your script to a dataset using variables, if it’s necessary for each bot to submit unique data to the server. For simple sites you can skip this.

  3. Build a scenario to configure how many bots should run your script, from which cloud regions or self-hosted engines, and for how long.

  4. Launch a load test and observe in real time how your site is responding and what errors Loadster is encountering.

  5. Analyze the results of your test to determine your next steps.

Load testing is an iterative process. It often takes multiple tests to get a full and accurate picture of how your site performs and scales.