Partager via

Stress Testing for Fun and Profit

  • Article

For me, one of the most enjoyable parts of being a test developer is writing stress tests.  Stress testing can be a lot of fun and, contrary to it's name, a good stress reliever (for the test developer).  During the most recent MEDC, I spoke briefly about stress testing and defined it as coming in two forms: "Long Haul" and "Short Haul".

Long Haul Stress
In long haul stress, the test is designed to emulate customer scenarios.  If a scenario is expected to be executed three times per second under normal operation, a long haul stress test will perform that scenario on multiple threads for a long time (days/weeks).  By using multiple threads and long run times, the Mean-Time-Between-Failures (MTBF) / Mean-Time-To-Failure (MTTF) for the component can be approximated.

In addition to simultaneous threads repeating the target scenario, long haul stress test often up the ante by manipulating other aspects of the system.  Available storage (hard disk / flash) and RAM are common targets for increasing the stress level of a long haul test.

Short Haul Stress
Short haul stress, or "load testing" is my personal favorite type of stress testing.  Short haul tests are designed to be extremely stressful and to run for a relatively brief amount of time (24 hours).  If a long haul test exercises a scenario three times per second on, say, 10 threads, a short haul version of that same test may perform the scenario 30000 times per second on more than 1000 threads.   The same system resource tweaking options used in long haul testing are often used in short haul testing as well.

To me, short haul stress is not really scenario based, however.  I tend to treat short haul testing as an opportunity to be as hard on the component I am testing as humanly possible.  I have been known to throw "everything but the kitchen sink" into my stress tests; every functional area of the component, multiple copies of data files, dozens of threads performing similar tasks, forced errors, etc.

At the start of this post, I asserted that stress testing can be fun.  While writing short haul stress tests, I have occasionally noticed some odd glances into my office (maybe I should close the door more often) when I watch the app run and let that maniacal laugh creep out.  Of course, the best reward of stress testing is to bring a component's developer into the office to show off the latest bug and hear a sound rivaling the most beautiful music... "Your app does WHAT?!?!".  YES!  I got one again. :)

Take care!
-- DK

Disclaimers:
This posting is provided "AS IS" with no warranties, and confers no rights.

Comments

  • Anonymous
    July 30, 2007
    One of the most common questions I hear towards the end of a product cycle is "are we ready to ship?".

  • Anonymous
    July 30, 2007
    One of the most common questions I hear towards the end of a product cycle is "are we ready to ship