How to best design and create a load test on a web application?

Question

I'm new to testing and have been asked to create a load test for a web application. My group's lead asked the test to just browse the application for hours with a load of 100 users. That's the only spec he has given to me, and I have my basic test doing that with the tool I'm using, Soasta Cloud Test

Now is there anything I should specifically test? A lot of the test results' details in Cloud Test are going over my head and I have no idea what to even look for in these results.

I do realize this is a generic question, but am willing to provide as much detail as possible given the right questions.

Answer 1

Assuming the web application accesses a server then the purpose of many web performance tests is to see how the server behaves under load and whether high loads cause unwanted delays in responding to user activity. Also to see whether the system has headroom while coping with that load.

One part of the test could be to see that 95% of all web pages are loaded within (say) 3 seconds and 99% within 7 seconds. Find the design goals and non functional requirements of the web site to get the actual values.

Another part of the test could be to see whether page load times increase significantly as the load increases. For your system you might run with 20 users for 20 minutes, increase to 40 users and run for another 20 minutes. Then keep increasing at the same rate until you get to (perhaps) 1.5 times your expected maximum load.

Another test might simulate 9am when all you users start work and login. The user load changes from near zero to near maximum in five minutes or less. How does the system behave with such a dramatic change of load. You might extend this test to simulate an 11am coffee break, where everyone stops work for 10 minutes then resumes work.

Another common test is a long duration steady load. Perhaps at a high load but not the peak expected load.

During each of the various tests you should monitor the various computers that together make the servers in the system; eg database servers, web servers, application servers, load balancing duplicates, etc. You might look for CPUs that are too busy, memory that is too low, excessive paging, over used network links, SQL (or database) transaction rates; and many others. Generally you are looking to see whether any parts of the system are overloaded or approaching overload. The tests can only use a small portion of the many possible transactions a user can do, so real load might push any busy parts of the system too far.

Answer 2

A few elements of a load test strategy:

• Concurrency: can your app handle x simultaneous sessions? The sessions don't have to be doing much, just that you can have that many users logged in at once.

• Latency: measuring page load time, like AdrianHHH described, is good here.

• Throughput: how many transactions can your system handle per unit of time?

• Scalability: the behavior of Latency or Throughput as the system load grows. (AdrianHHH described this pretty well)

• Load profile: use analytics to see actual customer behavior to design your load. For example, if you were testing a video streaming service: how many users will be searching for movies, watching movies, creating new accounts, or managing their existing account. its best to use actual behavior instead of random browsing the application.

• You can also use a page speed test service, or plug-in. Yslow is a popular plug-in for firefox. Webpagetest.org is a free service to give you a "waterfall" diagram of the page load. Both of these give a score (A-F) on various attributes. Here is the webpagetest result for sqa.stackexchange.com: http://www.webpagetest.org/result/140411_5N_XZB/

Good luck!

John

Answer 3

Adrian and jruberto have mentioned some things you could do.

I would like to add some general information.

The first thing you want to know is what the goal for your load tests should be. You should ask your group's lead what she wants to be tested, or what information she wants to have. Maybe she is interested in some specific component or web service. Maybe she wants the hole system to be load tested.

If the goal is to test the complete system, it is useful to first determine a profile of your application. If you have some kind of monitoring built into your application, you can use this to determine which components or services are used how often, and at which time of day. If there is no monitoring information, you can also estimate the usage of each component over time. E.g. for the number of users: At 7:00 there are 20 users working with the application. From 7:00 to 12:00 the number of users increase to 350 users. From 12:00 to 16:00 the number of users stays at 350, before decreasing to about 20 users at 22:00, where it stays until the next morning.

You do this also for each component or service or business workflow of your application, or for the most important ones. E.g. at 7:00 there are 30 workflows of type X per hour. Between 7:00 and 13:00 the number increases to 500 workflows per hour and so forth.

If you have this information, you can determine a load profile which is similar to production load. You design your tests accordingly. You can for example test increasing load starting at minimum production load and ending at maximum production load over 3 hours.

If a higher load is expected than is currently visible in production, you have to increase your load profile accordingly.

Generally, with load testing you want to know how the system or component behaves under load / how it handles this load. Mostly this is done using increasing load, or using a load profile which is similar to expected production load over a day as explained above (with increasing and decreasing load).

You increase the load up to the specified load the system or component was built to handle.

You can also increase the load beyond the specifications of the component or system for short periods of time, e.g. 10 minutes. This is called stress testing.

I hope this helps.