Load testing of Web-systems. We are completing the preparation
The article and the article describe the points that you should pay attention to when preparing for the test with a high load on a Web-based system with a Web-based interface.
I propose to consider the final, in my opinion, stages of preparation for stress testing.
When you plan to test the system, a detailed plan of actions is drawn up. Having prepared a sequence of steps, it’s worth looking at them again and breaking one large scenario into smaller ones.
Take some personal account of the banking sector. We check how your personal account works during stress testing. We have certain steps:
The first thing that comes to our mind is to write down these seven simple steps in one scenario and execute it. But we can break this sequence into 7 simpler sets. As a result, we get a fairly large number of combinations of many tests.
An approximate set of tests from 7 different sets.
We can clearly see how the use of several sets allows us to create several tests that can help us perform stress testing of our functionality in various combinations and in the most complete way.
This level of detail makes it possible to respond more quickly to changing conditions of the Web-system. For example, if one of the sets was changed, then we will need to re-record only 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 in stress testing.
The larger the system under test, the more possible options for using it can be. In the previous section, we examined how we can split 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 perform one set of steps at a time. Each person is individual. Of course, test suites may coincide for different user groups, but all 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 simpler ones. And then use several “complex” sets in one test.
Such detailing and the use of test suites brings us closer to the possible real 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 that the web-system is unknown to us, we do not know its structure and architecture and see only the web version, then we do not know exactly which of the operations on which server can be performed.
In real conditions, the load will differ from the test performed when we used the same sequence for the entire test and each user. I believe that such a test organization shows a real use case for a Web system.
This organization of execution kits also allows us to adjust the delays with which certain kits can begin to run. And this is another plus to the realism of our test.
Nowadays, with a huge number of digital devices and many ways to transfer data, we may encounter problems with data transfer speed. Modern utilities for stress testing or other software systems give us the opportunity to limit the speed of data exchange. Many will say why we need this, we checked how the system works when using our data channel, and which one is not of interest to us there.
I propose to consider the situation when the server supports only 10 simultaneous connections. 20 users will work simultaneously with it. We know that when this or that user has finished working, then he releases the connection and the next one can actively start using it. If for some users we limit the speed of data exchange, then our time for receiving data will also increase. Because of this, we are increasing the total operating time of the entire scenario.
If we have a lot of such “slow” users, then we will fill the entire channel of the server, which means that new ones who try to connect to it will receive a failure after the connection timeout. In other words, out of 20 users, several may completely fail.
In fact, this is not a server performance problem; it processed information at the speed with which the client works. But on the other hand, we lose a few 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 should wait in the connection queue.
If there was a high-speed channel, we would never have found out this problem, since the server would most likely have always managed to finish working with the current user before the next user connection timed out.
We were able to find out a similar situation only when performing load testing taking into account changes in the value of the data exchange rate.
It is always better for the customer to provide complete information about the operation of his web-system, taking into account its use on various digital devices. A situation is likely when you tested at maximum speed settings, but most users of the system turned out to be with mobile devices, where the speed of data exchange with the web-system can vary significantly and depend not only on the type of device, but also on the user's location relative to the data transfer device.
Splitting one large script into small sets gives us the opportunity to quickly make changes to a specific step in the script. Completely re-recording the script is not required.
Detailing allows us to compile a large number of tests with a different set. Which brings our tests closer to the real loads that will be carried out 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. Not always the data obtained using a full-fledged data exchange channel can be successfully extrapolated to a channel with less bandwidth.
I hope that the steps I have described to prepare for the load test on your Web system will help you implement a test that will be closest to the actual conditions of use of the system under test and will enable you to quickly make changes to your test suite.
Good luck with your tests and good results.
I propose to consider the final, in my opinion, stages of preparation for stress testing.
Smash test case
When you plan to test the system, a detailed plan of actions is drawn up. Having prepared a sequence of steps, it’s worth looking at them again and breaking one large scenario into smaller ones.
Take some personal account of the banking sector. We check how your personal account works during stress testing. We have certain steps:
- Open the main page.
- Go to your personal account page.
- Sign in.
- Check the status of your accounts.
- Pay for any service.
- Transfer to any card.
- Log out.
The first thing that comes to our mind is to write down these seven simple steps in one scenario and execute it. But we can break this sequence into 7 simpler sets. As a result, we get a fairly large number of combinations of many tests.
An approximate set of tests from 7 different sets.
We can clearly see how the use of several sets allows us to create several tests that can help us perform stress testing of our functionality in various combinations and in the most complete way.
This level of detail makes it possible to respond more quickly to changing conditions of the Web-system. For example, if one of the sets was changed, then we will need to re-record only 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 in stress testing.
Using different sets in one test
The larger the system under test, the more possible options for using it can be. In the previous section, we examined how we can split 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 perform one set of steps at a time. Each person is individual. Of course, test suites may coincide for different user groups, but all 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 simpler ones. And then use several “complex” sets in one test.
Such detailing and the use of test suites brings us closer to the possible real 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 that the web-system is unknown to us, we do not know its structure and architecture and see only the web version, then we do not know exactly which of the operations on which server can be performed.
In real conditions, the load will differ from the test performed when we used the same sequence for the entire test and each user. I believe that such a test organization shows a real use case for a Web system.
This organization of execution kits also allows us to adjust the delays with which certain kits can begin to run. And this is another plus to the realism of our test.
Use different baud rates for running sets
Nowadays, with a huge number of digital devices and many ways to transfer data, we may encounter problems with data transfer speed. Modern utilities for stress testing or other software systems give us the opportunity to limit the speed of data exchange. Many will say why we need this, we checked how the system works when using our data channel, and which one is not of interest to us there.
I propose to consider the situation when the server supports only 10 simultaneous connections. 20 users will work simultaneously with it. We know that when this or that user has finished working, then he releases the connection and the next one can actively start using it. If for some users we limit the speed of data exchange, then our time for receiving data will also increase. Because of this, we are increasing the total operating time of the entire scenario.
If we have a lot of such “slow” users, then we will fill the entire channel of the server, which means that new ones who try to connect to it will receive a failure after the connection timeout. In other words, out of 20 users, several may completely fail.
In fact, this is not a server performance problem; it processed information at the speed with which the client works. But on the other hand, we lose a few 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 should wait in the connection queue.
If there was a high-speed channel, we would never have found out this problem, since the server would most likely have always managed to finish working with the current user before the next user connection timed out.
We were able to find out a similar situation only when performing load testing taking into account changes in the value of the data exchange rate.
It is always better for the customer to provide complete information about the operation of his web-system, taking into account its use on various digital devices. A situation is likely when you tested at maximum speed settings, but most users of the system turned out to be with mobile devices, where the speed of data exchange with the web-system can vary significantly and depend not only on the type of device, but also on the user's location relative to the data transfer device.
Conclusion
Splitting one large script into small sets gives us the opportunity to quickly make changes to a specific step in the script. Completely re-recording the script is not required.
Detailing allows us to compile a large number of tests with a different set. Which brings our tests closer to the real loads that will be carried out 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. Not always the data obtained using a full-fledged data exchange channel can be successfully extrapolated to a channel with less bandwidth.
I hope that the steps I have described to prepare for the load test on your Web system will help you implement a test that will be closest to the actual conditions of use of the system under test and will enable you to quickly make changes to your test suite.
Good luck with your tests and good results.