Note: This is a repost from this artcile from MSDN Blogs
Visual Studio 2010 in a huge number of new features and capabilities across a wide range of disciplines. In many cases these features are small continual improvements to existing features areas and they tend to get lost in the hubbub of the big new shiny stuff. Since its first release in Visual Studio Team System 2005 the web and load testing features have quietly and steadily been improved in each release. Each time we have added more functionality and more valuable to one of the least marketed but potentially most valuable parts of the suite. In this post I will cover one of the small features that I believe will have a big impact on users that are writing Web Performance Tests (formerly Web Tests).
In the previous two releases of Visual Studio Team System (new Visual Studio ALM Tools) if a user wanted to put any conditional logic into their web tests they were forced to drop in to code. While this is not too big of a deal on the surface, as soon as you drop into code you loose a lot of productivity that the visual editor affords you. In addition there are many cases were the person writing the web test is not a developer and they do not have knowledge to write in C# or VB.NET code. In that case they had no ability to have condition or looping logic in their web tests.
In Visual Studio 2010 you now have the ability to add both branches and loops into your declarative web tests, in addition you have the ability to create your own conditional rules to control your branching and looping logic.
Adding a loop to your web test
Lets take the example of a simply web test on our ecommerce web site. In this test we want to simulate a user that is simply browsing our catalog.
As you can see we have only two requests, one to the product list page and one to the product details page. While this test is all a browsing customer will do you our site, it is not a very good representation of that customer. In the current test each customer will browse only 1 product and it will always be the same product of the same category. Let’s see if we can make it a little more repetitive of what we might expect.
The first thing we would do for this test is to databind it to a list of products so we can as least have the user browse a different product each time.
After this modification each time a user runs this test they will at least browse for a different category of products and a different product. However, in most cases we hope that a user will spend more than just a few seconds on our site and we would like them to browse more than one Item. In previous releases of Visual Studio you would have two options.
The first option would be to drop into code, however, that has a bunch of drawbacks on productivity so we don’t want to go that route. The second option would be to add a bunch of requests to the products list and product details page. While this would work we would be stuck with each user executing the same number of requests per test iteration and in each of those requests would request the same category and the same product per test iteration as the data source cursor does not advance during the execution of the test only between iterations.
To get around these issues and create a test that is more realistic to a browsing customer on our site we will add a loop around the two key requests.
Right-click on the request where you want the loop to start and select “Insert Loop…” from the context menu to launch the “Add Conditional Rule and Items to the Loop” dialog.
As you can see in the dialog there are a variety of different conditional rules you can use to control the flow of your loop. There are some basic loops like the “For Loop” or simple “Counting Loop” that will execute the selected requests a specific number of times before exiting. In our cases we want to simulate a broad set of our browsing customers so we want a loop that will execute the set of requests a random number of times so we have picked a “Probability Rule”.
The “Probability Rule” will execute our loop based on a percentage so such that each time the loop comes around it will “roll the dice” and if it returns true the loop will execute and if it returns false it will not. In our site we have determined that 70% of the time our customers look at more than 1 product when they are browsing so we will put that number in.
There are a couple of other properties on this rule that are interesting:
The first one is the “Advance Data Cursors”. When set to “True” as we have here this tells the engine to advance the cursor on our data source forward with each iteration of the loop. This has the effect of having the user browser for a different category and product each time they execute the requests in the loop. The second on is “Max Number of Iterations”. This will force the loop to execute after a maximum number of iterations, in this case 8, as been reached regardless of the outcome of the processing of the conditional rule.
Once we have completed the dialog we see the rule added to our test
And when we run our test we can see that our loop has executed more than once
Adding a branch to your web test
Lets take our same example of a simple web test but in this case we want the user to login into our site unless they have already logged in before.
Right-click on the request where you want to begin your branch and select “Insert Condition…” from the context menu to launch the “Add Conditional Rule and Items to Condition” dialog.
You will notice that this dialog looks exactly the same as the previous dialog right down to even having some of the same conditional rules for branches as loops. In our case we are going to select the “Cookie Exists” rule from the list, set the properties and click “Ok”.
Now that we have inserted the rule into our test we see the following:
One thing that you will have to know about branching conditional rules is sometimes you will have to negate a rule in order to get the behavior you want. In our case we will have to set “Check for Existence” to False in order to let the rule execute if the cookie is not there and not execute if the cookie is there.
Summary
Declarative branching and looping in Visual Studio 2010 allows you to build more complicated and realistic web tests without having to resort to code. This lets you maintain the high level of productivity of the visual editor for web tests and lets those non-coder users have more power.