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.
