Chapter 10. Automating a System Load

If we return to the input-processing-output analogy to stress testing I spoke of in the previous chapter, the work of automating a system load falls within the realms of both input and processing. Of course the workload itself, furnished with valid and plentiful data, lies at the heart of stress testing. But without a mechanism for automating this workload— for driving it in a fairly unattended but highly regimented manner and doing so in a way that reflects the appropriate number of concurrent users or processes—your stress-testing efforts amount to little more than inconsistent stabs at single-unit load testing. Automating a system load allows the following:

• It frees up human resources, both end-user- and technology-focused.

• It ensures a repeatable testing process is built, which in turn creates not only good baselines but good subsequent test runs that may be compared to the baselines.

• It mitigates Go-Live and change-driven risks.

• It saves money across the board, from people- and process-centric dollars (compared with manual stress-testing procedures) to the money inherently saved as a result of a solution being technically validated prior to deployment.

This chapter is dedicated to helping you make the most of your limited time and resources by focusing on effective workload automation. My own experience in real-world scripting and other automated techniques is highlighted here: approaches, lessons learned, tips and tricks to crisply and rapidly craft scripts that work, and more. And I identify a few alternatives to automating a test load, too, which will not only get you thinking but may also prove useful as sales tools should you find yourself in the position of having to justify or “sell” these automation techniques to your team, your boss, or perhaps even a steering committee.