While serving a web page, a browser client typically downloads a set of static resources from the application which is based on the content that’s being served. For example, while navigating to a product’s page on an e-commerce website, several of that product’s images are shown. If the number of static resources vary between pages, when test data that dictates page navigation is parameterized, defining the exact number of secondary requests could become challenging. Let’s see how this can be simplified using HCL OneTest Performance’s Secondary Request Generator feature.
When secondary requests vary in quantity
Imagine that you’re browsing a shopping website. From the home page, you navigate to a specific category of products – say, books. In this section, you search for a title driven by your interest — “Test Automation”, to get a matching list of books. You click on one of the listed books that catch your eye. You are now presented with a dedicated page for this book. This page contains details designed to capture your attention, such as images, content samples, buyers’ reviews, and FAQs that are meant to aid your decision making.
Now, put on a different hat – that of a performance engineer working on the web application beneath this shopping website. If your Quality Assurance team were to load test this application, will it be acceptable to you if they have scripts that have all virtual users navigate through the same category: books, the same search criteria: “Test Automation” and select the same search result? Chances are that you are not going to be content with that; you desire reasonable variety in browsing patterns to achieve an extensive load test. Accordingly, you will want your test scripts to be driven with varying data, so that all parts of your application are exercised for coverage. Thankfully, performance testers are well attuned to the criticality of this step, and products like HCL OneTest Performance make this task a breeze. (On a side note, the HCL OneTest portfolio has a rich data fabrication capability as well.)
While some of the requests for secondary assets remain unchanged even when test data is varied, some others are not. Let’s revisit the shopping website example for an illustration. There would be no changes in the quantity of secondary requests pertaining to stylesheets or scripts — or likely even for requests that fetch reviews — when the book title is substituted with test data. This might not be the case of other secondary requests; requests for product images that need to be downloaded might vary depending on the book that was picked. Granted, tying request data to content previously provided by the server, through a process of correlation, is an integral part of test scripting. However, changing the total number of requests itself at playback will require more than simple correlation; that will require some iterative logic too. In such circumstances, one would be naturally inclined to use loops and custom code for parsing responses and controlling loops. Fortunately, this problem has superior solutions if you use HCL OneTest Performance for your testing.
HCL OneTest Performance’s secondary request generator to the rescue
HCL OneTest Performance provides an out-of-box solution to ease the task of setting up secondary requests apportioned with the requisite number of assets that need to be pulled down. The solution involves three separate steps. The first step is to identify the response which contains all the references to drive the secondary requests and create an array reference there. Note that for such secondary requests, the substitutable part of the request would typically be on the URI itself. Moreover, this part is commonly the name of an image file (something like — myBook-image1.JPG). To locate the reference value to substitute the URI fragment, do a Test Search (Ctrl + H) with the exact value of the fragment. From the search results, identify the location where the server has returned this value. Most often, this would be in a response carrying HTML content where it’s typically found within the HREF property of an IMG or an A tag. While creating the array reference, keep in mind that it is slightly different from creating a regular reference: the occurrence property of the reference must be wildcarded, using the asterisk option, instead of a specific number.
After the array reference is created, the second part begins – substitution. In the normal course, if it were to be a plain substitution, one could simply select the part of the request that is dynamic for substitution. But in this case, it isn’t a simple substitution that you are aiming for. Remember that the number of requests itself needs to be dynamic, and be driven by the number of secondary assets that the array reference points to. Accordingly, you need to do something different. Let us find out more.
Start the process by identifying the set of requests in the recorded test script that appear to pertain to the item under view. In the shopping website example, this would be the set of requests that pull down the book’s images from the server into the client. Leaving one request in the set apart, eliminate the rest of the requests by either disabling or removing them. Right-click on the request that is not disabled, and in the context-menu, select “Create Secondary HTTP Request Generator”. This will convert the request into a special one: An HTTP Secondary Request Generator.
Now comes the final part. To complete what you set out to do, substitute the request’s URI (or rarely, some other field) with the array reference created earlier. To tie everything together, you’d have to configure the HTTP Secondary Request Generator for some finer details. (For additional information on each property, and for screenshots to guide you through the process, consult the HCL OneTest Performance product knowledge centre here: https://help.hcltechsw.com/onetest/hclonetestperformance/10.2.2/com.ibm.rational.test.lt.http.doc/topics/t_create_sec_req.html?hl=secondary%2Crequest%2Cgenerator)
Performance testing with HCL OneTest Performance is all about precision. The HTTP Secondary Request Generator is one of the important, yet underutilized, features that make playback behaviour with secondary requests precise in a load test. In this blog post we learned when HTTP Secondary Request Generators come handy and how to use them.