Load Testing Complete Guide for Beginners

A Complete Load Testing Guide for beginners:

In this tutorial, we will learn why we perform Load Testing, what is achieved out of it, Architecture, what is the approach to be followed to successfully execute a Load Test, how to set up a Load Test environment, best practices, along with the best Load Testing Tools available in the market.

We have heard of both Functional and Non-Functional Testing types. In Non-Functional Testing, we have different types of testing like Performance Testing, Security Testing, User Interface Testing etc.

Hence, Load Testing is a Non-Functional type of testing which is a subset of Performance Testing. 

Thus, when we say we are testing an application for performance, what all are we testing here? We are testing the application for Load, Volume, Capacity, Stress etc.

What is Load Testing?

Load Testing is a subset of Performance Testing, where we test the system’s response under varying load conditions by simulating multiple users accessing the application concurrently. This testing usually measures the speed and capacity of the application.

Thus whenever we modify the load, we monitor the behavior of the system under various conditions.

Example: Let’s assume that our client requirement for a Login page is 2-5 sec and this 2-5 sec should be consistent all throughout until the load is 5000 users. So what should we observe hear? Is it just the load handling capability of the system or is it just the response time requirement?

The answer is both. We want the system which can handle a load of 5000 users with the response time of 2-5 seconds for all the concurrent users.

So what is meant by a concurrent user and a virtual user?

Concurrent users are those who log in to the application and at the same time, perform a set of activities together and log off the application at the same time. On the other hand, virtual users just hop in and hop out of the system irrespective of the other user activities.

Load Test Architecture

In the below diagram we can see how different users are accessing the application. Here each user is making a request over the internet, which is later passed through a firewall.

After firewall, we have a Load balancer which distributes the load to any of the web servers, and then passes to the application server and later to the database server where it fetches the necessary information based on the user request.

Load testing can be done manually as well as by using a tool. But manual load testing is not advised as we don’t test the application for a lesser load.

Example: Let’s assume, that we want to test an online shopping application to see the response time of the application for each user click i.e Step1 –Launch URL, the response time, Login to the application and note the response time and so on like selecting a product, adding to the cart, making payment and logging off. All these have to be done for 10 users.

So, now when we need to test the application load for 10 users then we can achieve this by manually putting load by 10 physical users from different machines instead of using a tool. In this scenario, it is advisable to go for a manual load test rather than investing in a tool and setting up an environment for the tool.

Whereas imagine if we need to load test for 1500 users then we need to automate the load test using any of the available tools based on the technologies in which the application is built and also based on the budget that we have for the project.

If we have a budget, then we can go for commercial tools like Load runner but if we don’t have much budget then we can go for open source tools like JMeter, etc.

Whether it is a commercial tool or an open source tool, the details have to be shared with the client before we finalize the tool. Usually, a proof of concept is prepared, where we generate a sample script using the tool and show the sample reports to the client for approval of the tool before finalizing it.

In automated load testing, we replace the users with the help of an automation tool, which mimics the real-time user actions. By automating load we can save resources as well as the time.

Below is the diagram that depicts how the users are replaced using a tool.

Why Load Testing?

Let’s assume that there is an online shopping website which is doing pretty good during normal business days i.e users are able to login to the application, browse through the different product categories, select products, add items to the cart, check out and log off within an acceptable range and there are no page errors or huge response times.

Meanwhile, there comes a peak day i.e let’s say the Thanks Giving day and there are thousands of users who are logged in to the system, the system is crashed all of a sudden and the users experience a very slow response, some couldn’t even log in to the site, a few failed to add to cart and some failed to check out.

Hence on this big day, the company had to face a huge loss as it lost many customers and much business too. All this happened just because they didn’t predict the user load for peak days, even if they would have predicted there was no load test done on the company website, hence they don’t know how much load the application will be able to handle on the peak days.

Thus to handle such situations and in order to overcome huge revenue, it’s advisable to conduct load test for such type of applications.

• Load Testing helps to build strong and reliable systems.
• The bottleneck in the system is identified well in advance before the application goes live.
• It helps in identifying the capacity of the application.

What is achieved during a Load test?

With a proper Load test, we can have an exact understanding of the following:

1. The number of users the system is able to handle or is capable of scaling to.
2. The response time of each transaction.
3. How does each component of the entire system behave under Load i.e Application server components, web server components, Database components etc.
4. What server configuration is best to handle the load?
5. Whether the existing hardware is enough or is there any need for additional hardware.
6. Bottlenecks like CPU utilization, Memory Usage, Network delays, etc., are identified.

Environment

We need a dedicated Load Testing environment to conduct our tests. Because most of the time the Load test environment will be the same as the production environment and also the data available in the load test environment will be same like production though it is not the same data.

There will be multiple test environments like SIT environment, QA environment etc, these environments are not the same production, because unlike load testing they don’t need that many servers or that much test data to conduct functional testing or an integration testing.

Example:

In a Production Environment, we have 3 Application servers, 2 Web servers, and 2 Database Servers. In QA, we have only 1 Application Server, 1 Web server, and 1 Database server. Hence, if we conduct a Load test on the QA environment which is not equal to the Production, then our tests are not valid and are incorrect too and thereby we can’t go by these results.

Thus always try to have a dedicated environment for Load testing which is similar to that of a production environment.

Also, sometimes we have third-party applications which our system will call, hence in such cases, we can use stubs as we can’t always work with the third-party vendors for data refresh or any other issues or support.

Try to take a snapshot of the environment once it is ready so that, whenever you want to rebuild the environment you can use this snapshot, which would help with time management. There are some tools that are available in the market to set up the environment like Puppet, Docker etc.

Approach

Before we start the Load test we need to understand if any Load test is already done on the system or not. If there was any load testing done earlier, then we need to know what was the response time, client and server metrics collected, how much was the user load capacity etc.

