If you're new to load, stress, performance or scalability testing, you are probably wondering what's involved. You may have a lot of experience with automated testing or manual functionality testing and are moving toward the creation of a load testing process. There are some similarities but, more importantly, there are enormous differences.
1. Systems. Setting up an environment in which load testing can occur will most likely be a very expensive endeavor. Examine your current production system(s). Determine the scope of your load testing environment. Do you want to emulate your production system entirely? Do you want to emulate a portion of that system? The latter is probably more practical, though not necessarily the most ideal approach. What components do you want to include? Is third party software integral to your architecture? Do you want to include this? What about hardware? Remember that you'll need not only SUT boxes but also injectors for LoadRunner. If at all possible, you should have an environment for load testing that is separate from all other development, test and production environments. All of these questions and many more should be included in your assessment.
2. Network. Ideally, your load testing environment should be on an isolated network. If nothing else, a switched network should be in place. The reasons for this are obvious, but often overlooked. First, you don't want any non test related activity interfering with your test. If you're running a load test and someone starts FTPing or NDMing large files across the network, it can invalidate your testing. Also, you don't want a high volume stress test impacting a network used by your development or production systems. You won't be too popular if you hose up a heavily used network.
3. Scope. What will be the primary focus of your load testing lab? Will it support the testing of a single app? Will it be responsible for multiple apps across the enterprise? This is a critical question that must be answered before you start setting up your lab.
4. Planning. It cannot be stressed enough that the largest component of any testing effort is planning. Attempting to run a high volume load test in a week is asking for trouble. You must create a detailed test plan, consisting of all of the important aspects of the test: Transaction flow/workload/throughput are important but so are detailed diagrams of the system(s) to be tested, detailed information about your testing methodology (scaling factor, success criteria, step by step procedures for running the test), any issues or concerns that the project team may have, explanations of important metrics to be gathered, dates and times for test executions, contact lists, system components to be included, risks and mitigating factors. These are just examples of what you should include. Not all tests need go into this detail, but you should have a template from which you can cull different sections as required.
5. Support. Always have system and development support when you run your tests. It's very frustrating to be in the middle of a critical load test and have one of your servers lock up. Unless you can address this problem yourself, you need someone to investigate it for you.
6. Staff. Load testing can consume huge amounts of time. If you're supporting multiple applications and are repeating your tests on a regular basis, make sure that you have adequate staff to support all of your efforts.
These are just a few of the issues to consider when assessing you load testing plans.
What’s Involved in Load and Performance Testing?
(This article originally appeared on the Mercury knowledge base site under article number 1609 and is not available now that Mercury has sold to HP.)
 |
 |
 |
 |
 |
 |
 |
 |