BrowserUp offers a new approach to load testing, the first
See our manifesto for more about why we think this is the right approach to load testing.
How is it different?
BrowserUp is a DRY (Don’t Repeat Yourself) Load Testing Tool
It runs your code, libraries, page objects, binaries, and PostMan definitions to drive load for load tests. Why should you maintain two implementations of “how to talk to your app” when you can maintain one?
Don’t Repeat Yourself!
BrowserUp uses the cloud to “scale the things that make requests.” With traditional load testing, you scale an optimized thin-client script that makes requests that are kindof like the real ones, or at least kindof like how the real thing worked at the moment you hard-code it or captured it.
You’re forced to maintain a second, shadow, implementation of your request-logic for every API or UI you want to load test. Worse, these scripts are usually in the load tool’s language, UI, or IDE. And because they are a snapshot, they go stale quickly. So we create them last, once the development-dust settles.
There’ve been many attempts at shifting load testing left–earlier in the development cycle–but none succeeded because they all fall in this trap: they require you to maintain a second implementation of your request-logic.
Until Now!
BrowserUp uses assets you already have, so you can test earlier in the release cycle and shift your load testing left.
Overview
- BrowserUp scales your code in our “magic” traffic-capturing containers. This means logic and condition-handling code just works
- BrowserUp containerizes your stuff (automatically) and scale containers running your code to generate load
-
BrowserUp captures the traffic and provides rich reporting
- BrowserUp stays out of your way–work in your repo, in your IDE, in your language of choice
- Built-in multi-region cloud run capability
- Your data stays in your EC2 account
You might be thinking “what scripting language do I use to create the script?” The answer is: anything you like that causes traffic!
Java and Selenium?
Playwright?
C# with Selenium?
Your PostMan library (newman)?
Python script?
Ruby Script?
Some binary or command-line app you compiled yourself?
Any other thing, yes, probably!
So do I have to worry about containers now?
Probably not! BrowserUp has a standard container with Java, Javascript, DotNet, Ruby, Python, Bash, Postman and Curl and some other things ready to go. It has Chromium, Playwright and Chromedriver installed and ready for each of these languages. This image is the browserup/standard image and you get it, plus your assets (code under the test dir) by default. It should just work and you probably won’t need to think about containers.
Custom Containers
If your needs are off the beaten path, the browserup/custom-base container option gives you an escape valve where you can install more or less anything into a container to drive load. Just build on our base image.