Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
former_member283187
Discoverer
0 Kudos
SAP is evolving and has decided to have a uniform web based UI across all its products. Webide along with UI5 has emerged as an important tool for developing UI applications. But doing UI automations for these apps is very tough because of its UI constraints during rendering of these apps as html code. Even if user is able to complete the automations using selenium and Testng framework, running/managing such automation test cases is very difficult as the test cases has to run either manually or give the file name in testing xml and run them. By default, the Testng automation run with parallel feature as disabled. When the test scripts execute they take a lot of time as they execute one after another and often manual intervention is need when the number of test scripts is very huge.

The user can enable this feature but the test automation script should be designed in such a way that the running the automation in parallel mode should not impact normal functionality of script execution.

Parallel parameter in Testng xml

Parallel attribute is passed along with <suite> tag in Testng xml of that test suite.

Types of parallel execution:

  1. Methods – It is used to run test methods in parallelly.

  2. Classes – It is used to run all methods in same class in script parallelly

  3. Tests – It used to run all methods in same <test> tag parallelly.

  4. Instances – It used to run all methods in same instance in one thread. Methods belonging to other instances should run in separate thread.


Along with this we pass the thread-count attribute too. This parameter will control the number of threads that run parallelly. It is a very important parameter and need to adjusted as per number of components (tests/methods/classes/instances) running parallelly.

Key points before changing parallel parameters

  • The test scripts should be independent of each other such that failure of one script should not hamper functionality of other scripts.

  • The test scripts should avoid using unnecessary global variables. Only the static data should be kept in global variable.

  • Custom report generation should be done for every script so that when things execute parallelly, all the logs and errors are included in proper order in report.

  • Kill the drivers/instances of scripts when execution finishes as it will help to reduce load on memory when a huge number of scripts are running in parallel.


Sample Testng XML

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">

<suite name="UI Automation" parallel="classes" thread-count="2">

<test name="Scripts" >

<classes>

<class name="Test1"/>

 

<class name="Test2"/>

 

</classes>

</test><!-- Test -->

</suite> <!-- Suite -->

 

Test script Sample

The test script should be written such that if we execute that single script alone, it should execute normally without any issues. This will ensure that when scripts run parallelly as part of single test suite they don’t interfere or interact with one another.

Test1.java

package testsuite;

import org.apache.commons.lang3.exception.ExceptionUtils;

import org.testng.ITestContext;

import org.testng.annotations.AfterClass;

import org.testng.annotations.BeforeClass;

import org.testng.annotations.Test;

import org.testng.asserts.SoftAssert;

 

public class Test1 {

 

@BeforeClass

public void setUp(ITestContext ctx) throws Exception

{

//prereq variable initialize

// driver calls and loading

//load UI

}

 

@Test

public void functionTest() throws Exception

{                   s_assert=new SoftAssert();

try

{

//write your test scenario here

//log success steps to report

}

catch(Exception e)

{      //log error in report

}

 

s_assert.assertAll();

 

 

}

 

@AfterClass

public void tearDown() throws Exception {

try {

//clear all variables

//kill all driver instances  running and finalize entry in report

} catch (Exception e) { //log error is killing instances    }

finally { //any final steps to be execute after test finishes like sending mail/notification/logging the status in any db

}

}

 

}

 

Similar to steps shown above, develop all scripts and add them to Testng xml.

Keys points to considered when writing scripts

  • Keep the test scripts as short as possible and try to have only one scenario per script. This will make debugging of scripts easier.

  • Also, if anything fails, then we can focus only on failed scripts and re-execute them.

  • For regression feature testing, writing test scripts in above way will really help as we can pick and choose scenarios easily and execute them independently.


Test Suite Grouping

During regression testing, grouping test suites will help to maintain a track of regression features and prevent manual intervention. Also, it will help in periodic running of suites as part of Jenkins job.

Example:

RegressionSuite1.xml

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">

<suite name="Regression suite 1" parallel="classes" thread-count="2">

<test name="Scripts1" >

<classes>

<class name="Test1"/>

 

<class name="Test2"/>

 

</classes>

</test><!-- Test -->

</suite> <!-- Suite -->

 

RegressionSuite2.xml

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">

<suite name="Regression suite 2" parallel="classes" thread-count="2">

<test name="Scripts2" >

<classes>

<class name="Test3"/>

 

<class name="Test4"/>

 

</classes>

</test><!-- Test -->

</suite> <!-- Suite -->

 

FinalSuite.xml

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">

<suite name="All Suites" verbose="10" parallel="none" >

<suite-files>

<suite-file path="RegressionSuite1.xml" />

<suite-file path="RegressionSuite2.xml" />

 

</suite-files>

</suite>

Now the user can trigger this final master suite and it will take care of all other suite execution along with separate setting specified in each individual suite.This master suite can be triggered using a Jenkins job.

For more details, you may refer http://testng.org/doc/documentation-main.html

 

Happy Testing