OSAFS - The architecture

OSAFS uses a hybrid test automation approach. It has been built on Selenium RC. Components of OSAFS are:
• Global Configuration
• Test Scripts / Test Suite
• Execution Engine
• Reporting Engine
• Exception Handling

OSAFS Layers:

OSAFS Architecture:

Core of OSAFS framework is the Execution Engine. The engine consists of 6 main components:
1.Build.xml: starts the Selenium server and kick –start script execution.
2.OSAFS : is invoked by Build.xml which in turn calls XlateExcelToHtml and XlateHtmlToJava
3.XlateExcelToHtml: converts the test cases in the excel sheet to HTML scripts
4.XlateHtmlToJava: converts the HTML scripts to Java.
5.LogUtil.java (Error handler): When there is an exception it is recorded in “Error. log”
6.log4jConfig.properties : This file has the Config and display details for Error.log

OSAFS takes the input from user in form of Config, Test Cases and TestSuite. The execution engine internally invokes Build.xml to start the Selenium server and kick-start script execution. Error handler is invoked in cases of exception and the log file gets generated. At the end of the execution fairly standard and simple reports in html format are provided to the user

Open Source Automation framework for Selenium - OSAFS

Building an open source automation framework for Selenium would be a good challenge. Let's explore how we can go about designing and implementing a framework that uses a hybrid test automation approach. We shall employ Selenium RC to accomplish this. We can integrate Selenium RC with Test NG(-- a powerful, innovative, extensible, and flexible testing framework for test management) & ANT. We can do this so that we can inherit features from Test NG and Selenium RC.
Feature we can inherit from Test NG

  1. Ability to support both concurrent and sequential execution of scripts
  2. Test report generation
  3. JDK5 annotation support
  4. Flexible test configuration
  5. Data driven testing support with parameters

Hybrid automation framework

Hybrid test automation framework can be considered under fifth generation frameworks, where this framework is a combination of all of techniques, pulling from their strengths and trying to mitigate their weaknesses. This hybrid test automation framework is what most frameworks evolve into overtime and multiple projects
You can implement modularity by nesting test scripts and using the library files (or objects) to implement functions, procedures, or methods. You can implement whichever data-driven technique you choose and to the extent you find it useful. The trick is to use the best framework(s) for the job and the only way to figure that out is to jump in and start using them
Few advantages with this framework are Reusability, Common components handled by standard libraries, the details of the scripts are hidden from the user, and users don’t have to learn the script language to write scripts

Key word driven Automation framework

Keyword-based test automation framework can be categorized under fourth generation automation approach. It is a Software testing technique that separates much of the programming work from the actual test steps so that the test steps can be developed earlier and can often be maintained with only minor updates, even when the application or testing needs change significantly.
Keyword-driven testing and table-driven testing are interchangeable terms that refer to an application-independent automation framework. This framework requires the development of data tables and keywords, independent of the test automation tool used to execute them and the test script code that "drives" the application-under-test and the data.
Keyword-driven tests look very similar to manual test cases. In a keyword-driven test, the functionality of the application-under-test is documented in a table as well as in step-by-step instructions for each test.
When the software under test is changed, revisions to the test and to the automation scripts are necessary. By using a keyword-based framework, organizations can greatly reduce the amount of maintenance needed, and avoid rewriting entire test scripts. When there is changes made on the software the entire automation need not be changed, the existing automation can be modified by testers or business analysts. When required, changes to automated keywords can be completed by automation engineers without affecting the rest of the test, and can be swapped into other tests in the library as needed.


Powered by Blogger.


Total Pageviews

Copyright © T R I A G E D T E S T E R