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 in cases of purchasing, online test taking, bill payment, 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 name sake 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.

 

 

Introduction

The purpose of this test is to understand the performance of application under load, particularly users.

 

 

 

 

 

Load Testing

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, its ability to respond consistently within accepted tolerance on different user loads.

The key considerations are:

1. What is the max load the application is able to hold before the application starts behaving unexpectedly?
2. How much data the Database is able to handle before system slowness or the crash is observed?
3. Are there any network related issues to be addressed?

Stress Testing

Stress testing is the test to find the ways to break the system. The test also gives the idea for the maximum load the system can hold.

Generally Stress testing has incremental approach where the load is increased gradually. The test is started with good load for which application has been already tested. Then slowly more load is added to stress the system and the point when we start seeing servers not responding to the requests is considered as a break point.

During this test all the functionality of the application are tested under heavy load and on back-end these functionality might be running complex queries, handling data, etc.

The following questions are to be addressed:

• What is the max load a system can sustain before it breaks down?
• How is the system break down?
• Is the system able to recover once it’s crashed?
• In how many ways system can break and which are the weak node while handling the unexpected load?

Volume Testing

Volume test is to verify the performance of the application is not affected by volume of data that is being handled by the application. Hence to execute Volume Test generally huge volume of data is entered into the database. This test can be incremental or steady test. In the incremental test volume of data is increased gradually.

Generally with the application usage, the database size grows and it is necessary to test the application against heavy Database.  A good example of this could be a website of a new school or college having small data to store initially but after 5-10 years the data stores in database of website is much more.

The most common recommendation of this test is tuning of DB queries which access the Database for data. In some cases the response of DB queries is high for big database, so it needs to be rewritten in a different way or index, joints etc need to be included.

Capacity Testing

=> 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:

1. Will the application able to support the future load?
2. Is the environment capable to stand for upcoming increased load?
3. What are the additional resources required to make environment capable enough?

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 part.

Reliability/Recovery Testing

Reliability Testing or Recovery Testing – is to verify as to whether the application is able to return back to its normal state or not after a failure or abnormal behavior- and also how long does it take for it to do so(in other words, time estimation).

An online trading site if experience 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. In this case, 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 some more fundamental ones that are prominent:

Smoke Test:

• How is the new version of the application performing when compared to previous ones?
• Is any performance degradation observed in any area in the new version?
• What should be the next area where developers should focus to address performance issues in the new version of application?

 

Component Test:

 

• Whether the component is responsible for the performance issue?
• Whether the component is doing what is expected and component optimization has been done?

Endurance Test:

• Whether the application will able to perform well enough over the period of time.
• Any potential reasons that could slow the system down?
• Third party tool and/or vendor integration and any possibility that the interaction makes the application slower.

How does Functional Testing differ from Performance Testing?

Identification of components for 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, 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 performance test.
Example: E-commerce sites interface with online banking sites for payments, which is an external third party application. This should be definitely the part of Perf testing.

Tools for performance 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. Apparently it’s not practical and even if we do, 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 behave just the way a real user would.

For the creation of as many VUs as you would require and to 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.

Few of the such tools are:

• HP LoadRunner,
• Jmeter,
• Silk Performer,
• NeoLoad,
• Web Load,
• Rational Performance Tester (RTP),
• VSTS,
• Loadstorm,
• Web Performance,
• LoadUI,
• Loadster,
• Load Impact,
• OpenSTA,
• QEngine,
• Cloud Test,
• Httperf,
• App Loader,
• Qtest,
• RTI,
• Apica LoadTest,
• Forecast,
• WAPT,
• Monitis,
• Keynote Test Perspective,
• Agile Load, etc.

 

The tool selection depends on budget, technology used, purpose of testing, nature of the applications, performance goals being validated, infrastructure, etc.

HP Load Runner captures majority of market due to:

1. Versatility – can be used on windows as well as web based applications. It also works for many kinds of technologies.
2. Test Results – It provides in-depth insights that can be used for tuning the application.
3. Easy Integrations – works with diagnostics tool like HP Sitescope and HP Diagnostic.
4. Analysis utility provides a variety of features which help in deep analysis.
5. Robust Reports – LoadRunner has a good reporting engine and provides a variety of reporting formats.
6. Comes with an Enterprise package too.

The only flip side is its license cost. It is a little bit on the expensive side – which is why other open source or affordably licensed tools that are specific to a technology, protocol and with limited analysis & reporting capabilities have emerged in the market.

Still, the HP LoadRunner is a clear winner.

Future in Performance Testing Career

Performance testing is easy to learn but need lots of dedication to master it. It’s like a mathematics subject 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, straight forward logic not being applicable, look and feel of the tool being different, etc. – the approach to Perf testing is almost always the same.

I would highly recommend this hot and booming technology and to enhance your skill by learning this. Mastering PT could be just what you are looking for to move ahead in your software testing career.

Load Runner is going to be our vehicle in the journey, but the destination we want to reach is to understand everything about performance testing.

Stay tuned!