Web-based Automation Framework

Introduction

The automation framework that I am mentioning here is itself a web based application built on MVC (Model-View-Controller) concept using Java, Springboot, Thymeleaf and Selenium WebDriver. Test Cases are stored in Oracle database.

Key components and the folder structure of this framework are as follows

  • org.myorganisation.automation.config This package contains the required configurations including main class of the application and the database configurations and beans.
  • org. myorganisation.automation.config.controller This package contains the web controllers. Automation Controller handles all the required Request Mappings for the automation framework. Error controller handles any exception or error in the application.
  • org.myorganisation.automation.config.controller  This package contains exception handler, which helps to handle any kind of exception within the application and show an error page accordingly.
  • org.myorganisation.automation.constants This package contains the Constants classes for application as well as Database Queries. All the variables used in the constants classes are static.
  • org.myorganisation.automation.dao This is the interface layer of Database operations.
  • org.myorganisation.automation.dao.impl This contains the implementation of the database operations.
  • org.myorganisation.automation.dao.jdbc This contains the required Database connections configurations and related details.
  • org.myorganisation.automation.domain This package contains the domain classes of different objects used in the automation application
  • org.myorganisation.automation.pageObjects This package contains the XPATHs of the web page elements, which helps Selenium Webdriver to identify web page elements.
  • org.myorganisation.automation.service  This contains the interfaces of different automation services.
  • org.myorganisation.automation.service.impl  This package has all the automation service implementations.
  • org. myorganisation.automation.testCases This package contains the test cases. The name of the test case methods are same as Database Test Case Names. This methods helps to identify the sequence of the service operations to complete the test case execution.
  • org. myorganisation.automation.utils This package contains the utility classes required for the automation application flow.

Firstly, a new maven project was created (Select simple Project without Archetype).  From ‘New Maven Project’ window name Group Id and Artifact Id was selected to create the package as GroupId.ArtifactId. Secondly, Updated the POM file inserting all the dependencies. All dependency jar were included by Right Click On the Project -> Maven -> UpdateProject

Implementation of this framework can be explained briefly by mentioning user navigation via the automation app. The Application started with providing a login page. Used Http session object for each user. Created an authenticate method in Common Service. Controller has the following method with Request Mapping annotation (Fig.1)

Fig. 1 Authenticate function in Controller

Once successfully logged in, user is presented with the available applications/streams within Test Automation. Clicking on any of the sections will expand the options, and user will then be given the option to select required functionality and Test Environment.  After selecting test environment from the previous screen, the user will be presented with the list of Test Cases defined by the Test Automation Team for execution. Please note, all the Test Cases and Test Data are stored in oracle database. Test Data are propagated across the application using DAO object. Automation application page layout and CSS design are imported from Foundation and Company used CSS.

 

Brief Database design for Test Cases

Main two tables of each environment are Test Case Data table and Test Case MAP table. MAP to DATA table is created with 1 to M relationship with Test Case ID is the Primary Key for the MAP table and Foreign Key for the Data table. MAP table consists of Test Case name, region, type, qualifier, description etc necessary columns and Data table consists of field name and field values. Apart from these two tables, I used Test Case Execution Log table and User details table for each environment.

Technical Overview

Suppose the user need to find Regression Suit for QA environment.  After login, user will be given option to click on Regression link. HTML page was written as “regressionHome.Html” and placed it in templates folder.  Part of regressionHome html snap (Fig. 2) is as follows

Fig. 2 Part of regressionHome html

Now, if in one instance, user clicks on the ‘QUOTE’ button, showRegTestCases javaScript function (Fig. 3) will be called, URL (/automation/tcListReg/subfunction) will be navigated and the controller function tcListReg will be executed (Fig. 4)

Fig.3 JS function to communicate between Server and View
Fig. 4 tcListReg function from the Controller

Test Data are retrieved and returned by following two functions written in Test Management package and Automation Dao package as shown in following two screen dump (Fig 5 and Fig 6)

Fig. 5 getTCListReg from Test Management package
Fig. 6 Data Retrieve function from automationDao package

Returned list will be added to the REGRESSION_TC_LIST_PAGE (there is a html page in the template folder)

Execute Test Cases

Suppose user is going to execute a regression test case from a section called Manage from QA suit.

Test Case are written on Test Case package as shown in Fig. 7 below

Fig. 7 Test Cases Example

Manage Services are implemented to execute test cases. Code snippet below in Fig. 8

Fig. 8 Functions in Manage Services

Please note Interfaces are defined for all Services and Page Objects are defined in separate classes of separate packages.

Note :This is just brief technical note, please email me your opinion or  if you seek further explanation for any section discussed here , thanks