Review and customize the test
Performance Tester generates a test based on the HTTP traffic it captured during the recording. The test is much more than a simple HTTP trace log, however. Behind the scenes, Performance Tester does a lot of processing to create a test that is robust, extensible, and easy to maintain. In this section, you will examine the generated test in greater detail and customize it to use unique data.
The test is represented in a tree format in the left portion of the Test Editor view. Each top-level node in the tree represents a Web page visited during your recording session. The name of the node is based on the name of the Web page.
Figure 8. The Test Contents tree view
- Expand the Welcome to the Adventure Builder Reference application
node. Here is where the advanced performance test engineer can see all the
details of the transactions behind the page. The first element is highlighted
in blue to indicate that it is the primary request -- the request for the page
Figure 9. The expanded page in the Test Contents tree view
- Click the Protocol Data view in the bottom portion of the window,
then click the primary request highlighted in blue in the tree. The details
of the request and its corresponding response are shown in the Request,
Response Headers, and Response Content tabs of the Protocol Data view. The
Browser tab even renders the contents of the selected element.
Figure 10. The Browser tab in the Protocol Data view
- Detailed information about the selected element is also presented in the right-hand portion of the Test Editor view. You can edit this data if you need to change the host, URL, request header values, or any other field.
Web applications tend to be highly dynamic. For example, in the scenario you recorded you placed an order for a vacation package and were given a unique order ID. You then used that order ID to check the status of your purchase. When you play-back this test, it will place another order and you will be given a different order ID. You would want Performance Tester to check the status of that new order ID, not the one you previously recorded.
For that reason, Performance Tester performs automatic data correlation. That is, it looks at data parameters sent to the server and matches them up with prior response data from the server. Accessing the correlated data is easy.
- Highlight the Order Tracking Results node in the Test Contents area
of the Performance Test view. Now right-click inside the Test Data area to the
right and select Show References. Notice that the orderId field
is being substituted with data from a prior response.
Figure 11. Show References for data correlation
- Double-click orderId. This takes you to the URL of the actual request
for that page.
Figure 12. Correlated data in the URL of a request
- Right-click the highlighted string and select Go To. This takes you
directly to the orderId value in the response text of the Checkout
request. During test playback, Performance Tester will substitute the orderId
value it receives in this response for the orderId in the request for order
Figure 13. Correlated data in the prior response
Granted, you now know far more than you probably wanted to know about data correlation; but that is the beauty of Performance Tester: it does all this for you without any hand coding or other effort on your part.
In performance testing it is essential to be able to randomize the data being sent to the server. Modern Web applications have many layers of caching. If you were to emulate a thousand users using the application doing exactly the same thing, you would not observe typical performance behavior. Once the first emulated user performed the transaction, all the subsequent users would be drawing information from the cache. For this reason, performance test engineers often spend much of their time configuring tests to pull random data from a "datapool" so that each emulated user uses unique information.
Performance Tester automatically identifies likely candidates for datapool access and makes it possible to associate these fields with data sources you provide.
- Select the Enter Adventure Package Details page node in the test
contents. Notice in the Test Data area the
start_dayparameters. These were the default values in the Options page, which were subsequently transmitted back to the server when the Set Package Options button was clicked.
Figure 14. Datapool candidates
- Set up a datapool to randomize the values used by your virtual users when you play-back this test. Select start_month in the Test Data area.
- Click Substitute From below the Test Data area.
- Select Datapool Value....
Figure 15. Substitute start_month from the datapool variable
- Click Add Datapool on the "Select datapool" column window. You will add an association to an existing datapool to this test.
- Select the existing VacationStartDates datapool and click Select.
- Back in the "Select datapool" column window, select start_month and click Use Column. Note that the "Substituted with" column next to the start_month variable now has a reference to the datapool column.
- Select start_year in the Test Data area. Repeat the process. This time you will not need to add the datapool reference; just select start_year and click Use Column.
- Repeat the above procedure for start_day. The three variable rows
should be highlighted in green to indicate they are being substituted from the
datapool and should show references in the "Substituted with" column.
Figure 16. Variables substituted with datapool variables
- Press Ctrl-S to save the test when finished.