commercial load test tools but who wasn't familiar with Perl. It took forty-two lines of code to log in a user and click a link and iterate as many times as we desired. We only had three test accounts available, but once we proved that a user could log in from more than one browser at a time, we programmed the script to repeatedly log in the same few users.
At first I "drove," writing the preliminary version of the script and showing my partner how I used the automation library. When we found that we could log in thousands of sessions at a time without error, my partner took over the keyboard. We added code to randomly choose sessions that had already logged in and had them click another link to keep the session from timing out.
This was probably my first project where the first simplistic approach to load testing did not find any serious limitations in the product. With further exploratory functional testing, we did find numerous robustness problems, such as unexpected form input causing server exceptions. So after a few days of testing, we were able to report that robustness problems were more of a concern than the reliability of the system under load. We still needed to follow up with a more elaborate load testing approach before we could confidently say we had found most of the major reliability issues. Continuing the incremental approach to load testing would ensure that the project gets timely feedback on reliability, so that management can easily decide whether to invest in additional load testing.
Organic Script Gardening
In the Web testing example above, the script was contained in a single file. After a few hours of development, we started to abstract some common actions into subroutines. This was sufficient for what we needed for the short project.
For the peer-to-peer application discussed above, I was involved in the testing for several months and developed a whole suite of test tools for it. The application uses several different network protocols. When I started experimenting with testing a new protocol, my test code would be contained within a single script. As the script became more sophisticated, I would extract code into subroutines and eventually move the subroutines in an object-oriented test library. The code grew organically, and I carefully tended the developing garden of code so it didn't grow wild and unmanageable. I now have a powerful and continually growing arsenal of application-specific libraries that help me to quickly craft variations on the load tests I've done before.
The good news for you is that you can start to build load tests using an incremental approach. Adjust your approaches as you learn more about how the system reacts. Once you find one bug, you can often tune your test to avoid that bug. This way, you can find additional problems without waiting for a bug fix. Choose whichever tool will get you started fastest, whether it's a full-featured load test tool or a scripting language with a collection of existing libraries.