Why SAP performance testing?
Applications that have the right performance level will enable users to complete transactions quickly, which will speed up business operations during peak performance.
Performance testing for SAP will reduce the risk of the business processes to not perform as per the non-functional requirements. It will provide insights into the time behavior, resource utilization and capacity of SAP applications and the business processes they support.
Examples of tools for performance testing are:
- Tricentis NeoLoad
- LoadRunner
- JMeter
- And many more
Types of performance testing
Load Testing: used for exercising the system to perform the various expected loads on a component level as well as an end-user level. On a component level, performance testing will test for conforming to basic performance requirements (database transactions per second, API-calls per second etc.). At the end user level, the performance in a real-life situation with users “hitting” the system from all possible interfaces in real life is tested (mobile/ web/ workstation etc.).
Stress Testing: this aims at going beyond the regular load expectations/ requirements. This may vary from looking ahead to an expected increase in load over the months or years to aiming for the system to break (in order to test failover/ restore processes).
Endurance Testing: this is used to determine whether the system can sustain continuous expected load. Duration can be for example from 8 hours to 2 weeks for the endurance test. One of the purposes of an endurance test is to identify memory leaks.
Volume Testing: a volume test is executed with a huge volume of data in an SAP performance test environment to identify and validate the performance with realistic data volumes.
Common issues in SAP performance testing
Test Data: To execute performance testing, large quantities of test data are required. The data are used multiple times. Testers need to make sure test data does not expire after one iteration. In SAP, test scenarios are executed with master data (like Material Master, Business Partner master) and transaction data (like Purchase Requisition, Purchase Order, Invoice etc.), so creating large numbers (1000 transactions = 1000 Purchase Requisitions, 1000 Purchase Orders, 1000 Invoices) may be a very difficult and time-consuming process.
Real-time performance environment: Performance testing should be executed in a production-like environment. Performance metrics like number of users, number of transactions, response time are derived based on the production environment. However, performance tests are commonly executed in non-production environments which often have a lower capacity than the production environment. This means the results of the performance tests may not be 100% accurate.
Project Stakeholders: Many of the project stakeholders (Business Team, Infrastructure Team, Basis Team) are not aware of the importance of performance testing.