The purpose of stress tests is to make the system under test fail and determine how gracefully it behaves in failing. Deliberate overloads, certain security attacks, or other techniques to purposefully crash the software are only useful if they help in verifying that the overstressing conditions and failures are handled correctly.Notes taken from Boris Beizer books:
Include load generation for background, stress, and performance testing as a major budget item - probably to be shared equally between software development and quality assurance.
Select load generation methods (external, cogeneration, self-generation) appropriate to schedule, expected residual value, need, and validity. Start load generation development at the same time as software development.
Plan software instrumentation in support of performance testing as part of the system design rather than as an afterthought. Develop, publish, and discuss embedded software instrumentation as early as possible.
Tie down load statistics and parameters as early as possible in the project and in contractually binding written form.
Establish a method (e.g. continual revision of models) for tracking performance impacts of buyer changes just as you tack cost and schedule impacts - it's no less important.
Include background testing a part of element-level testing, as soon as it is feasible. Test exports should include whether or not the tests were run under background.
Start stress testing as early as possible in the program. Subject the system to stress whenever possible - after every revision, after every new version, after every major data-base change, and so on.
Include a well-staged stress test as the highlight of the formal system acceptance test; be sure to rehearse it.
Accept no performance criteria that cannot be measured and validated with the allocated personnel, schedule, and monetary resources. Conversely, be sure that all persons involved are aware of the cost and time that might be associated with validating specific performance parameters.
Plan performance testing as a specific, recognizable activity to be done on a test bed, and if necessary in the field. Be sure to allow enough time for the system and users to stabilize before attempting field performance testing.
Run performance tests intermixed with other system tests to detect bugs whose primary symptoms are performance-related. Validate the system's performance by a test run after every major revision, version change, data base change, and so on.