Real browsers absolutely matter. That’s why we created BrowserMob! There are two major reasons why real browsers matter:

1. It simplifies the script creation process by letting you avoid all the complexities and hacks you have to do with traditional load testing tools.
2. It ensures that you’ll see 100% of the traffic and load against your site that a real user would cause.

These are fairly complex topics once you scratch beneath the surface. If you’re interested in knowing the detailed reasoning why real browsers help in both of these cases, continue reading.

Simplifies Script Creation

In today’s modern web applications, AJAX is just about everywhere. And we’re not necessarily talking about super rich applications like Google Maps or Yahoo Mail, but even simple sites like google.com now use advanced AJAX techniques. See Google’s auto-complete for a real-world example:

In this case, when typing values in to the search box, the web browser executes JavaScript logic that in turn makes AJAX calls to Google’s search engine, asking for search suggestions to display. It does this on every keystroke that the user types in.

When recording a script with a traditional load testing tool, one of two things may happen here:

• The recorder will see the AJAX traffic and capture it for playback in the load test
• The record will not see the AJAX traffic and will only capture the request made when the user clicks the “submit” button

Obviously these AJAX requests are causing real load, so we want to make sure they get played back in a load test. So let’s assume that the script you recorded does indeed capture the AJAX traffic. What would it look like? Something like this:


http://clients1.google.com/complete/search?hl=en&gl=us&q=s
http://clients1.google.com/complete/search?hl=en&gl=us&q=se
http://clients1.google.com/complete/search?hl=en&gl=us&q=sel
...
http://clients1.google.com/complete/search?hl=en&gl=us&q=seleniu
http://clients1.google.com/complete/search?hl=en&gl=us&q=selenium


As you can see, the keys typed by the user are included in each subsequent search term. Let’s ignore the requirement of validating the results that come back from the AJAX requests for the moment (they are usually in JSON or XML format and difficult to validate using most tools). Instead, let’s just add a twist to the load test requirement for doing searches: the load test must search from 100 different search terms.

Parameterization very common requirement, since it ensures that the load is realistic and doesn’t get cached in any unnatural way. This means that now in addition to searching for the term “selenium”, we’re also searching for “AJAX”, and “browser”, among others.

However, this means your script can’t just blindly submit requests to those previous URLs either, since those were tied to the “selenium” term. Instead, they must search for the sequential characters of the respective search term, such as:


http://clients1.google.com/complete/search?hl=en&gl=us&q=b
http://clients1.google.com/complete/search?hl=en&gl=us&q=br
http://clients1.google.com/complete/search?hl=en&gl=us&q=brow
http://clients1.google.com/complete/search?hl=en&gl=us&q=brows
http://clients1.google.com/complete/search?hl=en&gl=us&q=browse
http://clients1.google.com/complete/search?hl=en&gl=us&q=browser  


Unfortunately, this is where even the best traditional load testing tools fall down. They don’t provide any help here, so it’s up to you to figure out how to, if it’s even possible, write complex scripting logic that breaks down the randomly selected search term by characters and then subsequently issue AJAX requests for each character in the term. Oh, and also note that the URLs start with “clients1″, which indicates that perhaps Google has many servers to handle these requests and the server is embedded in some JavaScript or HTML from the original page, so you may have to parse that out too!

At this point, you’re basically rewriting the same logic that the application developer wrote originally. If you’re a QA engineer, this may be difficult since you don’t know all the internal details coded in to the application. If you’re the developer, it’s still annoying because it’s tedious and likely in a language other than the original JavaScript that you wrote your code in.

So how does BrowserMob help?

Because BrowserMob uses real browsers to both record and playback load, that means you don’t have to worry about trying to simulate the logic in a web browser. Instead, all you have to do is record the human interaction with the browser, such as typing in a randomly selected search term. BrowserMob will then pass those instructions on to the hundreds or thousands of browsers participating in the load test, and those browsers will in turn “do the right thing” and issue the proper AJAX requests.

And if the underlying logic, such as the request URL pattern for those AJAX requests, changes? With traditional load testing it’s up to you to detect and fix the problem. With BrowserMob, your script won’t need to change one bit – the new AJAX logic will be run by the browser in real time.

Ensures Realistic Traffic

We’ve seen how BrowserMob helps with recording, but what about playback? As we just learned, using real browsers simplifies the process of recording and shrinks the behavior coded in to the script itself. This means we’re letting the real browser – the same type of program your end users will use – make the decisions about what requests to make.

For example, when visiting http://ebay.com you might see the following page:

But reload the page and now you might see this:

Notice a difference? the “Today on eBay” section has completely different images displayed. That’s because eBay’s home page chooses what to display based on complex and multi-variant logic determined at runtime. It’s quite likely that it’s going to be impossible for a load tester to know which images will be displayed on any given request.

It’s true that some load testing tools will try to parse the pages in real time and figure out which images should be displayed, but that’s hardly comforting once you’ve already learned they can’t deal with even the most simply AJAX components, as we just saw.

Instead, the only way to guarantee that every single object (image, JavaScript, AJAX request, advertisement from an ad partner, etc) gets requested is to use a real web browser. And no one does that except for BrowserMob.

Tweet This Post 

No tags