SOA Web Services Automation SOAPUI

Design SOA web services test automation framework to support multiple operating systems and web hosts with single driver script using SOAP UI.

This document outlines the automation plan of automation testing of SOA based web services with a single driver script to support various application hosted platforms, like Windows with JBOSS 5.1 (APP Server) , REDHAT (UNIX Host ) with Web Logic 4.0 (Web Server) , AIX (UNIX Host) with WAS 7.0 (Web Sphere) as my web application supported platforms.

Supporting Platforms

• Windows: JBOSS with SQL Server
• AIX: WAS (Web Sphere) with Oracle
• REDHAT: WEBLOGIC with Oracle
• Windows: WAS (Web Sphere) with SQL Server

Automation tool - SOAPUI

SOAPUI. This tool was developed in Java and provides mechanisms for functional and performance tests. From a valid Web Service Description Language (WSDL), the SOAPUI provides features to build automatically a suite of unit tests for each operation, and a mock service to simulate the web service under testing. Besides, this tool can be used for deploying the mocked service, and then, for making the WSDL interface available like the real service, but only the mocked functionalities are invoked.

Scripting languages: Groovy and VB.NET are built into Power Shell and is the only used part of the automation suite to prepare the test environment and copy the test resources from Windows to UNIX machines only.

• Groovy is a powerful scripting language with syntax very similar to Java. The major deference is that there is not exact declaration of the type of each variable but just a generic "def" declaration or with no declaration at all.
• Beginners look at http://groovy.codehaus.org/Getting+Started+Guide .
• The SOAP UI supports only two script languages, part of the automation "Groovy" and "JavaScript".
  

Note: How to change the selected Script Language "Groovy" to" JavaScript", the following setting needs to be done in the Project Properties as shown in the image above in the SOAP UI Functionality description of the Load Script (Groovy) Automation test suite.

Note: I don't want to show the complete code snippets about my driver script that comprises all the functionality as mentioned below because they do not fit in this article, but I will share by driver script that I have written in Groovy as attached with this article.



Test Automation Framework overview



How to set up the web services Automation Suite in a new machine:

A mistake users commonly do is, while designing the web services automation test suite using SOAP UI, to create the projects and test suites with imported WSDL URLs. I have tried, in the specific automation suite, to read the OSType as specified as one of the parameters in my configuration file and dynamically load all the projects and test suites using the driver script written in Groovy. This is the only supported scripting language in the SOAP UI.

The File Structure in the Web Services automation suite:

• Project Folders
• Contingency Plan
• Documents
• TestSuites
• Workspace file

AIX-WAS: contains all projects, test suites, test cases and utilities for AIX with WAS (Web Sphere) with Oracle and similarly RHEL for REDHAT with WEBLOGIC with Oracle, WIN-JBOSS for Windows with JBOSS with SQL Server and WIN-WAS for Windows with WAS (Web Sphere) with SQL Server.

Contingency Plan: Contains a copy of Test Suites, Template Files, workspace files, if anything has crashed or any file is deleted accidentally
Documents: necessary documentation of how to set up and run test cases
Test Suites: Contains all the test suites that are being used by all the projects
Workspace file: that contain the information about all the projects

Note: the SOAP UI stores all the project information files as named as a workspace and project files in XML format.

Set up the web services automation suite and also make it as simple as possible in my suite as mentioned below.

Step 1: Place the SOAPUI-TestFolder.zip or Test Resources folder as available in the Team Foundation Sever (TFS). Need to copy the local machines, either Windows or UNIX machines. Simply unzip and run them.

Step 2: Import thing the configuration file where I will fetch all the configuration parameters as named with server. properties file in ~\{Project}\Config\Server.properties

Step 3: Each time the user only needs the items to be updated in the Server. properties file

hostname_port (application URLs)

LDAP Credentials (Authorization credentials of user)
Machine_OR_FTP_UserLogin (Machine user name or FTP username)
Machine_OR_FTP_Password (Machine Password or FTP password)
(FTP username/password are to get access to non-Windows platforms, whereas Machine Username/Password are for Windows machines. For copying the test resources from Windows to UNIX machines using VB.NET code.)
OSType (Windows, Non-Windows)

Groovy Script Code Snippet to read the configuration files:

// define a array of configuration files used in automation suite

def propFileName =["ServerConfig","TestSuiteConfig"]

//Get the root path of project loction

context.BasePath = project.getPath()

// Change the folder paths to mapped the configuration file location – simply string in build functions

context.BasePath = context.BasePath.substring(0,context.BasePath.lastIndexOf('\\'))

//Processing ServerConfig, TestSuiteConfig

//************************************************************************

log.info "****************Project properties set up script called*********************"

//Below code read all the configuration files in project config folder and creates dictionary //with name and value pairs. Also attach these values to project global properties in SOAP UI

for(filename=0;filename<propFileName.size();filename++)

{

propFile = new File( context.BasePath + "\\Config\\"+ propFileName[filename] + ".properties" )

log.info "****Properties File to be loaded :: " + propFile

if(propFile.exists())

{

inStream = new java.io.FileInputStream(propFile)

def properties = new java.util.Properties()

properties.load(inStream)

log.info "Properties file has been loaded " + propFile

def names = []

names = properties.propertyNames()

while( names.hasMoreElements() )

{

def name = names.nextElement()

if(name=="hostname_port")

{

if(!com.eviware.soapui.model.propertyexpansion.PropertyExpansionUtils.globalProperties.hasProperty(name))

{

com.eviware.soapui.model.propertyexpansion.PropertyExpansionUtils.globalProperties.addProperty(name)

com.eviware.soapui.model.propertyexpansion.PropertyExpansionUtils.globalProperties.setPropertyValue(name,properties.getProperty(name))

log.info name + " property added in global properties"

}

else

{

log.info name + " property already exist under global properties"

com.eviware.soapui.model.propertyexpansion.PropertyExpansionUtils.globalProperties.setPropertyValue(name,properties.getProperty(name))

}

}

//Adding property to Project properties

else if(!project.hasProperty(name))

{

project.addProperty( name )

project.properties[name].value = properties.getProperty(name)

log.info name + " property added."

}

else if(project.hasProperty(name))

{

project.properties[name].value =""

project.properties[name].value = properties.getProperty(name)

log.info "Property " + name + " already exists, new value set to : " + project.properties[name].value

}

else

{

log.info name + " property already exists."

}

}

project.properties["CurrentDirectory"].value = context.BasePath

inStream.close()

}

else

{

log.info "properties file does not exist " + propFile

}

}

//*********************************************************

Screenshot of SOAPUI added global properties with load script location:



Test Automation hierarchy

Workspace is container for all projects:

Project: Project here is specific to the platform, in other words AIX with WAS , Win-JBOSS and so on
Test Suite: Test Suite is unit that can run independently without much manual intervention
Test Case: A test case is a collection of test steps
Test Step: A test step is an individual action performed by a web services method.

Workspace

Project 1
Test Suite 1
Test Case 1
Test Step 1
Test Step 2
.
.
Test Step n
Test Case 2
.
.
Test Case n
Test Suite 2
.
.
.
Test Suite n
Project 2
.
.
Project n