Performance Test Planning Document

V1.1

Document Status:
*validation step: In Progress / Sent for Approval /Approved*

Change log:
Change Prepared / Version# Reviewed & Comments Date
ref# Modified by Approved by
Performance 1.0 mm/dd/yy
Testing Team
Performance 1.1 03/08/2018
Testing Team

Page 1 of 9
1 Requirement Background..........................................................................................3
1.1 Synopsis................................................................................................................3
1.2 Objective...............................................................................................................3
1.3 Project Contacts and Approvals.......................................................................3
2 Scope of Work.............................................................................................................4
2.1 System Architecture – Logical..........................................................................4
2.2 System Architecture – Physical.........................................................................5
2.2.1 Production vs Test Environment..................................................................5
2.2.2 Business Processes for Performance Testing.................................................6
2.3 Volumes and SLA’s............................................................................................6
2.4 Test Types............................................................................................................6
2.5 Activities In Scope..............................................................................................7
2.6 Scope Exclusions.................................................................................................7
2.7 Assumptions........................................................................................................7
2.8 Risks......................................................................................................................8
3 Performance Monitoring............................................................................................8
4 Testing Schedule.........................................................................................................9

Page 2 of 9
1 Requirement Background

1.1 Synopsis
The objective of the Performance Test is two-fold
1. To test and configure best settings to hold desirable load
2. To verify if the page performance during high load times is in acceptable limits

1.2 Objective
1. To verify that the PerformanceTesting.in meet their expected response time SLA’s
while under predefined user loads, transaction volumes and concurrency.
2. To verify the PerformanceTesting.in can run consistently over a 24-hr period at an
expected load without encountering application failures or degrading response times.

1.3 Project Contacts and Approvals

Role Name Approver (Y/N) Extension

Testing Head freeperformance Y

Project Director Kamalesh Y

Page 3 of 9
2 Scope of Work
2.1 System Architecture – Logical

The Bajaj Lifestyle Mobile app. has two performance considerations

1. Manual Method
a. Manual method is employed under conditions when the App. code does not
interact with network
b. Manual method for the app is of two types
i. Device specific testing
ii. Streaming and other media services
2. Script Method
a. This method is employed when the network traffic (http requests) are
scriptable
b. All the end user scenarios which reach web server are scripted

Page 4 of 9
2.2 System Architecture – Physical

Currently system has shared physical resources. With IIS as execution engine MS SQL is
database. Few of the following questions are unknown and must be tested to find them.
1. It is currently unknown what the capacity of the system is. Future scaling of the
system depends on tests to be conducted. Load balancers and other load controls are
not in place. The rate of data loading is also unknown. Failover points are unknown.
2. IIS server (16 GB RAM / 4 Core Processor) – Windows
3. MS SQL server (16 GB RAM / 4 Core Processor) - Windows

2.2.1 Production vs Test Environment

# Component Y/N Details

Do Test and Prod have the same number of
Y Benchmark in progress
1 Web Servers?
Do Test and Prod Web Servers have the same
To be scientifically
hardware configuration (CPU, Memory, N
studied
2 Disk, NIC’s, etc)?
Do Test and Prod have the same number of Best settings to be
Y
3 App Servers? determined
Do Test and Prod App Servers have the same
To be scientifically
hardware configuration (CPU, Memory, N
studied
4 Disk, NIC’s, etc)?
Do Test and Prod Database Servers have the Best settings to be
Y
5 same amount of data? determined
Do Test and Prod DB Server(s) have the
To be scientifically
same hardware configuration (CPU, N
studied
6 Memory, Disk, NIC’s, etc)?

Page 5 of 9
2.2.2 Business Processes for Performance Testing
The business processes below are considered in scope for performance testing.

# user Business Process Name Complexity Work Load

1 End User Browse by Content Medium 50%
2 End User Browse by Products Moderate 30%
3 End User Product Registration Medium 5%
4 End User Service Registration Medium 5%
5 End User My Account Details Easy 5%
6 End User Application Feedback Easy 5%

2.3 Volumes and SLA’s

