Hello Readers – I am genuinely excited to announce a release candidate of BrowserMob support for Selenium 2 / WebDriver.

For anyone not familiar with the relationship between WebDriver and Selenium, consider reading the following article – Introducing WebDriver. To summarize, the two frameworks have merged and are collectively being called Selenium 2.

Following is a simple BrowserMob script illustrating Selenium 2 support with links and getting started guides for Selenium 2 / WebDriver.

References

Hello Readers – this post will focus on a fairly simple example script touching on some more advanced concepts. The script simply requests a landing page, inputs the start & end dates and then clicks a button. Specifically, the script implements:

  • jQuery Datepicker randomized input
  • JavaScript evaluation within BrowserMob
  • using try… catch statements

Resources

jQuery Datepicker
jQuery Datepicker is a plugin based on the jQuery and jQuery UI both of which are hosted by the Google Libraries API – a content distribution network and loading architecture for the most popular, open-source JavaScript libraries.

Hello Testers – as many readers are probably aware, both Firefox\Firebug and Chrome have a console panel for evaluating JavaScript, testing XPath expressions / CSS selectors (i.e. inspecting the DOM), and analyzing the HTML. To learn more about the Console, check out the following:

Google: http://code.google.com/chrome/devtools/docs/console.html

Firebug: http://getfirebug.com/commandline

The syntax used for inspecting the DOM of XPath and CSS is slightly different.

XPath syntax: $x("")
CSS syntax: $$("")

Given the code block:

<div class="element-block"><a href="http://www.google.com/" class="code-block-link">Google</a> , <a href="http://www.amazon.com/" class="code-block-link">Amazon</a></div>

The HTML output is:

Some associated XPath and CSS selectors are:

For many years, Customers have come to us and have asked to load test everything from Active X controls, Java applets, Flash, you name it. Until recently though, this was always a monumental and sometimes impossible task to undertake with emulated browsers.

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:

The BrowserMob local validator is a great tool that helps you quickly and easily debug Selenium-based BrowserMob scripts right on your desktop. This article focuses on a couple quick tips to help you get Eclipse optimally configured for use with local validator.
Once you’ve downloaded the local validator and launched Eclipse, you can create an External Tools configuration to help you quickly launch your scripts with the click of a single button. From the Run menu, select External Tools and click on “New Configuration”:

new_configuration

Name the configuration and fill in the path to the local validator .bat file under “Location”:

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:

Setting up your load tests with a blend of RBUs and VUs can be ideal but it does depend on the type of scripts you are running.  Does your script require the user to fill out a form or does the site use AJAX? For those instances, RBUs work best. If your script is about browsing the site as a read-only, VUs work just as well; plus saves you money. VUs is simply HTTP and may be harder to script (but 1/10th the price!).

Hello Readers, Welcome Back !!

As the first part of this Selenium Tips series, this article intends to summarize the different ways to interact with dynamic sites that refresh content asynchronously wherein the script will have to wait for certain elements to appear or disappear before proceeding further. As you are already aware of, Selenium has several ‘waitFor’ commands that fulfill this purpose. waitForCondition is one among them. ‘waitForCondition’ basically takes in two arguments, a JavaScript snippet and a timeout period in milliseconds. The snippet is executed either until it returns true or until the timeout period, after which the command will return an error. Now enough of theory and let’s get into action.

© 2012 The BrowserMob Blog Suffusion theme by Sayontan Sinha