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

We can see that the log on/log off code performance correction did solve the
problem. Now log on/log off response is not adversely affected after 400 purchase
steps have been launched. Both transaction groups remain well below their
requirement maximums.
Because the rerun of the fi rst mix of transaction groups stay well below
requirement maximums, we are ready to add catalog browse transaction groups
to the mix to verify that the crosstransaction performance fi xes did speed up the
transactions in competition for computing resources. Figure 9.13 illustrates the
results of our second transaction mix performance test rerun.

Log on Catalog browse Purchase

12 12

Purch
Max 10 s

10 10

Browse max
7 s

8 8

6 6

Log on max
3 s

4 4

2 2

0 0

1 50 100 150 200 250 300 350 400 450 500

Number of round trip transactions

Figure 9.13 Round trip performance for peak logon + purchase + catalog browse workload mix after
performance corrections have been applied

With these results, the performance corrections are now verifi ed as lower-
ing all mixed performance response times below the requirement maximums
without adversely affecting functionality. The application under test passes the
Saturday workload performance test. As more of the application is completed, the
performance tests become a part of the regression test to prove that newly added
functionality does not inadvertently degrade performance beyond the requirement
maximums.

9.5.6 Weekday Workload Performance
Plan Execution

You will approach the weekday workload testing in the same way that we per-
formed the Saturday workload testing. Ramp up each transaction group in
the workload to confirm that the transaction group response times are below