Hello Testers – First, I have to admit that I am not a Flex/Flash developer and cannot take credit for the following content. This was produced by my colleague and fellow BrowserMob blogger, Anu. It is documented internally but I believe the BrowserMob community will find value so I scrubbed it and published it.

Overview

Traditionally, testing Flex/Flash applications was difficult because the logic/behavior is encapsulated from the browser. With the introduction of Flex 3.x,  came the release of the Adobe Automation Framework; and Gorilla Logic developed a lightweight testing application called FlexMonkey. In conjunction, a Selenium plugin was created – FlexMonkium. Now Flex recording and playback are seamlessly interleaved with native Selenium recording and playback so you can easily automate the testing of hybrid web applications that mix HTML and Javascript with Flex.

Hello Testers – recently there was an inquiry looking for an example using the try... catch... statement for error handling.

The first example that came to mind was handling of interstitial pages. These are often full page advertisements that are randomly and temporarily displayed to the user before redirecting to the originally requested page. The intent of the script is to login but it needs to handle the exception when the page under test does not contain the expected HTML element.

If the script attempts to click on an element not contained within the DOM (a “continue” link) a Selenium runtime exception kills the test case:

The Eventually Consistent developer blog reports that after researching on-demand load testing tools, EC loves BrowserMob best. Why? (1) The ability to upload Selenium and run real browsers against your site, (2) real-time reports showing response times/server errors and (3) the downloadable database which lets you run your own queries and analyze them in numerous ways. EC said BrowserMob was “the best way for us, a small shop, to learn about how our site performs.”  Thanks EC and glad we could help.  Read the full post.

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.

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:

As you may have seen, we announced some exciting news today: Neustar’s BrowserMob Load Testing and FriendRunner have joined forces. With these platforms combined, developers will be better able to test Facebook applications and ensure they are ready for viral deployment before launching them publicly to the Facebook community.

So why did we form this relationship? Well, Facebook’s unique architecture makes it more challenging to perform traditional load testing. However, with this solution, application developers can run load tests easily and efficiently, all while staying within budget.

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.

dynaTrace just posted a really nice tutorial showing how to track client-side performance (JavaScript, DOM, render times, etc) automatically using Selenium. They do this by using their super-cool free AJAX edition of their product.

We’re a few weeks late to the story, but we think it’s still important to call attention to: Watir and Selenium are joining forces. For those unfamiliar with Watir or Selenium, both of them are open source browser automation frameworks. For years they have been “competing” in the open source community, with Watir winning favor among the Ruby community and those who needed strong IE support, while Selenium won favor among the Java and C# crowds and those who really valued cross-browser support.

© 2012 The BrowserMob Blog Suffusion theme by Sayontan Sinha