JMeter: A Data-Driven Test Script - Part 2

This is the second post looking at a sample JMeter script; in the first we covered the basic structure of the script.  In this post we'll take a look at the request samplers and associated config and assertion elements.  Here's a look at our script tree again:


The methods of our service are divided into two groups.  The three element specific requests are grouped together beneath a Loop Controller (labelled "ElementRequests Loop") with a CSV Data config element to facilitate testing the requests using different inputs.  Each of the three element specific requests are further nested under Simple Controllers-- these are purely structural, giving each sampler its own "branch" in the tree so we can group them with their own assertions and config elements.

For the sake of comparison, the first service method (GetElementSymbol) uses a WebService (SOAP) request sampler:


In the WSDL helper section you can enter the web service's WSDL URL and click the Load WSDL button to let JMeter try to identify available services; selecting a service and clicking the Configure button automatically populates key fields like Protocol, SOAPAction, etc. (to see this behavior, try temporarily adding a new sampler in the Workbench section, entering "http://www.webservicex.net/PeriodicTable.asmx?WSDL" for the URL).  Notice that the Server Name and Path fields are blank here-- these were already specified in the HTTP Request Defaults config element near the top of our script tree; since the sampler is at a lower level, these defaults are applied to it.  This sampler also illustrates that we can use variables in component name fields ("GetElementSymbol - SOAP Request - ${ElName}")-- useful for making our results more readable.  The "Read SOAP Response" checkbox must be enabled if you intend to use response data with a listener (which we are doing here).

We still have to provide the actual body of the request-- here's the GetElementSymbol request XML:


As the documentation for the WebService (SOAP) request sampler notes (and the dialog title screams in capital letters), it's been deprecated (you can read a discussion re: deprecation of the sampler here).  The recommended technique is to make SOAP requests via the HTTP sampler.  The remaining three requests are performed with the HTTP Request sampler; here's the GetAtomicNumber sampler:


By default, an HTTP Request sampler is configured to pass a series of parameters; to use the HTTP sampler for a SOAP request, you have to switch to use the Post Body tab in the HTTP Request section and put your request there.  Additionally, the HTTP sampler is missing a few of the fields available in the SOAP request sampler (the SOAPAction field, for example) so we have to add these to our HTTP Requests using a Request Header config element with each HTTP Request.  Here's the Request Header associated with the GetAtomicNumber sampler:


Each sampler is also grouped with a Response Assertion element to check response data for expected results:


As you can see, variables can be used in assertions, which makes our data-driven technique possible: each row of our CSV data file contains an input variable (an element name passed in as a request parameter) along with variables for expected response content.

The Pattern Matching Rules section of the Response Assertion dialog warrants some clarification.  The Contains and Matches options are used when your patterns to test are regular expressions (the Matches option means the entire response needs to match your regular expression).  The Equals and Substring options are used when your patterns to test should be evaluated as literal (case-sensitive) strings (the Equals option means the entire response needs to match the provided string).  The Not checkbox essentially reverses the test-- i.e., the assertion passes if the pattern is not found or matched.