10 Steps to SAP Performance Testing

Denis Sautin

Author

Denis Sautin

Denis Sautin is an experienced Product Marketing Specialist at PFLB. He focuses on understanding customer needs to ensure PFLB’s offerings resonate with you. Denis closely collaborates with product, engineering, and sales teams to provide you with the best experience through content, our solutions, and your personal journey on our website.

Product Marketing Specialist

Reviewed by Boris Seleznev

Reviewed by

Boris Seleznev

Boris Seleznev is a seasoned performance engineer with over 10 years of experience in the field. Throughout his career, he has successfully delivered more than 200 load testing projects, both as an engineer and in managerial roles. Currently, Boris serves as the Professional Services Director at PFLB, where he leads a team of 150 skilled performance engineers.

Performance testing is an important stage of software quality assurance. There is no better way to check your software code reliability, locate system bottlenecks, and eliminate failures. These bottlenecks can occur across various business-critical systems, from enterprise applications like SAP to customer-facing infrastructure such as call centers where IVR performance testing becomes essential during high-volume periods. One of the main goals of testing is to check whether the system as a whole or its individual modules meet the customer’s expectations.

SAP performance testing service is required when the system is only being launched to mitigate the risks. It is also a must when the system has already been installed and is working, but any kind of problems occur. Another good idea is to do the testing when modifying SAP modules.

If your or your customer’s company relies on SAP load testing, at a certain point, your QA team will ask themselves how to test it. We broke the process of SAP performance testing into 10 steps so that you (or they) could use it as a checklist. Read further, and you’ll have your roadmap.

Key Takeaways:

1. Develop SAP Performance Testing Methodology

Your methodology should contain the key elements of the testing process: load scripts, profiles, descriptions of test and production environments, target metrics and indicators, goals and objectives, as well as testing limitations. An important point is to confirm the performance testing methodology with the customer. Without having done that, don’t even start: business goals can be very different from how you see them. 

A well-developed methodology can save you loads of time, as well as ensure transparency and predictability of the result.

2. Request Roles

To write scripts, depending on the functional responsibilities, users should be assigned certain system roles. Those have to cover all business operations presented in the scripts. Store the registry of all used roles in a quickly accessible file. Questions about maintaining the register should be discussed with the customer and/or an appointed responsible person. Verification of credentials in the SAP system is carried out in 2 stages:

To analyze the missing permissions, it is necessary to type transaction SU53 in the transaction launch field.

If you use different user accounts to write scripts and to feed the load, make sure they have the same rights.

3. Develop Scripts

One of the most popular tools for automated stress testing of SAP is LoadRunner. You can read our guide on how to use it for SAP testing. LoadRunner consists of the following applications: Virtual User Generator, or VuGen (used to develop load scripts), Load Generator (used to generate virtual users), Controller (used to develop and run load scenarios), and Analysis (used to analyze the results of load testing).

3.1. What is SAP GUI

SAP GUI is the graphical user interface client in SAP ERP’s 3-tier architecture of database, application server, and client. This software allows users to access SAP functionality in SAP applications, such as SAP ERP and SAP Business Information Warehouse (BW). It is used for remote access to the SAP central server in a company network. There are versions of SAP GUI available for download to work in Windows or MacOS, as well as a version for the Web. The latest version of SAP GUI for Windows is 7.70, but 7.60 is also supported.

Before testing, you’d better update your SAPGUI release version. Don’t worry: it is backward compatible, so it does not matter if you had SAP GUI release version 7.60, 7.50, or even version 7.40.

3.2. Testing SAP GUI

To test a SAPGUI user running only on the client, use the SAP GUI Vuser type. To test a SAP GUI user using a web browser, use the SAP-Web protocol. To record an SAP GUI session using browser controls, create a multiprotocol Vuser script with SAP GUI and SAP-Web protocols. This allows VuGen to record Internet-specific functions when working with browser controls. However, this won’t work if you try to combine SAP GUI with web protocols different from SAP-Web. Before recording, make sure that your modules and client interfaces are supported in VuGen.

The SAPGUI script usually contains several SAP transactions that make up the business process. A business process consists of functions that emulate user actions.

