With most project teams I've worked with, I've found that when I say the words "stress testing" people really hear the words "load testing." To me this is rather odd, but when I step back and think about it, I guess it makes sense. Most applications I've worked on have been web applications, and in that world load is often one of the biggest factors related to stress.

However, to help remind myself that there are other forms of application stress, I use the following checklist when I evaluate what stress testing I want to do. For each of these, I look at each piece of the architecture (desktop/browser, database, service/server, etc...) and in turn ask myself, "What would happen if...?"

• heavy load:
  
  
  
  • large number of users
  
  
  • large volumes of data
  
  
  • large number of processes
  
  
  • large number of transactions
  
  
  
  


• constrained resources
  
  
  
  • not enough memory, processing power, or disk space
  
  
  • not enough bandwidth
  
  
  • not enough queues (or even shallow queue depth)
  
  
  • not enough licenses
  
  
  • inability to access files, servers, or services
  
  
  
  


• unfriendly inputs
  
  
  
  • invalid file types and/or data types
  
  
  • fuzz testing
  
  
  • very large (or very small) inputs
  
  
  
  


• shared resources
  
  
  
  • crash or stress other applications in a shared server space or that use a shared device/service
  
  
  
  


• timing
  
  
  
  • constant or steady load for long periods of time (endurance)
  
  
  • intermittent loads with long pauses in between transactions (looking for timeouts or parts of the system that go to sleep or get deprioritized with inactivity)
  
  
  • concurrency (trying to force potential race conditions, file/database locking, etc...)