SAP Performance Testing(Including volumes details)

The entry criteria for volume and stress in any SAP system are due to following reasons. • Increasing the number of users or adding new users • A major software upgrade like database or operating system migration • A major hardware upgrade like implementing BIA infrastructure for BW • Implementing a new module or new functionality like accessing through SAP Portal instead of SAP GUI The common concern which arises in minds of project team before any SAP application go live can be classified as follows. • How does the database react with existing or desired concurrent SAP users? • Will the implemented SAP application meet the end user performance requirements with respect to response time and throughput? • Is this SAP implemented solution scalable? • Will there be any dumps related to RFC connections and local printing hanging issues during production operation? • Can BIA infrastructure improve the performance of BIW queries? • Can specified number of CRM users create desired volume of tickets per hour? • Is this implemented solution capable of handling estimated production level transaction volumes within the available time frame? • Was the hardware sizing done accurately? • Are Application Servers and Database Servers configured accurately to withstand desired number of processes or requests? • Which component can fail for what time? • Which component of the system limits the number of concurrent users? In every volume test the engagement model begins in the following manner (refer Figure 1). • Request from Project Team: The request can be made in various ways like Service Request (SR), by email or phone call and sometimes project team member walking in with request for testing. • Initiate Kick off meeting: The testing team should initiate kickoff meeting to discuss and understand requirements. During this meeting the scope and objectives of testing should be defined. • Explain the strategy of testing to project team as per the requirement. • Create Service Request with a unique id. • Create the test plan. • Assign resources as per availability in pool and required skill set. Request from Project Team in the form of SR /email / Phone Call / Walk in Is request converted into SR? Testing team initiate Kick Off meeting to understand testing requirements. Scope and Objectives of testing defined. Strategy explained to Project team as per the requirements. Yes No Create SR Test Manager does the testing effort estimation and prepares the high level test plan. Sends to project team against the SR. No Resources allotted as per capacity plan. If the resources are not available in the testing pool then a request for the same is raised. Resource availability TAT 3-4 weeks. STOP YES START Project team and Test Mgr discuss the plan and agree Figure 1: Volume Testing Engagement Model/Framework 2. Effort Estimation To estimate an effort for volume testing is a key task. The effort can be measured based on 3 phases. Phase I: Script Design START Test Mgr/Lead as per the test plan doc identifies the business critical transactions and sends it across to scripting team. Scripting team identifies the protocol and complexity of the script. Test Mgr/Lead sends the delivery date of scripts to project team and execution team as per the input from scripting team. STOP Figure 2: Script Design According to Figure 2 the script complexity is measured by the scripting team. Effort involved is estimated based on this scripting. As a best practice, the scripting effort is designed using a formula keeping in mind the complexity level. Considering a medium complex script a script analyst can cover 1 script in 2 days. Hence the formula is # of Scripts * 2 = # of Man Days Note: This formula also considers script analyst skill in LoadRunner scripting. Phase II: Test Environment Design Test Mgr/ Lead based on test plan doc sends the test environment details to execution team and project Execution team prepares the test environment with help from IS Provider. The Injectors and SAP GUI client installed Test Mgr/ Lead sends confirmation mail to project team and execution team. START STOP Figure 3: Test Environment Design venture between execution team and IS Provider. Based on • SAP test environment: It includes identifying and creating a landscape similar to production • lves few • ner Infrastructure: The number of injectors to simulate or generate the load is • KEY_LOCAL_MACHINE\SOFTWARE\SAP\SAPGUI Front\SAP Frontend • Ena he scripting option can be enabled at server level by executing transaction “rz11”. Check for parameter “sapgui/user_scripting” and set it to ‘True’. Test environment setup is joint requirements captured in test plan document the environment is prepared. This involves setting up: environment consisting of Application Servers and Central Instance with Database. SAP test data: Load copy of production data in test environment. Data copying invo steps to be followed in order to be sure that the data copied is of equal size in the test environment. If we copy data to different environment, say production to QA, then it is normal backup from production and then restore in QA. And if we want to copy data to different platform (say Windows to UNIX) or different DB we need to use "r3load". This is a tool from SAP to import and export table during installation. In certain cases the data used should be confidential. As a result scrambled data is prepared using a third party tool called DSM (Data Sync Manager from EPI-USE). This tool is used to scramble and depersonalize data. LoadRun prepared based on number of concurrent users captured in test plan document. As a best practice in case of SAP R/3 50 virtual users can be simulated from a single injector with configuration of 512 MB RAM and 40 GB hard disk. With similar configuration as a best practice in case of SAP BIW 20 virtual user can be simulated from a single injector. To get better and consistent connectivity between LoadRunner controller and injectors, it is advisable to have same version of LoadRunner package and fix pack installed in controller and injector. Enable scripting at client: The scripting option should be enabled in SAP GUI client. If the scripting option is disabled the LoadRunner scripts can be neither created nor executed. In order to enable scripting at client level go to Run Æ regedit. Set the following parameter value to 1. o [H Server\Security] UserScripting = 1 ble scripting at server: T Pha specific execution plan is created considering all the activities involved uring execution. This master execution plan is captured in excel sheet with following worksheets: • consists of various types of execution scenarios to be executed during s arises. eck is found in • se III: Execution Phase Figure 4: Execution Phase During execution phase a d • Project Activities: This work sheet consists of details tasks or activities to be accomplished before and during execution. • Script Plan: This work sheet consists of all the scripts as per defined business critical scenarios. Scenarios: This work sheet the volume testing. These scenarios are captured initially in test plan document. • Injectors: This work sheet consists of all the injector details with IP address or machine name and location where they are installed. This list also consist of spare or backup injector • Systems and Monitoring: This work sheet consists of detailed information of Servers which will be monitored and parameters which will be considered for monitoring. • Stakeholders: This worksheet is replica of contacts info section in test plan document. This information helps to contact right person during execution if any problem • Test Log: This worksheet is updated by the execution team as a best practice to maintain a log of activities done during execution. For example during execution if any bottlen application server then extra application server is added and again tested. This kind of details should be captured in test log which during final reporting helps to prepare a good report. Actions Issues: Any action items to be taken care by stakeholders or issues encountered during any phase of volume testing are registered in this worksheet. Execution Team executes the test. Encounter Bottlenecks Yes Bottleneck details sent to Project team. An further executio ns y Test Manager/Lead sends the consolidated report j Document the necessary parameter changes required. No Make the necessary parameter changes. Yes START No STOP • Lessons Learnt: The captured data from lessons learnt are documented in SAP Volume Testing Best Practices for future reference.