Now, I’ll admit that all of this is technically documented on this page on MSDN, but it isn’t super obvious sometimes exactly what something should look like when it is done. And for non-technical folks, having a nice handy tutorial with images can be a huge help. I have a few client folks right now that needed something like this, so rather than only share it with them I thought I would post this on-line for everyone’s benefit. ANYONE can follow along with this, I am using a public web service. I specifically was doing this on VS 2013, but this should on any version back to 2005, so long as it is either Ultimate or Team Suite. I am assuming you already have some basic knowledge of web performance testing, but if you don’t check out this exercise first.
First identify a web service you would like to test, and choose and operation. You could also wrote your own web service, I’m not feeling THAT ambitious today. I am using a public Weather service and the “GetCityForecastByZip” operation as seen below:
1) Create an empty web performance test, so immediately stop recording when the recording tool starts up in the browser.
2) Let Visual Studio resume. Add a web service request to the empty web performance test:
3) Enter the URL for the web service via the Properties panel (“http://wsf.cdyne.com/WeatherWS/Weather.asmx”). It should look like this:
4) Grab the Soap Body from the Web Service page, it should look like this:
5) Enter “text/xml” for content type and place the soap body from your clipboard in the String body of the web service via the Properties pane. It should look like this:
6) Add a header to the service request:
7) Grab the SoapAction from the Web Service page:
8) In the Properties pane, add a key value pair of “SoapAction”, and the SoapAction from your clipboard. It should look like this:
9) Now the basics are configured, but we want to be able to pass in a zip code. To keep things easy for the first pass, let’s just hard code that sucker. I know, bad practice, but we’ll change it soon. Open the StringBody and replace the parameter with a value:
Now run the test and see weather for my town, it’s quite lovely today :)
But this is not really exciting, we should data drive this. Let’s create a data source with some zip codes to truly exercise this service.
1) Add a few rows to an excel sheet with valid and even invalid values, use a column header of Zip and save as CSV. Save someplace easy like the desktop, you’ll need to refer to it later:
2) Add a data source to your web service test:
3) Use the data source wizard to choose the CSV file that you just created, and add it to your solution. We could point to a shared repository instead, but for now let’s keep it simple and add it to our project when you are prompted to do so.
You should now see something similar to this:
4) Now we want to data drive the the Zip code rather than use a single hard coded value. To do this, we need to embed a reference to the data source inside the String Body. So where before you just hard-coded “60304” we now add a reference to the Zip field in the data source we imported with the following syntax {{DataSourceName.TableName.ColumnName}}. It should look like this:
5) Now most likely your test settings are still defaulted to running web performance tests just once. Let’s open your testsettings and make sure we spin through every row in the data source:
6) Now go to the Web Test section, and choose “One run per data source row”. Your settings should look similar to this:
7) Run the test again. It should now run once for each row, returning an appropriate response for each.
Huzzah! Super easy right? Now give it a try yourself…