Load testing of Web-systems. We finish the training
The article and the article describe the points that you should pay attention to in preparing for the test with a high load on the Web-system with a Web-interface.
I propose to consider the final, in my opinion, preparatory stages for load testing.
When you plan to test the system, then a detailed plan of actions performed. Having prepared a sequence of steps, it is worthwhile to look at them once more and break one big script into smaller ones.
Take some private office banking sector. We check how the personal account works under load testing. We have certain steps:
The first thing that comes to our mind is to write down these seven simple steps in one script and carry it out. But we can break this sequence into 7 more simple sets. As a result, we get a fairly large number of combinations of a set of tests.
')
The approximate composition of the tests of 7 different sets.
We can clearly see how the use of several sets allows us to create several tests that can help us perform load testing of our functionality in various combinations and in the most complete way.
This level of detail allows you to quickly respond to changing conditions of the Web-system. For example, if one of the sets was changed, then we only need to re-write it, and not the entire sequence.
When developing automated functional testing, it is customary to break one large set of steps into smaller functions. The same principle applies to load testing.
The larger the system under test, the more possible uses it can be. In the previous section, we looked at how we can break one large sequence into several sets and use them in different tests. But what to do when we run the test for several 1,000 users.
The reality is that people cannot simultaneously perform one set of steps. Each person is individual. Of course, test kits may coincide for different user groups, but all of these groups can work with one site at a time, and therefore this is one test.
Many utilities allow you to run different sets in parallel in the same test in parallel. We only need to define a “complex” set, which may consist of more simple ones. And then several “complex” sets are used in one test.
Similar specification and use of test suites brings us closer to the possible actual use of the tested Web-system. Of course, we can perform testing without breaking into sets. But how to be sure that it reflects the real history of use. If we take into account the fact that the web system is unknown to us, we do not know its structure and architecture, and we see only the web version, then we do not know exactly which of the operations on which server can be performed.
In actual practice, the load will be different from the test performed when we used the same sequence for the entire test and for each user. I believe that such an organization test shows the actual use of the Web-system.
This organization of execution sets also allows us to adjust the delays with which certain sets can begin to run. And this is another plus to the realism of our test.
Nowadays, in the presence of a huge number of digital devices and a variety of data transfer methods, we may encounter data transfer speed problems. Modern utilities for load testing or other software systems give us the opportunity to limit the speed of data exchange. Many will say why we need it, we checked how the system works when using our data channel, and which users we are not interested in.
I propose to consider the situation when the server supports only 10 simultaneous connections. 20 users will simultaneously work with it. We know that when a user has finished working, he releases the connection and the next one can actively begin using it. If we restrict the data exchange rate for a part of users, then the time of data acquisition will also increase. Because of this, we increase the total time of the entire script.
If we have a lot of such “slow” users, we will fill the entire channel of the server, which means new ones that will try to connect to it will be rejected after the connection timeout. In other words, some of the 20 users may complete with errors.
In fact, this is not a problem of server performance, it processed information at the speed with which the client works. But on the other hand, we lose several users anyway, they will not be able to connect to the server. Any web server has a setting that is responsible for how long the client waits in the connection queue.
If there is a high-speed channel, we would never find out this problem, since the server would most likely always have time to shut down the current user before the next user’s connection time-out.
We were able to figure out a similar situation only when performing load testing, taking into account the change in the value of the data exchange rate.
It is always better for the customer to provide full information about the operation of his web-system, taking into account its use on various digital devices. It is likely that you tested at maximum speed settings, but the majority of users of the system turned out to be mobile devices, where the speed of data exchange with the web system may differ significantly and depend not only on the device type, but also on the user's location relative to the data transfer device.
Splitting one big script into small sets gives us the ability to quickly make changes to a specific step of the script. Completely re-write the script is not required.
Detailing allows us to make a large number of tests with a different set. Which brings our tests to real loads that will be conducted on the Web-system.
The correct choice of the speed of the channel used will show us how our system will work with real user devices. Data not always obtained using a full-fledged data exchange channel can be successfully extrapolated to a channel with a lower bandwidth.
I hope that the steps I have described in preparation for performing a load test on your Web system will help you implement a test that will be as close as possible to the actual conditions of using the system under test and give you the opportunity to quickly make changes to your test suite.
Successful to you tests and good results.
I propose to consider the final, in my opinion, preparatory stages for load testing.
Break test case
When you plan to test the system, then a detailed plan of actions performed. Having prepared a sequence of steps, it is worthwhile to look at them once more and break one big script into smaller ones.
Take some private office banking sector. We check how the personal account works under load testing. We have certain steps:
- Open the main page.
- Go to the personal account page.
- Sign in.
- Check the status of your accounts.
- Pay for any service.
- To transfer to any card.
- Log out.
The first thing that comes to our mind is to write down these seven simple steps in one script and carry it out. But we can break this sequence into 7 more simple sets. As a result, we get a fairly large number of combinations of a set of tests.
')
The approximate composition of the tests of 7 different sets.
We can clearly see how the use of several sets allows us to create several tests that can help us perform load testing of our functionality in various combinations and in the most complete way.
This level of detail allows you to quickly respond to changing conditions of the Web-system. For example, if one of the sets was changed, then we only need to re-write it, and not the entire sequence.
When developing automated functional testing, it is customary to break one large set of steps into smaller functions. The same principle applies to load testing.
Using different sets in the same test
The larger the system under test, the more possible uses it can be. In the previous section, we looked at how we can break one large sequence into several sets and use them in different tests. But what to do when we run the test for several 1,000 users.
The reality is that people cannot simultaneously perform one set of steps. Each person is individual. Of course, test kits may coincide for different user groups, but all of these groups can work with one site at a time, and therefore this is one test.
Many utilities allow you to run different sets in parallel in the same test in parallel. We only need to define a “complex” set, which may consist of more simple ones. And then several “complex” sets are used in one test.
Similar specification and use of test suites brings us closer to the possible actual use of the tested Web-system. Of course, we can perform testing without breaking into sets. But how to be sure that it reflects the real history of use. If we take into account the fact that the web system is unknown to us, we do not know its structure and architecture, and we see only the web version, then we do not know exactly which of the operations on which server can be performed.
In actual practice, the load will be different from the test performed when we used the same sequence for the entire test and for each user. I believe that such an organization test shows the actual use of the Web-system.
This organization of execution sets also allows us to adjust the delays with which certain sets can begin to run. And this is another plus to the realism of our test.
Use different data rates for triggered sets
Nowadays, in the presence of a huge number of digital devices and a variety of data transfer methods, we may encounter data transfer speed problems. Modern utilities for load testing or other software systems give us the opportunity to limit the speed of data exchange. Many will say why we need it, we checked how the system works when using our data channel, and which users we are not interested in.
I propose to consider the situation when the server supports only 10 simultaneous connections. 20 users will simultaneously work with it. We know that when a user has finished working, he releases the connection and the next one can actively begin using it. If we restrict the data exchange rate for a part of users, then the time of data acquisition will also increase. Because of this, we increase the total time of the entire script.
If we have a lot of such “slow” users, we will fill the entire channel of the server, which means new ones that will try to connect to it will be rejected after the connection timeout. In other words, some of the 20 users may complete with errors.
In fact, this is not a problem of server performance, it processed information at the speed with which the client works. But on the other hand, we lose several users anyway, they will not be able to connect to the server. Any web server has a setting that is responsible for how long the client waits in the connection queue.
If there is a high-speed channel, we would never find out this problem, since the server would most likely always have time to shut down the current user before the next user’s connection time-out.
We were able to figure out a similar situation only when performing load testing, taking into account the change in the value of the data exchange rate.
It is always better for the customer to provide full information about the operation of his web-system, taking into account its use on various digital devices. It is likely that you tested at maximum speed settings, but the majority of users of the system turned out to be mobile devices, where the speed of data exchange with the web system may differ significantly and depend not only on the device type, but also on the user's location relative to the data transfer device.
Conclusion
Splitting one big script into small sets gives us the ability to quickly make changes to a specific step of the script. Completely re-write the script is not required.
Detailing allows us to make a large number of tests with a different set. Which brings our tests to real loads that will be conducted on the Web-system.
The correct choice of the speed of the channel used will show us how our system will work with real user devices. Data not always obtained using a full-fledged data exchange channel can be successfully extrapolated to a channel with a lower bandwidth.
I hope that the steps I have described in preparation for performing a load test on your Web system will help you implement a test that will be as close as possible to the actual conditions of using the system under test and give you the opportunity to quickly make changes to your test suite.
Successful to you tests and good results.
Source: https://habr.com/ru/post/336104/
All Articles