The below mentioned SLAs should be met by the application during performance testing and
this identifies part of the SUCCESS/FAIL criteria for tests.

Transaction Name User Volume Transaction Volume/hr Response time(sec)

Browse by Content 50%
Browse by Products 30%
Product Registration 5%
Service Registration 5%
My Account Details 5%
Application Feedback 5%

2.4 Test Types

Benchmark Tests:
These tests will start with a base load of 50 Users. The load is increased with Infrastructure
or Code changes. In case of delays in code fixes the tests will only be estimated (proportional
tests). These are cyclic tests. The cycle is independent of issue resolution and cannot be on
demand. The development should be planned around load tests.

Load Tests:
These tests will emulate the peak hourly load as on production servers.
Pass Criteria: 2 rounds of Load Tests for 2000 Users.

Stress Test:
This test is to find the break point, where the application breaks. We will increase user
volumes up to 5X expected peak load. We will run for a steady state of 15 minutes at each
user volume level.

Page 6 of 9
 Pass Criteria: Application doesn’t break at 5X load. (2500 – 4000 Users is a good
stress test)

Endurance Test:
This test is to find the application behavior when it runs for 24 hours. The ideal test condition
would be for 4 hours.

Pass Criteria: All Response time and Volume SLA’s are met.

NOTE: Additional tests to support performance tuning activities will require additional
project time, effort and cost.

2.5 Activities In Scope

The following activities are in scope of performance testing:
1. Scope Definition
2. Requirement Gathering and Test Planning
3. Test Script Development
4. Test Execution, Monitoring & Result Reporting

2.6 Scope Exclusions

1. Functional testing activities.
2. Test data setup activities to setup the data required for the transactions.
3. Hardware and other infrastructure-related enhancements
4. Any support activities and functionality issues for the existing production issues
5. Any architecture or database related changes.
6. Any performance issues arising out of third party applications.

2.7 Assumptions
The following assumptions are made:

1. This document must be completed prior to script creation.

2. Workflows to be scripted must be documented prior to script creation.
3. All Sev 1 and 2 defects must be resolved prior to script creation.
4. All testing will be performed in a dedicated test environment.
5. Performance test execution must happen on the same build of code that goes to
production.
6. The database in test environment is sized similar to the production environment.

2.8 Risks

1. Scripts used in previous cycle of testing are often unreliable on new builds. This issue
will frequently cause additional time and cost for re-scripting on the latest build.

Page 7 of 9
 2. The need for Performance Tuning Activities, delays in providing code or
environment, or any other delays with the project may require additional time, effort
and cost.
3. Code changes during scripting or execution will often cause script failures. It is
advisable to freeze code when performance scripting has started if possible.
4. There will likely be a delay in test execution if tuning requires the application to be
unavailable for the test execution.
5. Any delay in testing environment availability will impact on the script validation and
test execution schedule.

3 Performance Monitoring
Server Name Server Function Tool
IIS Server Web Servers Basic .net monitoring
MS SQL Server Database MS SQL - Trace
End to End Servers Web / DB New Relic

Page 8 of 9
4 Testing Schedule

Phase Owner Start Date End Date Status Comments

kick off
efforts freeperformance 9/2/2018 14/2/2018 Completed Requirements Gathering
Test Plan freeperformance
Creation 14/2/2018 15/2/2018
Completed Test script creation
Test Script freeperformance Script creation and
creation 12/2/2018 15/2/2018 Completed validation
freeperformance Baseline test
exection(Single User) for
Android and IOS
Baseline Test 15/02/2018 20/02/2018 Completed application
Test data freeperformance In Test data creation &
creation 9/3/2018 12/3/2018 progress validation
freeperformance Load Test execution with
Load test different user load and
executions 13/3/2018 28/03/2018 test report with analysis
freeperformance Test reporting and
Test Report analysis for all
and Analysis 29/03/2018 6/4/2018 executions
Walkthrough freeperformance Walkthrough with Client
Call 9/4/2018 9/4/2018 & DEV team
Test Signoff freeperformance
Report 10/4/2018 12/4/2018 Final Signoff report

Page 9 of 9