Also, we need information on how much is the current application handling capability. If it’s a new application we need to understand the requirements, what is the targeted load, what is the expected response time and if it is really achievable or not.

If it is an existing application, you can get the load requirements and the user access patterns from the server logs. But if it is a new application then you need to reach out to the business team to get all the information.

Once we have the requirements, we need to identify how we are going to execute the load test. Is it done manually or using tools? Doing a load test manually needs a lot of resources and is very expensive too. Also repeating the test, again and again, will be tough as well.

Hence, to overcome this we can either use Open source tools or commercial tools. Open source tools are available for free, these tools may not have all the features like the other commercial tools but if the project has a budget constraint, then we can go for open source tools.

Whereas commercial tools have many features, they support many protocols and are very user-friendly.

Our Load Test approach will be as follows:

#1) Identify the Load test Acceptance Criteria

For Example:

1. The response time of the Login page shouldn’t be more than 5 sec even during the max load conditions.
2. CPU utilization should not be more than 80%.
3. The throughput of the system should be 100 transactions per sec.

#2) Identify the Business scenarios that need to be tested.

Don’t test all the flows, try to understand the main business flows which are expected to happen in production. If it is an existing application we can get his information from the server logs of the production environment.

If it is a newly build application then we need to work with the business teams to understand the flow patterns, application usage etc. Sometimes the project team will conduct workshops to give an overview or details about each component of the application.

We need to attend the application workshop and note all the required information to conduct our load test.

#3) Work Load Modelling

Once we have the details about the business flows, user access patterns and the number of users, we need to design the workload in such a way in which it mimics the actual user navigation in production or as expected to be in the future once the application will be in production.

The key points to remember while designing a workload model is to see how much time a particular business flow will take to complete. Here we need to assign the think time in such a way that, the user will navigate across the application in a more realistic way.

The Work Load Pattern will usually be with a Ramp up, Ramp down and a steady state. We should slowly load the system and thus ramp up and ramp down are used. The steady state will usually be a one-hour Load test with Ramp up of 15 min and Ram down of 15 min.

Let us take an Example of the Workload Model:

Overview of the application – Let’s assume an online shopping, where the users will log into the application and have a wide variety of dresses to shop, and they can navigate across each product.

To view the details about each product, they need to click on the product. If they like the cost and make of the product, then they can add to the cart and buy the product by checking out and making the payment.

Given below are a list of scenarios:

1. Browse – Here, the user launches the application, Logs into the application, Browses through different categories and Logs out of the application.
2. Browse, Product View, Add to Cart – Here, the user logs into the application, Browses through different categories, views product details, adds the product to cart and Logs out.
3. Browse, Product View, Add to Cart and Check out – In this scenario, the user logs into the application, Browses through different categories, views product details, adds the product to the cart, does check out and Logs out.
4. Browse, Product view, Add to cart Check out and Makes Payment – Here, the user logs into the application, Browses through different categories, views product details, adds the product to the cart, does check out, makes Payment and Logs out.

The above values were derived based on the following calculations:

• Transactions per hour = Number of users*Transactions made by a single user in one hour.
• The number of users = 1600.
• The total number of transaction in the Browse scenario = 17.
• Response Time for each transaction = 3.
• Total time for a single user to complete 17 transactions = 17*3 = 51 rounded to 60 sec (1 min).
• Transactions per hour = 1600*60 = 96000 Transactions.

#4) Design the Load Tests – The Load Test should be designed with the data that we collected so far i.e the Business flows, Number of users, user patterns, Metrics to be collected and analyzed. Moreover, the tests should be designed in a much realistic way.

#5) Execute Load Test – Before we execute the Load test, make sure that the application is up and running. The Load test environment is ready. The application is functionally tested and is stable.

Check the configuration settings of the Load test environment. It should be the same as the production environment. Ensure all the test data is available. Make sure to add necessary counters to monitor the system performance during test execution.

Always start with a low load and gradually increase the load. Never start with the full load and break the system.

#6) Analyze the Load Test Results – Have a baseline test to always compare with the other test runs. Gather the metrics and server logs after the test run to find the bottlenecks.

Some projects use Application Performance Monitoring Tools to monitor the system during the test run, these APM tools help to identify the root cause more easily and save a lot of time. These tools are very easy to find the root cause of the bottleneck as they have a wide view to pinpoint where the issue is.

Some of the APM tools in the market include DynaTrace, Wily Introscope, App Dynamics etc.

#7) Reporting – Once the Test Run is complete, gather all the metrics and send the test summary report to the concerned team with your observations and recommendations.

Best Practices

Enlisted below are some of the best practices of Load Testing:

#1) Always check the application stability before starting a Load test. The application should be signed functionally stable by the Functional testing team and all major defects should be fixed and tested before the build is copied to the Load Test environment.

#2) Ensure that the Load test environment is a replica or is close to the production environment, including the number of servers, Load balancers, server configurations, and firewalls.

#3) Check if the test data is unique and we have all the test data copied to the load environment before conducting a load test.

#4) Design the test scenarios in such a way that they mimic the real-time user action happening in the production.

#5) Design the workload based on the production user loads and business flows and in case of an old application, see if it is a new talk to the business team regarding the business flows and the user load.

#6) Collect all the important metrics like Response Time, hits per sec, Throughput, Cpu, Memory, Network, and Running Vusers.

Recommended Read => List of Performance Testing Tools available in the market for conducting exclusive load testing.

Conclusion

In this tutorial, we have learned how Load testing plays an important role in Performance testing of an application, how it helps to understand the efficiency and capability of the application, etc.

We also came to know how it helps to predict if any additional hardware, software or tuning is required on an application.

Happy Reading!!