One of the most misunderstood parts of performance testing is load testing. Most people think that all performance testing is load testing, but this is not accurate. There are many types of tests that make up performance tests. Before doing load testing, let us take a closer look at the basic information of load testing.
Alibaba Cloud Simple Application Server: Anti COVID-19 SME Enablement Program
$300 coupon package for all new SMEs and a $500 coupon for paying customers.
A basic definition of LoadRunner: Load testing is that many concurrent users run the same program to see if the system infrastructure has handled the load without affecting functionality or performance.
There is another way of explaining the load test as:
Load testing is a subset of performance testing. For example, the performance test is equivalent to Microsoft Office, and the load test is Word. Word is just an integral part of Office. Word and Excel are widely used together. They are probably the two most frequently used components of Office.
The following are N strategies to consider when preparing for load testing.
For the right test volume
First of all, don't perform large-scale testing without actual need. There is no need to put pressure on the software beyond actual expectations.
Of course it is always a good thing to produce an environment with a higher traffic load than expected, but to remain realistic and efficient, you should focus on evaluating the correct workload that your application will encounter in production.
For convenience, depending on periodic events, a website or APP may encounter traffic peaks during more than one peak or peak load period. But it is recommended to start the load test by simulating or monitoring the throughput of a normal day before focusing on the load test.
The key word here is throughput, which is another performance test that is often misunderstood. System throughput refers to the amount of information processed by the system in a unit time, which is measured by the number of processes processed per hour or per day.
When proposing a workload transaction test configuration, consider the following:
- On average, how many operations are performed in a typical hour. What about the peak period?
- What is the purpose of this test?
- What is the usual pattern of your server or database activity?
- When choosing tasks to simulate, do you focus on tasks that pose the greatest risk to your business?
- What specific indicators will be tracked or required?
- Take some time to perform this step correctly, as it is the basis for creating a proper load test.
Load generator
Ensure that the load generator is ready to withstand the workload. The load generator is the computer that runs the virtual user test. Virtual users can use scripts or application software, and their behavior is the same as when a real user sends requests to the tested application and system at the same time.
Here are some things to consider:
- Suspend any unnecessary software from the computer.
- Confirm that you are connected to the network and have sufficient network bandwidth, etc.
- If you want to run many virtual users, you need many load generators.
It is important to understand all of this, because if you over-utilize the load generator itself, there is always a risk that may lead to unreliable test results.
Scripting
It is not enough to create a test that simulates the actual scenario. You also need to ensure that the script does not overload the test tool itself.
Make sure that the settings, time, running time, selection of monitors, and the amount of recorded information have been optimized for the test plan. These factors are critical in the load testing process.
Consider any hard-coded or dynamic data that needs to be parameterized, and exclude code that generates invalid tests due to improper script writing. Make sure to generate the correct amount of data and execute the test plan in accordance with the test plan.
User thinking time
Thinking time is an important part of script logic. All tools should have logic to increase thinking time by specifying how many seconds you want virtual users to wait.
Thinking time is useful for mimicking the correct workload based on the actual behavior of virtual users. Failure to use thinking time properly is another common performance test error.
People either forget to add them, or the setup takes a few milliseconds. Load testing does require the creation of an actual test plan to simulate how real users will interact with the software. Take a look at the tool, and then ask for confirmation: Do you need to make more decisions on this page? How long does it take to perform related operations?
Acceleration and deceleration time
For an application, to allow so many virtual users to log in and log out at the same time, this is not in line with the real scenario.
If you have the ability to extend the acceleration and deceleration time, it is recommended to do so. When performing load testing, it is best to have an acceleration time, because it takes some time for the test to reach a stable state, which is a bit similar to Ramp-up in JMeter. Response time and other measurements should only be counted between the end of acceleration and the beginning of deceleration.
Monitoring and diagnosis
When conducting large load tests, monitoring and diagnosis must be considered.
The diagnostic information captured during normal testing means that a large amount of data will be captured. However, for tests with many virtual users, the captured data may have many difficulties. The side effect of this is that testing tools may have difficulty coping with all this information.
The same is true for performan
ce monitoring. Many test programs choose seemingly random measurement values, but do not know the function of each counter, or even whether it needs to be monitored, not to mention how to record and count these data.
Generally speaking, it is not a bad idea to capture as much monitoring data as possible, but to minimize the test data collected, it is important to select only basic performance counters.
When performing load testing, you need to save some troublesome process, and insist on using statistical tools that have successful experience, and then use them to solve and isolate performance problems.
Analyze test data
Prepare to analyze your load test data. The longer the test time, the greater the number of events captured during the test, and it will be more challenging to analyze it regardless of the tool used.
Load testing generates a lot of data. It is not easy to delve into the test results and find everything you need. Even if there is a simple way to analyze data (or automated analysis), it is still a very challenging process.
Need to estimate in advance about how to deal with this problem, and then specify the relevant plan. Error analysis of software data can produce wrong results. If you don't analyze the data correctly, you can't rush to conclusions. Extracting relevant conclusions from the data generated by the load test requires experience and skills.
to sum up
Before starting the load test, you need to determine the correct workload flow. Determine the resources occupied by virtual users to prepare an appropriate number of load generators and the distribution of virtual users among them. You need to create the data that virtual users will use, and you need to prepare the environment, hardware,
servers, applications to be tested, and the software to be tested itself.
