Due to requests from many of our users, we’ve rolled out two new features to BrowserMob:

  1. The ability to specify “think time” for virtual users with the setSpeed and pause commands.
  2. The option to reference the unique “virtual user” ID, which makes testing sites that don’t allow concurrent user logins much easier to test.

Here’s a brief summary of each feature. You can consult our documentation or our support team if you have any additional questions.

New Think Time Support

Firebug is a popular tool among web developers that helps with JavaScript debugging, CSS and HTML design, and web performance optimization. It’s truly a Swiss Army Knife for web developers. But it’s also a great tool for anyone doing web testing. Unfortunately, not all testers know about Firebug yet, so this is our attempt to share.

Whether you’re using BrowserMob for load testing, Selenium for functional testing, or any other open source or commercial traditional load testing tool, Firebug can be a huge asset. Three things we at BrowserMob find love about Firebug are:

Scott Barber answered a question on SearchSoftwareQuality.com about how to conduct performance testing without using any tools. He goes on to state that being denied tools is likely a bad idea, but regardless of whether you have great tools (such as BrowserMob) or you have none, there are a lot of areas to focus on in addition to what a load testing tool does:

Now, after saying all of that, I must admit I have found that the vast majority of value that is gained by quality performance testing comes outside of the load-generation tool. Some of my favorite techniques (assuming you are testing websites):

Steve Souders recently wrote up an excellent article on how to build high performance web sites. His advice is to focus on what the end-user experiences, which means focusing on everything from the HTML construction to browser caching to network infrastructure and delivery. He provides 14 “rules” to follow and it’s a great eye opener!

Steve is also the author of YSlow, a plugin for the popular Firebug tool. We strongly encourage all our customers to use Firebug and YSlow when doing any load and performance testing on their site. They are great tools to go along with Selenium IDE and BrowserMob.

Sanjay Dange wrote up an excellent summary of why QA professionals don’t have to hide from open source. You can find the article on his blog and reproduced at Test Republic. I made the following comment to his article and I think it’s worthwhile to share here as well, as it explains why we set out to create BrowserMob:

As a contributor to Selenium, an open source functional testing tool, I have also seen a lot more willingness to try out open source technologies.

A common question we get here at BrowserMob and elsewhere in the open source and QA communities we’re involved in is: “what’s the difference between stress testing, load testing, and performance testing?”

The three types of tests are often used interchangeably, though they do actually have somewhat different meanings. Fortunately, a friend of ours, Grig Gheorghiu, wrote about this very topic a few years ago in two blog posts:

Selenium is a popular open source, cross browser functional testing tool. You can learn more about it here. If you’re looking for functional testing solutions that use real web browsers, we strongly encourage you to take a look at Selenium.

We have a close relationship with Selenium: BrowserMob’s founder, Patrick Lightbody, was the original creator of the most popular version of Selenium, Selenium Remote Control. So it’s not surprising that BrowserMob utilizes Selenium technologies for both the record and playback of web traffic.

Because Selenium is a functional testing tool, it isn’t really meant to be used as a load product. There are two reasons for that:

There is no hard or fast rule on how long your tests should be, since it all depends on what you’re trying to do. However, we can provide some general guidance as well as some tips to optimize your value with BrowserMob.

First, it helps to know a bit about how the application works, since that may very well determine how long you should run your test for.

There is no clear cut answer to this, but we’re happy to provide guidance.

Your business liaison (usually a product manager, project manager, or analyst) may know the answer right away, since there may be specific business goals associated with the project.

The system architect may also have a good idea of what the capacity of the overall system is, so that might be another place to start asking.

You should also read our FAQ on hits/second vs. concurrent users, as that may help you better think about how many virtual users you need in a load test.

Like most aspects of load testing, there is no easy or simple answer to this question. The answer often depends on what your goals are, how the application logic works, and what parts of the application you’re trying to test.

But in general, it’s important to clearly define various terms, which will help communication amongst your team and help you get to a clear goal before starting testing.

Some common words or phrases that are worth clarifying are:

© 2012 The BrowserMob Blog Suffusion theme by Sayontan Sinha