Loadster is a platform for distributed load testing of your web applications, web services, and static websites from the public cloud or private networks.
Soon, you’ll be creating test scripts to simulate realistic user behavior, and running them with hundreds or thousands of concurrent users, to measure and improve your site’s scalability and performance.
First, let’s take a second to get familiar with a few of the terms you will see within this manual.
The process for load testing with Loadster generally goes like this:
Create a script to simulate your actual user path through the site you’re testing, as realistic as possible.
Build a test scenario describing how many virtual users (v-users) should run your script, from which cloud region or self-hosted engine, and for how long.
Run a test and observe in real time how your site is responding and what errors Loadster is encountering.
Analyze the results of your test and figure out what went wrong.
It may take multiple load tests (sometimes quite a few) to get a full and accurate picture of how your site performs and scales. It’s usually a good idea to create a baseline load test scenario and re-run it periodically as your site and hosting environment changes, to make sure performance doesn’t degrade and bottlenecks aren’t introduced.
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 load test (recommended for most sites).
Your scripts should replicate real user behavior as closely as possible. The more realistic your set of test scripts, the more 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 your scripts in an ordinary web browser, or you can add and edit steps manually.
Many sites have some way for users to submit form data or uploads. This is especially true of web applications and APIs. For example, each of your users may have a different username and password, email address, and other data that they will enter into forms or submit to an endpoint. In this case, you can supply unique data for each v-user with Dynamic Datasets.
There will also be times when the application returns dynamic data for each user. An example of this would be account creation: if your script registers a new account, the web application may assign a unique id that will need to be reused later in the script. Have a look at Capturing Rules and Validation Rules to learn more about dealing with dynamic responses from your site.
To run multiple users at once, you’ll need to create a test scenario. Scenarios include one or more v-user groups, each of which contains some number of v-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.
Launch the scenario to run a load test. Make sure to keep an eye on the test as it runs, to see how your application is responding to the load. You can always stop a test prematurely, tweak it, and restart the test if you need to.
Once Loadster has finished the load test and collected and processed your test data, you’ll need to analyze and interpret the results so you can evaluate whether the test passed or failed, and plan your next steps.