PERFORMANCE TESTING
A Seminar Report submitted to JNTUA in partial fulfillment of the requirements
For the award of the degree of
BACHELOR OF TECHNOLOGY
IN
COMPUTER SCIENCE AND ENGINEERING
BY
V.Radesh 182H1A05B8
Under the guidance of
Mr.R.KALYAN CHAKRAVARTHY
Associate.Proffesor
Dept of CSE, ASIT, Gudur.
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
(Accredited By: NAAC A-GRADE | Approved By: AICTE | Affiliated to JNTUA)
NH-16, BYPASS ROAD, GUDUR-524101, TIRUPATI (Dt.). ANDHRA PRADESH.
2018-2022.
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
(Accredited By: NAAC A-GRADE | Approved By: AICTE | Affiliated to JNTUA)
NH-16, BYPASS ROAD, GUDUR-524101, TIRUPATI (Dt.). ANDHRA PRADESH.
2018-2022.
CERTIFICATE
This is to certify that the Technical Seminar Report entitled , “PERFORMANCE TESTING” is
bonafied work of Mr.Radesh vankayalapati bearing Reg. No: 182H1A05B8 in partial fulfilment
of the requirements for the award of degree BACHELOR OF TECHNOLOGY in COMPUTER
SCIENCE AND ENGINEERING from AUDISANAKARA INSTITUTE OF TECHNOLOGY.GUDUR .
CO-ORDINATOR HEAD OF DEPARTMENT
R.Kalyan Chakravarthi (bsc) Dr. A.SWARUPA RANI(Ph.D)
Assistant. Professor Professor
Department of CSE Head Of CSE
Audisankara Institute Of Technology Audisankara Institute Of Technology
Gudur – 524101 Gudur – 524101
DECLARATION
I, Mr.Radesh Vankayalapati hereby declared that the Technical Seminar Report entitled
“PERFORMANCE TESTING” being submitted by me is a bonafied work carried out by me and
true to the best of my knowledge .
Date : Signature of the Student
Place: GUDUR RADESH VANKAYALAPATI
182H1A05B8
TABLE OF CONTENT
S.NO TITLE PAGE NO
1. INTRODUCTION 1
1.1. CHARECTERISTICS OF TESTING 1
2. TYPES OF TESTING 3
2.1. ALPHA TEST 5
2.2. BETA TEST 6
2.3. WHITE BOX TESTING 7
2.4. BLACK BOX TESTING 11
3. PERFORMANCE TESTING TECHNIQUES 11
3.1. LOAD TESTING 12
3.2. STRESS TESTING 12
3.3. SOAK TESTING 13
3.4. SPIKE TESTING 13
4. PERFORMANCE TESTING PROCESS 14
4.1. REQUIREMENT ANALYSIS 14
4.2. POC/TOOL SELECTION 16
4.3. PERFORMANCE TEST PLAN & DESIGN 17
4.4. PERFORMANCE TEST DEVELOPMENT 18
4.5. PERFORMANCE TEST MODELLING 19
4.6. TEST EXECUTION 20
4.7. TEST RESULT ANALYSIS 21
4.8. REPORT 22
5. CONCLUSION 23
6. REFERENCE 24
LIST OF FIGURES
S.NO FIGURE NAME PAGE NO
1. TYPES OF PERFORMANCE TESTING 7
2. BLACK BOX TESTING 11
3. PERFORMANCE TESTING TECHNIQUES 14
4. PERFORMANCE TESTING WORK FLOW 15
ABSTRACT
The performance testing is a measure of the performance characteristics of an application. The
main objective of a performance testing is to demonstrate that the system functions to
specification with acceptable response times while processing the required transaction volumes
in real-time production database.
The objective of a performance test is to demonstrate that the system meets requirements for
transaction throughput and response times simultaneously. The main deliverables from such a
test, prior to execution, are automated test scripts and an infrastructure to be used to execute
automated tests for extended periods.
Software testing is the process in which we uncover errors that were made unintentionally as it
was designed and constructed. Software testing is done to improve software quality. A strategy
for software testing is developed by project managers, software engineers and testing specialists.
PERFORMANCE TESTING
INTRODUCTION
1.Characteristics of testing
" To perform effective testing, a software team should conduct effective formal technical
reviews. By doing so, many errors will be eliminated before testing commences.
" Testing begins at the component level and works "outward" toward the integration of the entire
computer-based system.
" Different testing techniques are appropriate at different points in time.
" Testing is conducted by the developer of the software and (for large projects) an independent
test group.
" Testing and debugging are different activities, but debugging must be accommodated in any
testing strategy.
1
TESTING:
2
2.Types of Testing
2.1.Alpha Test
Alpha test is conducted at the developer's site by the end user. The software used in a natural
setting with the developer "looking over the shoulder" of a typical user and records errors and
usage problems. Alpha tests are conducted in a controlled environment.
2.2.Beta Test
Beta test is conducted at the end user's site. Unlike alpha testing, the developer is generally not
present. Therefore, the beta test is a "live" application of the software in an environment that
cannot be controlled by the developer. The end user records all problems that are encountered
during beta test and reports these to the developer at regular intervals. As a result of problems
reported during beta test, software engineers make modifications and then prepare for release of
the software product to the entire customer base.
2.3.White-Box Testing
White-Box Testing is sometimes called as glass-box testing. Logical paths through the software
and collaborations between components are tested by providing test cases that exercise specific
set of conditions and/or loops. Using White-Box Testing methods software engineers derive test
cases that
" Guarantee that all independent paths within a module have been exercised at least once.
" Exercise all logical decision on their true and false sides.
" Execute all loops at their boundaries and within their operational bounds.
" Exercise internal data structure to ensure their validity.
2.4.BLACK BOX TESTING:
Black-Box Testing is also called as behavioral testing. Black-Box Testing alludes to tests that are
conducted at the software interface. It focuses on the functional requirements of the software.
Black-Box Testing attempts to find errors in the following categories:
" Incorrect or missing functions.
" Interface errors.
" Errors in data structure or external data base access.
" Behavior / performance errors.
3
2.4.Black-Box Testing
3. Performance Testing Techniques:
4
5
3.1.Load testing
It is the simplest form of testing conducted to understand the behaviour of the system under a
specific load. Load testing will result in measuring important business critical transactions and
load on the database, application server, etc., are also monitored.
3.2.Stress testing
It is performed to find the upper limit capacity of the system and also to determine how the
system performs if the current load goes well above the expected maximum.
3.3.Soak testing
Soak Testing also known as endurance testing, is performed to determine the system parameters
under continuous expected load. During soak tests the parameters such as memory utilization is
monitored to detect memory leaks or other performance issues. The main aim is to discover the
system's performance under sustained use.
3.4.Spike testing
Spike testing is performed by increasing the number of users suddenly by a very large amount
and measuring the performance of the system. The main aim is to determine whether the system
will be able to sustain the workload.
4.Performance Test Process
Here are all the activities performed in this testing:
6
7
4.1. Requirement Analysis/Gathering
The performance team interacts with the client for identification and gathering of requirements –
technical and business. This includes getting information on the application’s architecture,
technologies, and database used, intended users, functionality, application usage, test
requirement, hardware & software requirements, etc.
4.2.POC/Tool selection
Once the key functionality is identified, POC (Proof Of Concept – which is a sort of
demonstration of the real-time activity but in a limited sense) is done with the available tools.
The list of available tools depends on the cost of the tool, protocol that application is using, the
technologies used to build the application, the number of users we are simulating for the test, etc.
During POC, scripts are created for the identified key functionality and executed with 10-15
virtual users.
4.3.Performance Test Plan & Design
Depending on the information collected in the preceding stages, test planning and designing are
conducted.
Test Planning involves information on how the performance test is going to take place – test
environment, workload, hardware, etc.
More on the Test Strategy document below.
4.4.Performance Test Development
Use cases are created for the functionality identified in the test plan as the scope of PT.
These use cases are shared with the client for their approval. This is to make sure the script will
be recorded with the correct steps.
Once approved, script development starts with a recording of the steps in use cases with the
performance test tool selected during the POC (Proof of Concepts) and enhanced by performing
Correlation (for handling dynamic value), Parameterization (value substitution) and custom
functions as per the situation or need. More on these techniques in our video tutorials.
The Scripts are then validated against different users.
Parallel to script creation, the performance team also keeps working on setting up the test
environment (Software and hardware).
8
The performance team will also take care of Metadata (back-end) through scripts if this activity
is not taken up by the client.
4.5.Performance Test Modeling
Performance Load Model is created for the test execution. The main aim of this step is to
validate whether the given Performance metrics (provided by clients) are achieved during the test
or not. There are different approaches to create a Load model. “Little’s Law” is used in most
cases.
4.6.Test Execution
The scenario is designed according to the Load Model in Controller or Performance Center but
the initial tests are not executed with maximum users that are in the Load model.
Test Execution is done incrementally. For Example, If the maximum number of users is 100, the
scenarios are first run with 10, 25, 50 users and so on, eventually moving on to 100 users.
4.7.Test Results Analysis
Test results are the most important deliverable for the performance tester. This is where we can
prove the ROI (Return on Investment) and productivity that a performance testing effort can
provide.
Some of the best practices that help the Result Analysis process:
A unique and meaningful name to every test result – this helps in understanding the purpose of
the test.
Include the following information in the test result summary:
Reason for the failure/s
Change in the performance of the application compared to the previous test run
Changes made in the test from the point of application build or test environment.
It’s a good practice to make a result summary after each test run so that analysis results are not
compiled every time test results are referred.
PT generally requires many test runs to reach the correct conclusion.
It is good to have the following points in result summary:
Purpose of test
Number of virtual users
9
Scenario summary
Duration of test
Throughput
Graphs
Graphs comparison
Response Time
4.8.Report
Test results should be simplified so the conclusion is clearer and should not need any derivation.
Development Team needs more information on analysis, comparison of results, and details of
how the results were obtained.
10
5.Conclusion
Transactions are LoadRunner’s which is a mean for measuring performance and high business
risk transactions. It is able to measure a single step or a group of steps. It allows performance
comparison between different load tests. It helps to identify performance problems. It also
measures end-to-end response times of specific steps in the entire business process
automatically.
11
6.REFERENCE:
https://www.softwaretestinghelp.com/introduction-to-performance-testing-loadrunner-
training-tutorial-part-1/
http://jmeter.apache.org/
http://www.hp.com/
12
