Performance Testing - Software Testing: Testing Across the Entire Software Development Life Cycle - page 148

as dissatisfi ed with the software as if the functionality were incorrect in the fi rst
place. The reason for this end-user attitude is because correct answers delivered
too late lose business opportunity just as surely as if the correct answers were
never delivered at all.
This chapter describes an approach to performance testing that will alert the
development team about software performance shortfalls before the software is
delivered to end-users. Although software delivery of business functionality has
advanced signifi cantly in the past 30 years, performance delivery continues to be
problematic. Expect the fi rst performance tests from any new software to reveal
not “if” the software is performing to requirements but “how much” the software is
missing the performance requirements.
9.7 SUMMARY
The objective of performance testing is to validate the software “speed” against the
business need for “speed” as documented in the software requirements. Software
“speed” is generally defi ned as some combination of response time and workload
during peak load times. These peak load times may occur during lunchtime, at the
opening of the stock market day, or after midnight when all online customers are in
bed (overnight batch workload). Performance testing is achieved by a series of tests
that introduces increasingly more workload of increasingly more complex business
transaction mixes.
Performance testing occurs after the functional testing is mostly completed and
the software has become quite stable (fewer and fewer changes or corrections). Func-
tional defects in the software may be revealed during performance testing, but this
is not the testing objective.
The performance tester's fi rst workload challenge is to identify which
business transactions and activities need to be measured for performance. In all
but the simplest software applications, it is diffi cult to identify the most important
transaction and activity candidates for performance testing. The diffi culty lies partly
with the software end-user's typical reaction, “everything must respond in less than
3 seconds.” Somehow the tester must convince the end user that different groups of
transactions and activities will have different performance requirements based on
different business priorities.
The performance tester's second workload challenge is to determine peak usage
of each group of transactions and the timeframes in which the peak usage occurs. Peak
usage is normally measured in terms of active users. The third performance tester's
challenge is to clarify just how many different workload peaks need to be tested.
Once you have identifi ed the groups and volumes of transactions for each peak
workload test, you need to develop the steps to create this peak in a test environment
so that performance measurements can be taken. There are three traditional steps for
executing performance test workload. First, you execute workload ramp-up to peak
load. Then, you execute performance measurements at the peak. Finally, you execute
workload ramp-down from the peak.