Creating an ASMX web service web test with VSTS 2008

Right click on the test project and select Add > Web Test…

IE will be opened with the Web Test Recorder available on the left side.

Click the stop button.

Right Click on the webtest node and select Add Web Service Request.

Fill out the properties in the properties window.

If you include the full path to the web method under test, the web method query variable will be extracted and created for you.

(example: http://localhost/VSTSLoadTest/VstsLoadTestWebService.asmx?op=ReverseTheString).

Assemble the soap request (I suggest using Internet Explorer to browse the web service and capture a sample soap request.

Drill down into the web request to fill out the String Body properties.

Set the content type to text/XML.

Click the ellipses button on the string body.

Paste the soap request into the popup – make sure and modify the placeholders with actual values.

More VSTS 2008 Team Test Edition Tips and tricks.

It has been about a month since I posted any VSTS Test edition tips or tricks. Here is a few I think are particularly important.

BEST PRACTICE: Can we copy/paste (and rename) web tests if we want to? What effect does this have on the data source? Is it advisable from a source control standpoint?

Doing a copy, paste, or rename operation is totally fine. The data source will have to be added again to copied tests. Consider using extract web test rather than copy. Extracting a webtest is a way of grouping a request or requests into another callable web test. This is a very powerful feature. If you make 3 copies of a web test and the test has to change, you will have to modify all three copies of that test. Rather than doing a copy paste, use the extract web test functionality.

• Go to the test editor window
• Select the first request you want to include in the test
• Right click and select Extract Web Test…
• Enter a meaningful name in the text box
• The top drop down will contain the first request to include in the test
• Use the second drop down to select the final request you want to include in the test
• Check both check boxes at the bottom of the dialog
• Select OK

In the Test Editor you will see that the requests that you extracted are removed and replaced with a single request that points to another web test.

Now if you need to change that test you change it in one single place. This test may also be included in any other web test by right clicking in the test editor and selecting Insert Call to Web Test…

Can a web test record pop-ups?

If you are having difficulty recording pop-ups using the web recorder, try using Fiddler to capture the HTTP traffic. Once you are done executing your test and capturing the http traffic in fiddler,

• highlight the requests,
• Right click and select save select Session(s) select as Visual Studio Web Test (http://blogs.msdn.com/vstsqualitytools/archive/2006/12/21/testing-web-applications-with-pop-ups.aspx)

BEST PRACTICE: Use validation levels

During a standalone web test you want to run all validations but during a load test you want to only run the most critical validations so you can leave the client or agents to do the work they are intended to do – load the server. Execution of validation rules in a load test has impact on performance.

The default validation rule level of a request is “high”. When you create a load test you can specify what level of validation rules you want to execute under the Run Settings node. The default rule validation level of the load test is “low” therefore if you do nothing with validation levels no validations will be executed during a load test.

If you want to run a validation rule during a load test you want to change the validation level on the most critical rules to ‘‘low’’. In this case low means that it is a low-level, or fundamental, verification; low does not refer to the priority of the verification. Setting the level to ‘‘high’’ means that it will only be run if the load test has been set to a validation level of ‘‘high’’.

Load test level	Validations that will run
Low	Low
Medium	Low, Medium
High	Low, Medium, High

Load Testing with VSTS FAQ

As I mentioned in my bio, in addition to .Net consulting, I do some web and load test consulting. Here is a handful of questions that come fairly often.

Q) Connections per user or Connection Pool – Which is recommended?

A) Connection per user is ideal. It requires the most resources on the agent. If agent CPU < 75% and memory usage < 90% you should be ok. Note: the number of connections may be 2X the number of users as dependent requests may get another connection and run in parallel.
B) Connection pool means that one Web test may have to wait before issuing a request when another Web test is using the connection. The average time that a Web test waits before submitting a request is tracked by the load test performance counter Avg. Connection Wait Time. This number should be less than the average response time for a page. If it is not, the connection pool size is probably too small.
More Info: http://msdn.microsoft.com/en-us/library/ms404664(VS.80).aspx#ConnectionModel

Q) What is the difference between having multiple scenarios in a load test and different tests in a single scenario.

A) You can and should use multiple scenarios. A scenario typically mimics different “groups” of users. For example a single website might have a couple admin type users that perform 1 set of tasks and regular users that perform another set of tasks. To simulate these users you would create a scenario for each group. The scenarios, of course, can contain multiple tests and if you choose some of these tests may be in both scenarios.


Q: How is load test execution affected by data source access methods?

A: When you add data source to a Web test, you can choose from three different access options.

• Sequential - If you set a data source to sequential, it uses the records from the data source in the order it reads them in. When it reaches to end of the records, it will loop back to the beginning and start again. It will continue to do this for the duration of the load test.
• Random - If you select random, then a random row will be used for each test iteration. This will continue to happen for the duration of the load test.
• Unique - If you select unique, the load test will access the data sequentially, but it will only execute 1 test iteration for each row in the data source regardless of what the test duration is set to. So if you have 20 rows, then the load test will execute 20 tests and then stop.

For more information, see About Data Binding in Web Tests.