Web Browser Automation is a process where certain steps in the web browser are performed repetitively to ensure the correct operation of the web application’s functionality. It may be applied for QA testing in the development process and for control over Information System accessibility and performance during implementation. The second becomes more and more important since current market trends indicate that just having a good service is not enough; the service should also be highly accessible and effective. With Web Browser Automation Tools it is possible to check accessibility and performance by periodically running some transaction scenarios for certain services.
|Tool||Simulation||Supported Browsers||Supported Languages||Test Recorder|
|Selenium||No||Firefox, IE(partially), Opera (partially), Chrome (partially)||C#, Java, Perl, PHP, Python, Ruby||Yes|
|Watij||No||On Windows only IE, On Linux only Firefox,
On Mac only Safari
|Watir||No||On Windows only IE, Watir Web Driver -IE/FF/Chrome/Safari||Ruby||Yes|
|Watin||No||IE, Chrome, Firefox||.net platform languages||Yes|
|Tool||Num. of tests||Browsers||App run duration||Num. of threads||Test frequency (min)||Transaction step count||Num. of tests running during 20 mins||Avg. exec time for 1 test (sec)|
As you can see, the test results for Selenium with IE browser are absent. The problem was that the Selenium couldn’t run several transaction tests at the same time. Instead of opening several browser instances, it mixes all of them in one browser instance. However, it doesn’t have this kind of problem when working with Firefox or Chrome. For example, running the Selenium with the same conditions but on the Firefox browser, the following results were obtained: average execution time of 1 test is 15.1 seconds, the number of tests run during 20 minutes is 50. The average running time of one transaction test for these tools is not greater than that of the others. The other 2 tools spent a substantial amount of overhead time communicating with the server, starting browser instances, etc.
Examining the performance of selected Web Automation Tools shows that they differ not only in terms of functionality, but that they also behave differently in different conditions (depending on OS, browser type, multithread or singlethread). The main limitation we noticed with Selenium is that it’s primarily designed for Firefox. All of its products support Firefox, and as we have already seen it has problems working with IE. On the other hand the Casperjs is headless and is Webkit based, so it will not work on IE only sites, for example. Meanwhile, Watij works with only one unique browser type per OS (IE on Windows, Firefox on Linux and Safari on Mac). Working with different transaction scenarios simultaneously is much more productive with the headless tools since they consume less time.