Replaying a testcase as recorded is useful in many scenarios, but it has its limitations. In many situations, it is desirable for the Virtual Users (VUs) to perform slight variations in order to more accurately judge the performance of an application. For instance, the VU might sign onto the system using different username/password combinations. Or the VU might use different words when performing a search.
The process of configuring a testcase to submit slightly different information is referred to as Customizing the testcase.
The process usually consists of:
Step 1 is accomplished by importing or creating data in a Dataset. The data may also be edited later. These topics are addressed separately.
Step 2 will be the focus of this section.
Step 3 is accomplished using the testcase editor. See the section on editing testcase content for details.
In a typical web application, there are a number of ways that application data flows between the browser and server. The most common are:
Cookies rarely need any customization because the testcases are automatically configured to handle cookies the same way that the browser would. This happens without any intervention from the user and as a result, there is little customization provided in the GUI.
Note that the automatic configuration supports cookies that are set by the server and received/returned by the browser via the HTTP headers. If the cookies are set or modified using Javascript (or any other client-side scripting mechanism), the testcase may need special configuration using a Cookie Processor.
HTTP headers also rarely need customization by the user. However, support is provided for some simple customizations. See the Headers View for instruction on configuring modifiers on HTTP headers.
A query parameter is a part of the URL submitted in the HTTP start-line. In this example:
http://finance.yahoo.com/q?s=ibm
s=ibm is a query parameter. The parameter has a name (s) and a value (ibm).
A modifier may be configured for a query parameter in two ways:
This is the most commonly-customized item in a testcase. This is how, for example, a testcase might be customized to submit different keywords in the search function of a website.
A form field is part of the HTML in a web page that allows a user to enter data into the page and submit it back to the server. There are a number of variations on this theme, including hidden fields that are not editable by the server (they are usually pre-populated by the server when the page is sent). All the fields submitted to the server may be viewed and edited from the Fields View.
A file upload field is part of an HTTP POST where the application is sending a file to the server. These fields can be modified for data replacement using the Fields View. For more detailed information on setting up data replacement, see File Uploads.
When the HTTP request contains the content-type multipart/related or post a single raw block of data, the part can be modified for data replacement using the Fields View. For more detailed information on setting up data replacement, see Part/Post Content.