4. Work with Consultants

When recording the script, interact with consultants on the customer’s side: it is necessary that they give you data about business operations. Since there are a lot of modules in SAP, and a single person cannot know them all, there will be different consultants for each module. You should request the contact details of all consultants with specifications on which module they are responsible for.

Otherwise, hire a specialized vendor to outsource all necessary communication and responsibility. Choose wisely: PFLB has wide expertise with SAP performance testing services and will save you time and money.

💡 Read Our Case Studies:
– SAP ERP Load Testing for a Retail Company ->
– SAP BW Comparative Load Testing (Oracle vs SAP HANA vs EXADATA) ->
– SAP ERP Load Testing for a Major Meat Producer ->

5. Debug SAPGUI Scripts

The following steps are necessary to debug and rerun SAP GUI scripts.

5.1. Replace the disguised password in the sapgui_logon function generated during recording with a real password. This is the second argument in the function after the user name.

sapgui_logon("user", "pswd", "800", "EN");

5.2. Display SAP GUI during the test. When you run the script for the first time, configure VuGen to display the SAP GUI user interface to see the operations performed through it. Select Replay > Runtime Settings > SAPGUI > General, and select Show SAP Client During Replay. During the load test, disable this option, as it uses a large amount of system resources when displaying the user interface for multiple Vusers.

5.3. Perform data correlation and parameterization. Consider using TAFObjectSpy as a utility for debugging the script.  The main purpose of the tool is to define the Uniform Resource Identifier (URI) of the user interface control element. It can access SAP GUI and SAP-Web sessions. The program allows you to track the user interface controls of the application under test and generates a URI for you.

6. Generate Data for SAPGUI Scripts

If there is not enough data in the script for any of the business operations, you will need to use “Action” to generate the necessary data. This way, the script can be executed an unlimited number of times, using different data each time.

7. Run SAPGUI Scripts via VuGen

Run the script via VuGen to check if it works. If the script works without errors, then you can proceed to the next step. If there are errors, you can see them in the Output. To increase efficiency, increase the number of iterations in Runtime Settings > Run Logic and select Number of iterations bigger than 1.

8. Run SAP GUI scripts via controller

To run scripts correctly through the controller, you need to perform the following steps:

1. In Runtime Settings > SAPGUI > General, uncheck Show SAP Client During Replay.
2. In Runtime Settings > Think Time, select Use random percentage of recorded think time, as well as Limit think time to 1 second.
3. During the test run of the script, enable logging so that it would be easier to detect the errors later. To do so, in Runtime Settings >Log check Enable logging. For even more information, you can enable Extended log. If you do not need the full log, you can leave only the log with the errors checked: Log when an error occurs and log cache limit to 1 KB.
4. Check if the option to ignore errors is on. In Runtime Settings > Miscellaneous, uncheck the Continue on error option.
5. Select the load generator on which you will run the script.
6. Configure the script according to the regulations described below in point 10.

9. Acceptance Procedure

After completing all of the above, send the script to the customer or your manager for verification. They check the script’s functional capacity through the controller. After checking the script and auditing the code, your customer or manager accepts the script or handles it back to correct errors.

10. SAP Performance Testing Algorithm

After all scripts have been accepted, it’s finally time for performance testing. Below, you can see an approximate algorithm.

• The start of each next script in the scenario is in N minutes after the start of the previous one.
• Initialization of each virtual user is right before its launch.
• Delay of M minutes before the start of each script is necessary.
• Run the script at the rate of increasing the load of K users every L seconds until it reaches the value of O vusers.
• Further operation of the test takes Q time.
• Delay of 1 minute after completion of each script execution is necessary.

Conclusions

If you’re using SAP, perform continuous load and performance testing to ensure that your software meets performance, capacity, and usage requirements. This approach is equally important for other enterprise systems, as demonstrated in our transaction processing system load testing case study, where rigorous testing ensured optimal performance for high-volume financial operations. If you need any help, PFLB engineers would be the right fit: we have a lot of experience with customers who rely on SAP and have probably found solutions to problems similar to yours in their 300+ previous projects. Drop us a line!