The document provides information on performance testing processes and tools. It outlines 8 key steps: 1) create scripts, 2) create test scenarios, 3) execute load testing, 4) analyze results, 5) test reporting, 6) performance tuning, 7) communication planning, and 8) troubleshooting. It also discusses tools like LoadRunner, Controller, and Analysis for executing and analyzing tests. The document emphasizes having a thorough test process and communication plan to ensure performance testing is done correctly.

3. Click OK button to proceed with the installation of missing prerequisites. If you already
have .net framework 4.0 or above, you’ll not see this screen, rather the setup will show a
splash screen for a moment till it calculates space requirements. Refer below for a snapshot.

14. Business
Process
Total
Users
(%)
Avg Number
of concurrent
users
Peak number
of concurrent
users
Preferred
Response
Time (Total,
including
think time)
Unacceptable
Response
Time (Total ,
including
think time)
Browse 20% 100 2000 2-3 min > 5 min
Time Entry 60% 200 6000 3 min > 5 min
Update
personal
info.
20% 50 1000 1 min > 3 min
Total 100% 350 9000

15. Business
Process
Total
Users
(%)
Peak
Time
Peak
Load
(# of
users)
Preferred
Response Time
(Each transaction)
Unacceptable
Response Time
(Each transaction)
Create
Order
20% 4-6 pm 1000 3-5 sec > 8 sec
Browse
Catalog
60% 4-6 pm 6000 3-5 sec > 8 sec
Display
order
20% 4-6 pm 1000 3-5 sec > 8 sec
Total 100% 8000

16.  It is the traffic model of the application
 The better the documentation of the business processes,
the better the test scripts and scenarios.
 Save time on script and scenario creation
 Good business profile can make it possible to reuse
existing load testing scripts and results later.
- Business Profile is the basis for load testing

17. 2. Create Scripts
- Automate business processes in LoadRunner VUGen (Virtual User
Generator):
Scripts are C, C++-like code
Scripts are different with different protocol/technology
LoadRunner has about 50 protocols, including WAP
- Record user actions
Need assistance of SME/Functional Testing group
- Add programming and test data in the scripts
- E.g. add correlation to handle dynamic data, e.g. session id
- Test data may need lot of work from project team

18.  web_submit_data("logon.sap",
 "Action=http://watstwscrm02:50000/bd/logon.sap",
 "Method=POST",
 "RecContentType=text/html",
 "Referer=http://watstwscrm02:50000/bd/startEBPP.sap",
 "Snapshot=t3.inf",
 "Mode=HTML",
 ITEMDATA,
 "Name=login_submit", "Value=true", ENDITEM,
 "Name=j_authscheme", "Value=default", ENDITEM,
 "Name=j_alias", "Value={UserName}", ENDITEM,
 "Name=j_password", "Value=coffee@2", ENDITEM,
 "Name=j_language", "Value=EN", ENDITEM,
 "Name=AgreeTerms", "Value=on", ENDITEM,
 "Name=Login", "Value=Log on", ENDITEM,
 LAST);

19. 3. Create Test Scenario
- Build test scenario according to usage information in Business
Profile
- Load Calculation
- Can use rendezvous point, IP Spoofing, etc.
- Run-Time setting
 Think time
 Pacing
 Browser Emulation: simulate browser cache, new user each iteration
 Browser version, bandwidth, etc.

20. 4. Execute Load Testing
• Execute test scenarios with automated test scripts in
LoadRunner Controller
• Isolate top time transactions with low load
• Overdrive test (120% of full load) to isolate SW & HW
limitations
• - Work with Internal Support Team to monitor the whole
system, e.g., web server, DB server, middleware, etc.

21.  system - % total processor time
 Memory - page faults/sec
 Server work queues - bytes transferred/sec
 HTTP Response
 Number of connections
• Support team will have better ideas for what to monitor
• Individual write-up is highly suggested as part of test report
• ---need to get csv files, then import to LoadRunner

22. 5. Analyze Test Result - Analysis
- Collect statistics and graphs from LoadRunner
- Report results
- Most commonly requested results:
Transaction Response time
Throughput
Hits per sec
HTTP response
Network Delay
*Server Performance
- Merge graphs to make it more meaningful
Transaction response time under load
Response time/Vuser vs CPU utilization
Cross scenario graphs

23. 6. Test Report
- Don’t send LoadRunner result and graphs
directly
- Send summary to the whole team
- Report key performance data and back end
performance data
- Add notes for each test run
- Keep test history: for team to compare test runs

24. 7. Performance Tuning
- Help identify the bottlenecks and degradation
points to build an optimal system
- Hardware, Configuration, Database, Software, etc
- Drill down on transaction details,
- e.g. webpage breakdown
- Diagnostics
- Show Extended Log to dev team
- Data returned by server
- Advanced Trace: Show logs of all VUser messages
and function calls

25. 8. Communication Plan
- Internal Support Team:
- - PM, BA, environment / development /
architect, network, DBA, functional test
lead, etc.
- Resource plan

26. Test Planning, Script Creation – 4 weeks
Test Execution – 4 weeks
Trail run - 2 days
1. Round 1 – Load Testing: Response time with SLA target load:
1 week
2. Round 2 – Stress Testing: find breaking point: 1 week
3. Round 3 – Duration (Reliability) test: 2 days
4. More performance tuning – 3 days
5. Document and deliver final report – 2-3 days

27.  Scripting: VUGen (Virtual User Generator)
 Performance test execution:
 Controller – build test scenarios according to
business profile and load calculation
 Load Generator – run virtual users
 Performance test result analysis
 Analysis
 provides test reports and Graphs
 Summarize the system performance

28.  Web-enabled global load testing tool
Performance Testing team can manage
multiple, concurrent load testing projects
across different geographic locations
User Site - conduct and monitor load tests.
Privilege Manager- manage user and project access rights
Administration Site - for overall resource management
and technical supervision

29.  - Pinpoint Root Cause
– Solve tough problems
 Memory leaks and trashing
 Thread deadlock and synchronization
 Instance tracing
 Exceptions

30. • Start with monitoring of business process
• Which transactions are problematic
• Eliminate system and network components
• Infrastructure monitors and metrics
• Isolate application Tier and method
• Triage (using Transaction Breakdown)
• Correct behavior and re-test
•
•

31. • WebSphere J2EE/Portal
Server
• WebLogic J2EE/Portal
Server
• JBoss, Tomcat, JServ
• Oracle Application
Server J2EE
MS .NET
Generic/Custom JAVA
SAP Net/Weaver
J2EE/Portal
Oracle 11i Applications
Siebel

32.  80% of IT Organizations experience failures in apps that
passed the test phases and rolled into production
 HyPerformix – Performance Engineering
 Production line: Designer, Optimizer and Capacity
Manager
 HyPerformix Optimizer (Capacity Planning): can bridge
the gap between testing and production environments
and leverage load test data to accurately show how the
application will perform when in production.

33.  Configuration sizing, Capacity planning
 Create production-scale models
 – Perf. Test team and Architect team work together
 Load test and production perf. data are
seamlessly integrated with Optimizer
 Ensure capacity is match to current and future
business requirements
 Reduce risk before application deployment

34.  Performance testing is critical. Competition in market is
high: customer switch cost is low, cost to keep
customers is high
 Performance Testing can protect revenue by helping to
isolate and fix problems in the software infrastructure
 Improve availability, functionality, and scalability of
business critical applications
 Ensure products are delivered to market with high
confidence that system performance will be acceptable
 Proactive performance testing can decrease costs of
production support and help desk
 A good Performance Testing Process is essential to get
performance testing done right and on time!