Today, we are starting the ‘Performance testing with LoadRunner’ tutorial series. This is the first tutorial in a three-part HP LoadRunner training series.
In the first two tutorials, we will introduce you to performance testing and in the last tutorial we will share ‘Load Testing with LoadRunner video tutorials‘.
See Also => List of all LoadRunner Video Tutorials.
Why Performance testing?
Performance testing has proved itself to be crucial for the success of a business. Not only does a poor performing site face financial
losses, it also could lead to legal repercussions at times.
No one wants to put up with a slow performing, unreliable site when purchasing, taking tests online, bill paying, etc. With the internet being so widely available, the alternates are immense. It is easier to lose clientele than gain them, and performance is a key game changer.
Therefore, performance testing is no longer a namesake checkpoint before going live. It is indeed a comprehensive and detailed stage that would determine whether the performance of a site or an application meets the needs.
The purpose of this test is to understand the performance of an application under load, particularly for users.
What You Will Learn:
Load testing is a type of performance test where the application is tested for its performance on normal and peak usage. Performance of an application is checked with respect to its response to the user request and its ability to respond consistently within an accepted tolerance on different user loads.
The key considerations are:
Stress testing is used to find the ways to break the system. The test also provides the range of maximum load the system can hold.
Generally, stress testing has an incremental approach where the load is increased gradually. The test is started with a load for which the application has already been tested. Then, more load is added slowly to stress the system. The point at which we start seeing servers not responding to the requests is considered the breaking point.
During this test, the functionality of the application is tested under a heavy load. On the back-end, the functionality might be running complex queries, handling data, etc.
The following questions are to be addressed:
Volume testing is to verify that the performance of the application is not affected by the volume of data that is being handled by the application. In order to execute a Volume Test, a huge volume of data is entered into the database. This test can be incremental or a steady test. In the incremental test, the volume of data is increased gradually.
Generally, with the application usage, the database size grows, and it is necessary to test the application against a heavy database. A good example of this could be a website of a new school or a college having small amounts of data to store initially, but after 5-10 years, the data stores in the database of the website is much more.
The most common recommendation for this test is the tuning of DB queries which access the database for data. In some cases, the response of DB queries is high for a big database, so it needs to be rewritten in a different way or the index, joints etc need to be included.
=> Is the application capable of meeting business volume under both normal and peak load conditions?
Capacity testing is generally done for future prospects. Capacity testing addresses the following:
Capacity testing is used to determine how many users and/or transactions a given web application will support and still meet performance. During this testing, resources such as processor capacity, network bandwidth, memory usage, disk capacity, etc. are considered and altered to meet the goal.
Online Banking is a perfect example of where capacity testing could play a major role.
Reliability Testing or Recovery Testing – is to verify whether or not the application is able to return back to its normal state after a failure or abnormal behavior and how long does it take for it to do so (in other words, time estimation).
If an online trading site experiences a failure where the users are not able to buy/sell shares at a certain point of the day (peak hours) but are able to do so after an hour or two, we can say the application is reliable or recovered from the abnormal behavior.
In addition to the above sub-forms of performance testing, there are other fundamental tests that are prominent:
See also => Smoke testing in functional testing.
How does Functional Testing differ from Performance Testing?
In an ideal scenario, all components should be performance tested. However, due to time & other business constraints, that may not be possible. Hence, the identification of components for testing happens to be one of the most important tasks in load testing.
The following components must be included in performance testing:
#1. Functional business-critical features
Components that have a Customer Service Level Agreement or those having complex business logic (and are critical for the business’s success) should be included.
Example: Checkout and Payment for an E-commerce site like eBay.
#2. Components that process high volumes of data
Components, especially background jobs are to be included for sure. Example: Upload and download feature on a file-sharing website.
#3. Components which are commonly used
A component that is frequently used by end-users like jobs scheduled multiple times in a day, etc.
Example: Login and Logout.
#4. Components interfacing with one or more application systems
In a system involving multiple applications that interact with one another, all the interface components must be deemed as critical for a performance test.
Example: E-commerce sites interface with online banking sites for payments, which is an external third-party application. This should definitely be part of Perf testing.
Sure, you could have a million computers set up with a million different credentials and all of them could login at once and monitor the performance. However, it’s not practical and even if we do that, we still need some sort of monitoring infrastructure.
The best way this situation is handled is through – virtual user (VU). For all our tests, the VU behaves just the way a real user would.
For the creation of as many VUs, as you would require and simulate real-time conditions, performance testing tools are employed. Not only that, Perf testing also tests for the peak load usage, breakdown point, long-term usage, etc.
To enable all with limited resources fast and to obtain reliable results, tools are often used for this process. There are a variety of tools available in the market- licensed, free wares and open sourced.
A Few of such tools are:
See Also => List of top 15 Performance Testing tools
The tool selection depends on budget, the technology used, the purpose of testing, nature of the applications, performance goals being validated, infrastructure, etc.
HP Load Runner captures a majority of the market due to:
The downside is its license cost. It is a little bit on the expensive side – which is why other open source or affordable license tools that are specific to a technology, protocol and with limited analysis and reporting capabilities have emerged in the market.
Still, the HP LoadRunner is a clear winner
Performance testing is easy to learn but needs lots of dedication to master it. It’s like a math problem where you have to build your concept. Once the concept is through, it can be applied to most of the tools irrespective of the scripting language being different, straightforward logic not being applicable, look and feel of the tool is different, etc. – the approach to Perf testing is almost always the same.
I would highly recommend learning this hot and booming technology to enhance your skills. Mastering PT could be just what you are looking for to move ahead in your software testing career.
In this article, we have covered most of the information required to build a base to move ahead and understand Performance testing. In the next article, we will apply these concepts and understand the key activities of Performance testing.
Next Tutorial => How to Performance Test an Application
LoadRunner is going to be our vehicle for the journey, but the destination we want to reach is understanding everything about performance testing.
About the Author: Chetan Kaushal is helping us for this ‘Performance testing with LoadRunner’ tutorial series. He has over 6 years of experience working on performance testing projects using HP LoadRunner and Performance Center tools.
In the meantime, if you have any questions related to performance testing, load testing, or LoadRunner please ask them in the comments below.