Load testing can be further expanded to include volume testing where volumes of data used by each of the users can be put through the systems whilst they are under load.
I've found it confusing how different organisations use the terms 'load' and 'volume' testing. As some use 'volume' testing when they really mean 'load' testing and others use 'load' testing to include both load and volume testing.
Load testing is increasing the number of users a system can handle concurrently and volume testing is increasing the number of tasks each of the users does.
The following story of when I first worked in banking highlights the differences. During my stint at the bank, there was a big push to use blade technology. I was given the task of designing a Citrix farm capable of running the development applications. With the farm scheduled to be deployed using low powered non-SCSI, single CPU blades, I believed a volume test was essential but because I was a freelancer, an outsider, the Citrix team didn't believe my cause for concern.
"We should easily get 45 users per blade!"
I was shocked at how these figures were being touted and that the cost per user in terms of hardware was grossly inaccurate, as I believed they'd seriously over estimated their user numbers per server.
So I decided to run two tests to show the Citrix team the value of not only testing but advanced load testing, that is volume testing. After pestering them for a few days, they agreed to come to my presentation.
For my first test, I ramped up users onto a single blade server and opened Microsoft Word. I managed to get 180 test users log into the server and run a few tasks each. The Citrix team seemed very happy with these results as they seemed to exceed their own expectations.
The second test involved logging into a development application running various tasks such as compiling programs etc. There were over 200 different tasks scripted and I'd actually worked with the developers for a few days to get a good idea of how they worked.
I also managed to get hold of one of the programs they were working on at the time. It contained over a hundred thousand lines of code and I used this as my base program used by the development application in my test.
The second server started to struggle at 15 users, it was identical in specification to the first server. The Citrix team started to ask questions about the huge discrepancy. I told them both servers were undergoing load testing but one was also experiencing volume testing and it's these volumes which were pushing the server to it's limits.
The first server just opened the application and ran a few tasks. Plus the application, Microsoft Word was terminal services aware and therefore wouldn't really be a good indicator of application resource usage. I used this application to prove how easily it was to skew the results.
The second server was a better indicator as this is how the systems would actually be deployed. Hence the cost saving advocated by blade servers were inaccurate as they handled considerably less load when large volumes of tasks occurred.
I got the general consensus to proceed further with my testing and use different hardware, so the cost savings could be re-evaluated. After I completed my testing, the results proved we needed to avoid the blade servers and use the standard dual CPU servers they'd previously used in their deployments.
To further highlight how load and volume testing work, I'm going to use a MPV (Multi Purpose Vehicle) as an example. The MPV is designed to carry to typically carry 7 passengers. So during load testing the MPV would be tested with 7 passengers aboard and then driven across various terrains.
Now when the volume aspect of load testing was looked at, you could increase the weight of the passengers. So instead of using average weight people, obese passengers could be used. This wouldn't increase the load in terms of people but it would increase the volume of people in the test, that is their combined weights.
In conclusion load testing can be advanced by conducting Citrix volume testing.