Performance testing is an important stage of software quality assurance. There is no better way to check your software code reliability, locate bottlenecks in the system and eliminate any errors. 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 is required when the system is only being launched, in order 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 or organization relies on SAP, 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.
Table of Contents
3.1. What is SAP GUI
3.2. Testing SAP GUI
Looking for performance and load testing provider?
Drop us a line. Most likely, we have already dealt with problems like yours in the previous 300 projects.
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.
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:
1. checking for the start of transactions;
2. checking for permissions for certain actions with an object (viewing, creating, deleting, changing, etc.) in a transaction.
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.
One of the most popular tools for automated load 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).
SAP GUI is the graphical user interface client in SAP ERP’s 3-tier architecture of database, application server and client. This software allows a user 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 Web. The latest version of SAPGUI for Windows is 7.70, but 7.60 is still supported, too.
Before testing, you’d better update your SAPGUI release version. Don’t worry: it is backwards compatible, so it does not matter if you had SAP GUI release version 7.60, 7.50, or even version 7.40.
To test a SAPGUI user running only on the client, use the SAP GUI Vuser type. To test a SAP GUI user who also uses 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.
Don’t want to run tests by yourself?
There is no better place for a QA solution than PFLB.
Drop us a line to find out what our team can do for you.
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 contact details of all consultants with specifications of which module they are responsible for.
Otherwise, hire a QA contractor to outsource all necessary communication and responsibility to them. Choose wisely: our 400+ performance testing engineers have wide expertise with SAP performance testing and will save your time and money.
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.
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.
Want to avoid performance testing mistakes?
Just hand it over to us. There is no better place for a QA solution than PFLB.
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.
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 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.
After completing all of the above, handle 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.
After all scripts have been accepted, it’s finally time for performance testing. Below, you can see an approximate algorithm.
If you’re using SAP, perform continuous load and performance testing to ensure that your software meets performance, capacity, and usage requirements. If you need any help, PFLB engineers would be the right fit: we have large 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!