Stressing anything beyond a point results in serious consequences in humans, machine or a program. It either causes serious damages or breaks it completely.
Similarly, in this tutorial, we will learn how to stress test web applications along with its effect.
In order to avoid any permanent damage to your apps or websites when they are stressed i.e. heavily loaded, we need to find the breaking point and in turn the solution to avoid such conditions. Just think how it would be when your shopping website goes down during Christmas sale. How much would be the loss?
Stress testing is defined as the process of testing the hardware or software for its stability under a heavy load condition. This testing is done to find the numerical point when the system will break (in terms of a number of the users and server requests etc.) and the related error handling for the same.
During Stress testing, the application under test (AUT) is bombarded with a heavy load for a given period of time to verify the breaking point and to see how well error handling is done.
Example: MS Word may give a ‘Not Responding’ error message when you try to copy a 7-8 GB file.
You have bombarded Word with a huge sized file and it couldn’t process such a big file and as a result, it is hanged. We normally kill apps from the Task Manager when they stop responding, the reason behind it is that the apps get stressed and stop responding.
Following are some technical reasons behind performing Stress testing:
- To verify the system behavior under abnormal or extreme load condition.
- To find the numerical value of users, requests etc., after which the system may break.
- Handle the error graciously by showing appropriate messages.
- To be well prepared for such conditions and take precautionary measures like code cleaning, DB cleaning, etc.
- To verify data handling before the system breaks i.e. to see if data was deleted, saved or not etc.
- To verify security threat under such breaking conditions etc.
This is a type of non-functional testing and this testing is usually done once the functional testing of a website or app is completed. The test cases, the way to test and even the tools to test may vary at times.
Following are some pointers that would help you to strategize your testing process:
- Identify the scenarios, functionalities etc., that will be accessed the most and may tend to break the system. Like for a financial app, the most commonly used functionality is transferring money.
- Identify the load that the system can experience on a given day i.e. both maximum and minimum.
- Create a separate test plan, scenario, test case and test suite.
- Use 3-4 different computer systems for testing with different memory, processor etc.
- User 3-4 different browsers for web apps with different versions.
- Ideally, find the value below the breakpoint, at the breakpoint and the value after the breakpoint (when the system will not respond at all), create a test bed and data around these.
- In the case of web apps, try to stress test with a slow network too.
- Don’t jump to the conclusion of tests in just a round or two, execute the same tests for at least 5 rounds and then conclude your findings.
- Find the ideal response time of the web server and what is the time is at the breakpoint.
- Find the app behavior at the breaking point at different points of the app like while simply launching the app, logging in, performing some action post login etc.
Stress testing for native mobile apps is a little different from that of web apps. In native apps, a stress test is done for the commonly used screens by adding huge data.
Following are some verification that is done as a part of this testing for native mobile apps:
- The app doesn’t crash when huge data is shown. Like for an emailing app, around 4-5 lakhs of received email cards, for shopping apps, the same amount of item cards etc.
- Scrolling is glitch free and the app doesn’t hang while scrolling up or down.
- The user should be able to view the details of a card or perform some action on the card from the huge list.
- Sending lakhs of updates from the app to the server like marking an item as ‘Favourite’, adding an item to the shopping cart, etc.
- Try loading the app with huge data on a 2G network, when the app hangs or crashes, it should show an appropriate message.
- Try an end to end scenario when there are huge data and a slow 2G network etc.
Following should be your strategy for testing on mobile apps:
- Identify the screens which have cards, images etc., so as to target those screens with huge data.
- Similarly, identify the functionalities that will be used most commonly.
- While creating the test bed, try to use medium and low-end phones.
- Try to test simultaneously on parallel devices.
- Avoid this testing on emulator and simulators.
- Avoid testing on Wifi connections as they are strong.
- Try to run at least one stress test out in the field etc.
|S.No.||Stress Testing||Load testing|
|1||This testing is done to find out the breaking point of the system.||This testing is done to verify the performance of the system under an expected load.|
|2||This testing is done to find out whether the system will behave as expected if the load goes beyond the normal limit.||This testing is done to check the response time of the server for the expected specific load.|
|3||Error handling is also verified in this test.||Error handling is not intensely tested.|
|4||This also checks for security threats, memory leaks etc.||No such testing is mandatory.|
|5||Checks the stability of the systems.||Checks the reliability of the system.|
|6||Testing is done with more than the max. possible no of users, requests etc.||Testing is done with the maximum no of users, requests etc.|
The test cases that you will create for your testing will depend on the application and its requirements. Before creating the test cases, make sure that you know the focus areas i.e. the functionalities that will tend to break under the condition of an abnormal load.
Following are some sample test cases that you can include in your testing:
- Verify if a proper error message is shown when the system reaches the breakpoint i.e. crosses the maximum no. of permitted users or requests.
- Check the above test case for various combinations of RAM, processor, and network etc.
- Verify if the system works as expected when maximum no. of users or requests are being processed. Also check the above test case for various combinations of RAM, processor, and network etc.
- Verify that while more than the permitted no. of users or requests are performing the same operation (like buying the same items from a shopping website or making a money transfer etc) and if the system becomes irresponsive, an appropriate error message is shown about the data (not saved? – depends on the implementation).
- Check if more than the permitted no. of users or requests are performing different operation (like one user is logging in, one user is launching the app or web link, one user is selecting a product etc) and if the system becomes irresponsive, an appropriate error message is shown about the data (not saved? – depends on the implementation).
- Verify if the response time for breaking point users or requests is in an acceptance value.
- Verify the performance of the app or website when the network is very slow, a proper error message should be shown for ‘timeout’ condition.
- Verify all the above test cases for a server which has more than one application running on it to check if the other application gets affected etc.
Before executing tests, make sure that:
- All the functional failures of the application under test are fixed and verified.
- The complete end to end system is ready and integration tested.
- No new code check-ins that will affect the testing are done.
- Other teams are informed about your testing schedule.
- Backup systems are created in case of some serious issues.
When Stress Testing is done manually, it is a very complicated and tedious job too. It may also not yield you the expected results.
Automation tools can get you the expected results and it is relatively easy to create the required test bed using them. It may happen that the tools that you are using for your normal functional testing may not suffice for stress testing.
Hence it is for you and your team to decide if they want a separate tool exclusively for this testing. It is also beneficial for others that you run the suite at night so that their work won’t be hampered. Using automation tools, you can schedule the suite to run at night and the results will be ready for you the next day.
Following is a list of most recommended tools:
#1) Load Runner:
LoadRunner is a tool designed by HP for load testing, but it can also be used for stress tests.
It uses VuGen i.e. Virtual User Generator for creating the users and requests for load and stress testing. This tool has good analysis reports which can help to draw the results in the form of graphs, charts etc.
Neoload is a paid tool that is helpful in testing web and mobile apps.
It can simulate more than 1000 users to verify the performance of the system and find the response time of the server. It also integrates with Cloud for both load and stress testing. It provides good scalability and is very easy to use.
JMeter is an open source tool that works with JDK 5 and above versions. The focus of this tool is mostly on testing web applications. It can also be used for testing LDAP, FTP, JDBC database connections etc.
Grinder is an open source and Java-based tool that is used for load and stress testing.
The parameterization can be done dynamically while the tests are running. It has good reporting and assertions to help you analyze the results in a better way. It has a Console that can be used as an IDE to create and edit the tests and Agents to create the load for testing purposes.
Webload tool has a free as well as a paid edition. This free edition allows up to 50 user creation.
This tool supports both web and mobile app stress checking. It supports different protocols like HTTP, HTTPS, PUSH, AJAX, HTML5, SOAP etc. It has an IDE, load generation console, analysis dashboard, and integrations (to integrate with Jenkins, APM tools etc).
In a programming language, a statement is nothing but the line of code or instruction for the computer to understand and act accordingly. A statement becomes an executable statement when it gets compiled and converted into the object code and performs the action when the program is in a running mode.
Hence “Statement Coverage”, as the name itself suggests, it is the method of validating whether each and every line of the code is executed at least once.
Stress testing completely focuses on testing the system under extreme load conditions to find its breaking point and see if appropriate messages are shown when the system is unresponsive. It stresses the memory, processor etc during the testing and checks how well they recover.
Stress testing is a type of non-functional testing and is usually done after the functional testing. When there is a requirement of load testing as well, then this testing can be done as the extreme case of load testing. 90% of the time, the same automation tool can be used for both load and stress testing.
Path coverage tests all the paths of the program. This is a comprehensive technique which ensures that all the paths of the program are traversed at least once. Path Coverage is even more powerful than Branch coverage. This technique is useful for testing the complex programs.