Performance testing is a type of testing that measures how a system is performing under a particular load. With this system, it becomes possible to find valuable information that helps in eradicating bottlenecks and improving the performance of the system. There are different types of performance testing.
The main ones are:
- Load testing
- Stress testing
- Spike testing
- Endurance testing
This guide will be explaining everything you should know about locust load testing. After reading this article you will be able to build a comprehensive plan for testing your application. This guide will explain all the elements and information required to take into consideration for finding and fixing those annoying bottlenecks so you can give your users a better experience while using the application.
Designing a performance testing plan
After defining in which environment is to be tested and what tools will be used for developing the script and executing them it is time for designing and defining the test plan. This planning document should contain:
- Introduction: A brief overview
- Objective: Knowing the objective of these load tests and the benefits they will bring.
- Scope: The system processes that are going to be tested.
- Architecture: Details of application architecture like application server, web server, firewalls, and 3rd party applications.
- Prerequisites: All resources required for starting the project like ensuring all the components that will be load tested are functionally and stable and that the environment is the same.
- Test scenarios: The list is scenarios that are going to be tested.
- Load execution cycles: Mentioning the baseline and how many test runs will be executed with the duration of each cycle and its load.
- Team: The team members who will be involved in the scripting and execution of load tests.
Creating test cases
The goal of load testing cases is to establish the level of performance delivered by the present system. The information gathered helps benchmark the future. It is recommended that performance test cases cover critical functionalities of the application. When saying critical it means that is used most by users.
Here are some essential factors that should be given adequate consideration while designing your test cases:
- Expected load: The load expected by the application in production
- Assertions: Ensure that the application answers as we anticipate for each request
- Security: Ensure that the system preserves user confidentiality, data integrity, and approved permissions.
- Desired Response Time: The entire time it takes for a response to be obtained after requesting it
Creating load scenarios
Using website load testing tools we can simulate the workload an application will have in production. We can also count the number of concurrent users using the application currently, the test cases will be executed then, and the frequency of execution by users among other things.
For designing a load scenario it's recommended to reconsider these variables:
- Daily operations
- Peak hours on the system
- Most popular days used
You can identify the procedures most often utilized and the number of users utilizing these variables. So it's time to set up the load scenario in JMeter now that you have the essential information. Draft a load scenario that simplifies the real system used to increase the cost-benefit ratio while preparing for a performance test. If a simulation had to be made which is the same as that received by the system in production, we would have to pass such a costly test that it would not be worth it. The advantages are not valuable, and after it is too late the outcomes may be achieved!
Data and Infrastructure
You are strongly advised to know the infrastructure your application hosts and which components are present. This is helpful to understand the infrastructure and which components must be monitored to obtain the essential information throughout the testing process.
Data plays a vital part in the conduct of tests to produce a more realistic test. The data quantity, quality/reliability in the test environment, and the test environment are therefore suggested to be similar to that in production. During the test run, this will assist to replicate "reality."
Criteria for acceptance
Criteria of acceptance are conditions for acceptance of the test load findings. Written acceptance criteria assist to minimise unpredictable results in production situations and guarantee that everyone is fulfilled with what is obtained.
Such criteria should be created before test runs and are based on the results of the application that we expect and want. Certain of the most significant and common requirements are:
- Response Time
- Error Percentage
- Processor Usage
- Memory Usage
- Disk Usage
Some load testing tasks, particularly monitoring the live results and the health of the engine, are performed by the tester. These actions are an important element in the testing process, which is needed for testing to be successful.
The health of the engines allocated to the test is also suggested. You may do this on the tab "HealthEngine" (check picture 3). The CPU values should not exceed 75% and the RAM value should not be exceeded by 70%. If the figures are greater, consider reducing the number of virtual users per motor or scrutinizing the script to make this more effective.
Competitive Users versus Active Users
The distinction between competitor users and active users is often asked. Teams are interested in calculating the numbers for which they should shoot, therefore the link between both values has to be understood.
Simultaneous users are people who utilize the app. They have an open session, but they do not conduct activities on the website load testing app. Active users, on the other hand, are people who utilize the app. They hold an open session and take action on the app.
One of the frequent responses from a performance test is, "Give me the time to review the logs so that we don't miss anything. This is because we can locate all that took place in the test logs during the test run.
You will get a warning in a log called JMeter.log indicating that the plugin is missing, for example, if you require a JMeter plugin to execute your test and don't include it in the run. "WARN missing tika-app.jar in the classroom. The advisory will appear like that." This type of document cannot be converted to plain text." The test terminated early, for example. In this situation, the bzt.log file should be checked for the cause. The lines of error will be red.
That's it! We’ve covered all the important elements required for setting up and running a locust load testing plan. Now, in future projects, or your application, you will utilize this expertise.