Stay in the driver’s seat and in control!  When launching a new website or application there are many things to consider to get ready to go “live” – and one of the most important aspects is load testing.

Simply put, load testing helps you determine how many customers the website or application will support – before you potentially find out the hard way (i.e. when users actually come to your site and you have to scramble to make last minute capacity improvements).

Following our blog series on Load Testing Best Practices, Webmetrics will be hosting a Twitter Chat for you to ask any and all questions about load testing.

As you build out your script and plan for a successful load test, it’s important to design the script that incorporates timeout values. BrowserMob has a few types of timeouts that you can use: HTTP-level, Selenium page-level, and Script-level timeouts.

HTTP-level timeouts are controlled by the HTTP client, usually the “c” variable. var c = browserMob.getActiveHttpClient(); and there are 3 commands relating to HTTP timeouts: setConnectionTimeout, setRequestTimeout, and setSocketOperationTimeout.  For more information, check out our API documentation which outlines each of these commands.

selenium.waitForElementPresent(“myelement”);

The waitForElementPresent commands polls the page waiting for the specified element to load. If you are familiar with Webmetrics/WATIR scripting, the command is very similar to the wait_until() command. The waitForElementPresent command is most often used on sites containing dynamic content such as Ajax, JavaScript, etc. Scripts are designed to execute as quickly as possible and Selenium tends to fire steps faster than the DOM can render changes, causing issues/errors with the script playback.

There are a few ways to determine if you need this command:

The first is to check the playback in SeleniumIDE:

This article covers how BrowserMob can be used to test mobile websites by modifying the User-agent header and connection speed to match the desired device (iPhone, Android, etc.).
When deciding which version of the website to serve up, most mobile-enabled web applications rely on parsing the User-Agent http header. By modifying this value, BrowserMob Real Browser Users (RBUs) can be turned into “Mobile Browser Users”.

The first step is to determine what specific devices you want to simulate. Zytrax has put together a great compilation of the various different mobile browser user-agent strings here.
Once you’ve determined the User-Agent strings you want to test, the next step is to update the script to overwrite the standard User-Agent header in Firefox. This can be done via the following snippet:

The BrowserMob API has two methods that come in handy when you want to pause a test that has exceptionally lengthy scripts running, such as loops that repeat certain actions several times over the course of the script execution.

By default, when a test is paused, BrowserMob will wait for the actively running scripts to finish executing and complete the current transaction. Long running scripts with loops or scripts testing a streaming video will not be interrupted until they complete. So in order to abort such transactions immediately on pausing, it is important to include the method browserMob.quickStop() at the top of the script as in the example below:

We recently had a customer from a large clothing retailer ask us if there was any way to ensure that data, such as a username/password combination, could be restricted such that it was “checked out” and available only for a specific concurrent user. This is very common with logins, where systems often will prevent concurrent logins from multiple IP addresses.

While BrowserMob does not have a concept in which data rows can be “checked out”, some simple scripting can achieve the same results. The key is in creative use of the browserMob.getUserNum() and browserMob.getTxCount() APIs. You can learn more about them by reading up on the BrowserMob APIs.

Because both our load testing and website monitoring services are based on Selenium, we have a unique ability to measure the performance of things like page load times, AJAX timings, and other in-browser interactions.

Selenium has both a setTimeout command and a waitForPageToLoad command. Both can be given a timeout value, which will control how long Selenium waits for a given page to load or element to appear. When it comes to using our services, most people stick with the default time of 30 seconds. If the timeout is reached, an error is thrown, the script aborts, and the transaction is recorded.

When setting up monitoring jobs, there are often predictable time periods in which you want to change the behavior of a script or prevent it from running at all, without having to manually stop/start the monitoring job each time. For instance, you might want to prevent errors and alert emails during routine maintenance windows, or perhaps you’re only interested in site performance on weekdays during regular business hours. We’ve come up with solutions to a few common situations that will help jump start your scripts.

BASIC authentication is used to provide minimal, low-security protection from anonymous visitors hitting your website. It is frequently used by companies to ensure that their staging or development environments are not accessibly by the general public prior to pushing the changes to production. Typical authentication dialog prompts look like so:

200912080850.jpg

The challenge here is that this dialog box is the kind of dialog that Selenium cannot automate. You cannot issue “type” or “click” commands on it. In fact, if this box comes up, your script is guaranteed to time out because Selenium will continue to wait for the page to load, not realizing a login is required and unable to populate it.

© 2012 The BrowserMob Blog Suffusion theme by Sayontan Sinha