# Terms & Definitions > Key terms and definitions related to load testing web applications, web services, and static websites with Loadster. Source: https://loadster.com/manual/terms-and-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 use 1/4 the fuel of Browser Bots (see [Pricing](https://loadster.com/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 three types of scripts: [Protocol Bot scripts](https://loadster.com/manual/protocol-scripts/), [Browser Bot scripts](https://loadster.com/manual/browser-scripts/), and [Playwright scripts](https://loadster.com/manual/playwright-scripts/). [Protocol Bots](https://loadster.com/manual/protocol-scripts/) run a sequence of HTTP/HTTPS requests for low-level testing. Since they let you fire off each request individually, Protocol Bot scripts are good for testing APIs and simple static websites. [Browser Bots](https://loadster.com/manual/browser-scripts/) control real headless web browsers. With steps like "navigate to page" and "click on element", Browser Bot scripts are ideal for complex web applications. [Playwright scripts](https://loadster.com/manual/playwright-scripts/) let you write standard Playwright Test code for developers who prefer a code-first approach to browser automation. You're free to choose whichever scripting approach makes the most sense for the website, web application, or API that you're testing. Once you've created a script, you can reuse it in many load tests. ### Scenario A [scenario](https://loadster.com/manual/load-test-scenarios/) 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](https://loadster.com/manual/dynamic-datasets/) 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. Keep in mind that each [bot group](https://loadster.com/manual/load-test-scenarios/) gets its own copy of a dataset, so values are unique per bot within a group but not across multiple groups using the same dataset. See [Datasets and Bot Groups](https://loadster.com/manual/dynamic-datasets/#datasets-and-bot-groups) for details. ### Test When you [launch a load test](https://loadster.com/manual/running-load-tests/), 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](https://loadster.com/manual/analyzing-test-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](https://loadster.com/manual/protocol-scripts/) or [browser script](https://loadster.com/manual/browser-scripts/) to simulate a user's path through your site, as realistically as possible. 2. Map your script to a [dataset](https://loadster.com/manual/dynamic-datasets/) using [variables](https://loadster.com/manual/variables-and-expressions/), 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](https://loadster.com/manual/load-test-scenarios/) 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](https://loadster.com/manual/running-load-tests/) and observe in real time how your site is responding and what errors Loadster is encountering. 5. [Analyze the results](https://loadster.com/manual/analyzing-test-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.