Recording a script from your web browser is often the easiest way to get started.
Recording is especially helpful for static sites with lots of page resources (images, CSS, JS, etc) or dynamic web applications. It can also be useful for testing APIs that serve as the backend for a single page web application (SPA).
To record your browser traffic and make a Loadster script, you’ll need the free Loadster Recorder Browser Extension, currently available for the Chrome and Firefox browsers.
After you’ve installed the extension in your browser, expand it from the Loadster icon in the toolbar.
Toggle the switch to Enabled when you are ready to share your browser traffic with Loadster for the purposes of recording scripts. When enabled, the Loadster Recorder Chrome Extension sends your browser events to loadster.app as well as localhost:1999, which is the port that Loadster Workbench listens on.
When you’re finished recording your script, toggle the switch back to Disabled or uninstall the extension so that your traffic will no longer be available to Loadster.
The browser extension is open source and you can review the source code on GitHub.
To start recording, open a new or existing script and hit Record.
Loadster will start communicating with the Loadster Recorder browser extension and listen for traffic.
Enter the URL of the first page you want to record.
When you hit Start Recording, Loadster will open a new browser tab to that location. Whatever you do in that browser tab will be recorded as an event and show up in the recording log. Traffic in your other browser tabs is not recorded.
Click Stop Recording when you’re finished.
Many sites have a lot of 3rd party trackers, ads, and other content that you may not want in scope for load testing. You can leave these out of your test script.
After you stop recording, uncheck any domains and/or event types that you do not want included in your script.
When you click Add to Script, Loadster will convert your raw traffic into steps and append them to your script.
You might notice that many of the events have been folded up as resources of other events. Loadster does its best to determine which requests are primary requests (pages) and secondary requests (included CSS, JS, images, etc). For this reason, the number of steps added to your script may not match the number of raw events that were recorded.
Recording saves time, but it isn’t always perfect! Avoid the temptation to blindly record and play back scripts without reviewing and understanding them first.
When you record your browser traffic, Loadster does its best to guess the relationship between pages and their resources. Typically, images and stylesheets are recorded as static page resources under the pages that requested them, rather than independent steps. However, there are cases when you may need to tweak the script after recording to get it just right.
Also, if you are testing a dynamic site with complicated interactions (such as an OAuth flow or a series of form submissions, or an API), the initially recorded script might need to be edited a bit to allow for repeated use. You generally wouldn’t want to submit the exact same recorded data over and over in a load test.
You may also want to delete recorded steps that you don’t want in your script.
Last of all, always play through your script with a single v-user before running a load test, to make sure the script runs as intended and you know what it’s doing!