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 HTTP/S. Depending on whether you’re testing a static site, a dynamic web app, 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 easier if you’re testing a complex website or web application.

Script

A script simulates the path of a single user through your site. You can create multiple scripts if you want to test multiple user paths in the same load test, which is often a good idea.

Usually, 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, as a real user would.

Loadster supports two types of scripts: Protocol Scripts (used by Protocol Bots) and Browser Scripts (used by 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 ideal 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 best 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 create 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 want the load test traffic to come from multiple regions.

Each bot group in a scenario has its own configuration for what script the bots should run, the gradual 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 later 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 supply 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 isn’t 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 mix up the dynamic data in your tests.

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

Test

In Loadster, a test is created when you launch a load test from a scenario.

While a load test is 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 at any time.

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.