|
Description
New to load testing? Things to consider
Solution
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. I'd like to try to go through a few here in the
document included in this posting. It's a bit long, so I couldn't post the entire text here.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
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. |
|