Table of contents
1. Building, using tests on Microsoft VSTS: .webtests
2. Tutorial: Using Microsoft VSTS .loadtest
Microsoft Visual Studio Team System 2008 (VSTS) has become a mature load testing tool for web-enabled applications. Its strength comes from combining an integrated development environment and a testing framework that supports load testers who may or may not be .NET developers. In my experience VSTS is a good candidate for any organization moving into load testing of web-enabled applications, especially when Visual Studio .NET is the development platform of choice.
In this tutorial, I will begin with a brief overview on how to create a VSTS .webtest, followed by an overview on how to craft a VSTS .loadtest. During this overview we will introduce VSTS technical tips that will help you use VSTS more effectively or, at least, provide alternative routes for successfully employing VSTS for load testing web applications.
There are several papers available on the Internet that address the process of creating a VSTS .webtest and using .webtest(s) to create one or more VSTS .loadtest (s) I will not attempt to duplicate the content of these articles.
VSTS webtest
Recording a .webtest
VSTS Web Testing supports recording activity against an existing website. This is accomplished using a traditional play-and-record process that allows us to record new web tests in a new or existing test project. Recordings are saved once the browser window is closed we can then instrument the recording from within the VSTS.
Recording Tip 1: Comments
Insert comments during the recording process to capture the intent of each event as it occurs. The intent may not be so obvious once you are looking at a s...
To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
tream of http requests without an interface to use as a reference.
Recording Tip 2: Think Time
Think Time is the property that defines the user wait time between requests. Always try to approximate typical user think time these values can have significant impacts on the run characteristics of future test runs. If you don't believe the think times are appropriate adjust them after recording.
Instrumenting a .webtest
The recorded .webtest certainly provides the raw .webtest framework. This framework needs to be appropriately instrumented, modified, and customized to meet your load testing needs.
Instrument Tip 1: Transactions
Transactions allow you to package http requests into logical packages. Transactions are used when reporting on a .loadtest run using a consistent self-sorting naming convention can make future reporting across several .webtest(s) extremely easy. For example:
application_Business Event_Step_Page
HelpApplication_Login_01_Homepage
Instrument Tip 2: Validation Rules
Validation rules examine the HTTP response and check that it is performing as expected. There are several validation rules provided with VSTS, but the most useful one, in my experience, validates the existence of a text string in the given response (ValidationRuleFindText). If a validation rule fails, the request will be marked as failed - the Details tab will provide an explanation for what failed.
The validation rules provide several mechanisms to ensure the expected behavior has occurred it is important to remember that you are not functionally testing the application you are testing the architecture. To date the most useful and consistent are:
Maximum Request Time to validate the response occurred within X ms.
Response URL to validate the URL is the one that is expected (if this can be predicted).
Find Text to validate text contained within the response.
Instrument Tip 3: Extraction Rules
Extraction rules capture a response value to be used later usually within a request. VSTSautomatically adds an ExtractHiddenFields rule when data is posted back in the second request. While this ability certainly helps support later executions of the .webtest it does not address (catch) all correlation issues fortunately VSTS comes preloaded with several extraction rules and the ability to extend the extraction rules.
Instrument Tip 4: Binding Test Data
Extraction and validation rules provide for data capture/entry within the Properties window. Text can be pulled from a database making it possible to create a data driven .webtest that can be leveraged when creating a .loadtest. Parameters associated with the data source are associated with a column in the data source on consumption of the data row the value of that row/column will be assigned to the parameter. This is a very powerful tool when creating a data driven .webtest that becomes even more important when the .webtest is included within a .loadtest.
Instrument Tip 5: Consuming Test Data
There are several ways to consume Test Data: random, unique, and sequential. Unique is very useful for standalone execution of the .webtest to detect and remove data issues before a performance run. Sequential supports formal performance runs, if the data set is large enough to support the user load you should not encounter data collisions - remember the setting in the ".webtest" is what is used by the ".loadtest".
Executing a .webtest
Executing a .webtest as a data driven test will enable you to detect issues before they are presented during .loadtest execution. It should be noted that the .webtest is the framework upon which a .loadtest executes (transactions, extractions, validations, and data). It is important to ensure the .webtest is stable before incorporating it into your .loadtest.
Execution Tip 1: Verification
Verification occurs only as it has been defined within the .webtest this means that a .webtest with no verification rules will always pass not matter what the actual behavior of the application. Thoroughly test the behavior of the .webtest verifying requests and responses are behaving as expected and that adequate verification rules have been applied.
Next: Load testing with Microsoft VSTS
About the author: David W Johnson "DJ" is a senior test architect with over 22 years of experience in information technology across several industries having played key roles in business needs analysis, software design, software development, testing, training, implementation, organizational assessments, and support of business solutions.
