image

Load Testing

Building Resilient Cloud Load Tests for SAP Fiori

Editor’s note: This article was originally published by Jason Rizio on the Flood blog.

Tricentis is a sponsor of SAP Sapphire May 7-9, 2019.  If you’ll be there, please stop by and visit our booth for exciting information on cloud load testing for your SAP Fiori instance!

Why Load Test SAP Fiori?

SAP Fiori is generally viewed as a fairly complex web application that can be customised extensively. With this level of available customization there is a substantial amount of complexity with respect to user interface objects and how their properties change when these modifications are carried out.

UI objects can be dynamically inserted to add functionality to the interface depending on business and functional requirements. These functionality changes can break your existing automated test cases requiring you to investigate the issue and update scripting steps accordingly.  Load Testing SAP (especially Fiori) from the cloud should be a top priority .

Why Use Browser Level Load Testing for SAP Fiori?

Browser Level Load Testing is an innovative solution when testing web applications like SAP Fiori.  Cloud ready, browser based load testing tools like Element will provide:

  • Simpler scripting, without the need for complex correlation
  • Reduced maintenance and easier script updates
  • More realistic load coming from real browsers
  • True measurement of the application responsiveness as users would see it

This post will explain how you can make your automated test cases more resilient to changes using an advanced browser-level load test tool such as Flood Element.

Challenges when using Browser Based Load Testing for SAP Fiori

When using a Browser level load test tool in general – the most common challenge is figuring out which of an object’s properties are the most effective and reliable to use. Software applications like SAP Fiori will tend to change with updates to the application code as well as changes to UI components. As mentioned previously – any changes to the UI may include adding/removal of buttons for example – each of these components tend to have an ID value containing a numerical order as part of their attributes. This order can change if other grouped objects are added/removed so it’s not a good idea to use these ID’s for object identification.

A better use of an object’s identification are attributes that are less likely to change if other components are added onto the interface. Any label-based attributes such as a button that allows you to Create a Purchase Order and that has a label property called ‘btnCreatePO’.  In general, this specific property name will generally only be tied to this button. This is an example of an effective and stable property to use.

Another challenge for object identification is that some objects are nested within multiple levels of <DIV> or <TABLE> tags – this usually causes the object identification string to be very long and virtually unreadable. An example of this is observed here:

let linkNewAccount = await browser.findElement(By.xpath('//*[@id="brandBand_1"]/div/div[1]/div[2]/div/div/div[1]/div[1]/div[2]/ul/li[1]/a'))

As you can see the number of div tags in this object identification string is numerous and very specific – if changes to any of the these div tags are made then this script step will more than likely fail when the script is run again.

A More Robust Approach to Browser Level Load Testing

The aim of our scripting is to create a resilient, easy to maintain scenario that can be repeatedly run as a cloud load test even when our SAP Fiori instance sees UI changes frequently.  A much more reliable and elegant object identification string is shown below:

let selIssueType = await browser.findElement(By.xpath("//input[contains(@id, 'issuetype-field')]"))

The usage of the `contains` method cuts down on the use of long and complex strings while targeting the specific nested object we want to interact with. We simply use the object property (in this case the `id` property) along with the property value.

SAP Fiori specifically has the main home screen presented into different tiles for each area. These tiles have an order that can be changed if there are additional tiles being added. We can utilise a method as per below to ensure any changes to these tiles will still enable our script to function correctly:

let tileEmployeeLookup = By.xpath("//div[contains(@title, 'Employee Lookup')]")

In this case we are looking for a tile that contains the title Employee Lookup since every tile has a title property this should make our script resistant to changes made on this screen.

We can also take advantage of the partialVisibleText method when identifying SAP objects – as follows:

let tileEmployeeLookup = By.partialVisibleText('Employee Lookup')

This can be an alternative to using the `contains` method above however it’s usage needs to be carefully implemented as the text ‘Employee Lookup’ text needs to be the only instance of it’s value on the current application screen.

Taking Your Load Test to the Cloud

Once you have your script created, you can upload it to Flood to execute it with 100’s or 1,000’s of concurrent users and try your hand at load testing your SAP Fiori platform. The free trial will provide you with enough node hours to execute this test outlined here for 1 hour with roughly 50 concurrent users.

If you are load testing against SAP Fiori, we’d love to hear from you. Drop us a note and share any ideas that are working for you and feel free to ask our team any of your tough questions