posted 02-10-2003 04:10 AM         

1) Scenario: All the 50 users using the application simultaniously and every user using different functionality.

2) Scenario: All the 50 users using the application simultaniously and every one is using the same functionality.

3) Scenario: All the 50 users using the application and may be some functions not in use at all and some functions used my more than a single user. Now 51st user trying to access the application.

posted 02-10-2003 04:59 AM         

Load = expected multi-user usage.
Stress = more (often much more) than Load.

There is a grey area in the middle that I call "heavy load" which is expected usage patterns, but more than expected users

posted 02-10-2003 06:04 AM         

I use these 5 types of tests when I am doing performance testing. I cannot remember where I found these definitions at.

• Smoke Test - A brief test used to check if the application is really ready to be tested (e.g. if it takes 5 minutes to download the home page, it isn’t worth going on to test the other pages)

• Load Test – For these kinds of tests, the application is subject to a variable increasing load (until the peak load is reached). It is useful to understand how the application (software + hardware) will react in production.

• Stress Test – For these kinds of tests, the application is subject to a load bigger than the one actually expected. It is useful to evaluate the consequences of an unexpected huge load (e.g. after an advertisement campaign)

• Spike Testing – For these kinds of tests, the application is subject to burst loads. It is useful to evaluate applications used by a lot of users at the same time (high concurrent user rate)

• Stability Testing – For these kinds of tests, the application is subject to an average load for a long period of time. This is useful for finding memory leaks.
  

posted 02-10-2003 10:47 PM         

I must say Thanks in advance, as I am asking this which you all might have answered many times. What i am more interested is list the scenarios for each type of testing for the above said application.(like how I listed 3 scenarios).

I am specificaly asking for scenarios as in the definition to spike testing the word "bursting load" is used. Now this makes me again to search for meaning of bursting load. sorry if I am stressing you a bit further.

posted 02-11-2003 05:49 AM         

Load testing is testing the specified performance of the application. If the application is supposed to support 100 users, then you run a test with 100 users. If it is supposed to handle 50 MB of data in an hour, then you put through 50 MB of data within an hour.

Stress testing is putting the application under stress. Typically I will do 3 times the specification, or at least try to. If the spec says 100 users, I will try to ramp up to 300 users. Actually I will go higher to find the breaking point, but if the application doesn't support 300 users, I will start bringing up the growth issue. If specs say 50 MB per hour, then I try for 150, then 200, then 250, ...

Volume testing... Well, I think that is kind of what I was pointing at with Stress testing. I guess Stress testing would be hitting the limit of 3 times the specs. Volume testing would be to find the upper limits of the application.

Stability testing would be like a 24hr, 48hr, or week-long test of the specified load. The applicaiton may hold up under 100 users for an hour, or 50 MB for an hour, but can it sustain that level for long periods of time. This is especially critical if you have any type of queueing(spelling?) mechanism in the back end. Queues can get backed up over time if not configured correctly, and it may take longer than 1 or 2 hours for it to happen. A stability test will flush this out. Monitoring the servers during this test is paramount, it is important during all of the tests, but you need to pay special attention here.

Spike testing... that is a tricky one to execute, depending on the tool you have. I'm using SilkPerformer right now and one of the workload configurations lets you control the number of VUs while the test is running, so I can quickly jack-up the number of virutal users at any point. This kind of testing is used to mimic peak times of the day or week when a large number of people are hitting the application. If you are testing for the number of users hitting the system, you are wanting a high concurrency of page hits, such as 9:00 am when everyone shows up for work and logs in at the same time. Or to simulate overnight batch processing when everyone dumps their data into the system at midnight on Sunday. Some tools have facilities to manage this through the workload you set up, others you will have to code for this. Very good and important test. It is ok for the app to slow down, but you don't want the app to break with a spike in activity. With Spike testing, the concept of "burst loads", at least as I take it, is to send multiple spikes at the system, don't just send one spike and let it go, send a spike, give it a minute or two, then send another, then another, then another. The system may appear to be handling a single spike, when in reality, it is getting clogged up (back to the queueing problems). You could send a spike, and the application is responding, but slowly. Now, you may want to monitor the servers to see when they return to normal after a spike, then you want to start sending one spike after another so see if they still handle things gracefully.

I hope all of this helps, and if anyone has anything to add to this or disagrees with any of it, please feel free to hack it apart.

posted 03-02-2003 11:14 PM         

I have used ACT on a couple of projects. i have been very comfortable in
using all the features in it.

Consider this scenario.

Suppose i record a script for a application . I record the functionality on
a update user profile page. in this case i am recording only the activities
of a single user.
i run this test for different number of browser connections says (1, 5, 10 ,
20, 30... 100). the results what i get says that at a load of 40 browser
connections. the requests in the IIS are getting queued. similarly also in
the database transactions are getting queued. as 40 users are accessing the
same table updating the same record. this will all increase the waiting time
of the request in the IIS queue.

I dont think this case is realistic. the SQL transactions will be on the
same table but not on the same record.

for the above mentoned scneario the reading what are received, are this the
ideal once?

does performance testing go about this way.

or is there some other approch to it.

posted 03-03-2003 08:34 AM         

While I am glad that information was helpful to you, please do not re-post your question. You gave it a thread all it's own. Folks will answer you there.