Thursday, July 4, 2013

Another Selenium system that incorporates GRID for parallel distribution of tests

System Components

The system is made up primarily of open source components as well as custom libraries written in Perl. The Selenium Standalone Server is the browser automation portion of the system. Selenium has been around since 2004 (although it was called JavaScript TestRunner then). It is a very stable browser automation platform, from our experience. It was chosen not only because of its stability and community support, but also because it supports ALL major browsers in use today; mainly Internet Explorer, Firefox, Chrome and Safari.

The test scripts and libraries are written using (as much as possible) the Page Object design pattern. This model gives us the capability of abstracting specific functions in a class and exposed as a method that can be accessed by the test scripts using wrapped function calls to the Selenium Perl Client Driver.

All html objects that the user (i.e. Test Script developer) will access are also abstracted and mapped to human readable names. This is a simple process that maps Selenium element names and locator strategy, for example the human readable “menu” “database_setup” will map to “mnuMain_DXI5_T” “ID” (element name, locator strategy) respectively.

As shown on the below diagram, we are using Selenium Grid to distribute our tests to different environments. Grid by itself does not support choosing a specific platform (i.e. you can tell it to use VISTA but you cannot specify architecture (e.g. x64), for example); we forked and modified the original code to support this functionality. Basically we are using a capability called applicationName to pinpoint the exact node we want to execute our test against.

Implementation

As shown on the below diagram, we are using Selenium Grid to distribute our tests to different environments. Grid by itself does not support choosing a specific platform (i.e. you can tell it to use VISTA but you cannot specify architecture (e.g. x64), for example); we forked and modified the original code to support this functionality. Basically we are using a capability called applicationName to pinpoint the exact node we want to execute our test against. See examples section for more details.

System Diagram









Automatically Executing the Scripts

There are many options for executing the test scripts. Which one is chosen will be determined by the specific project needs. The important thing to note is that these are Perl scripts that can be executed by any system that can run a Perl interpreter. Below are some of the options:
  • Windows task scheduler (Windows platform)
  • Windows Service Manager (Windows platform)
  • Cron scheduler (Linux platform)
  • Chron or Automator (MAC platforms)
To execute the scripts use any of the above tools to “Schedule” and “Run” at specific times the automated test suite.

Test Script Flow

When a test script is launched (either manually via command line or via one of the tools listed above) the following occurs:
  • Test Script requests a specific environment from the Grid’s hub (Browser, OS, Arch)
  • The hub checks for an available node that matches the desired capabilities
  • The node then executes the script, once a matching node is found
  • The script logic is designed to iterate through a list of browsers and platforms and execute the test against each, see here for an example.
  • After each the test run (i.e. all steps executed on all browsers and platforms), results are stored in the Automation Results Data Store. These results are then reflected in Quality Center’s Test Lab module
Quality Center Integration Module
Integration with Quality Center is accomplished using the HP Quality Center Open Test Architecture. OTA is a COM API exposed by Quality Center to facilitate integration with third party (from QC’s perspective) tools. It also enables developers to code custom applications to interface with QC. As an example the QCExplorer application uses the same API.

Let us know via email or comment any feedback you may have. As well, if you'd like for us to design a custom automated testing framework for Web or Client applications, please let us know.

1 comment:

  1. Very informative post. I've learned some. Thank you.

    ReplyDelete

Creative Commons License
VGP-Miami Web and Mobile Automation Blog by Alfred Vega is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.