Documente Academic
Documente Profesional
Documente Cultură
html
http://www.packtpub.com/article/load-testing-using-visual-studio-2008-part1
LOAD TESTING the idea behind the load test is simulating that multiple users execute the logic of the solution simultaneously. The primary goal of the load test is to discover scalability and performance issues in the solution. Testing the solution also gives benchmark statistics on performance as the solution modified or extended. The tester creates a load test in the VSTS environment using a wizard that steps through the process of defining a load test scenario. A scenario is a certain situation of the use of the application and is defined with a load pattern, test mix, browser mix, and network mix. The load pattern defines how the load is applied to the application and has two flavours, a constant and a step load definition. The constant load definition applies a continuous load of users on the applications. For example, when the tester sets the maximum user count setting on 50, the load test continuously simulates 50 users stressing out the applications. This option is useful for peak usage testing and stability testing to see how the system performs under constant peak stress. The step load definition starts the load test with a small number of users and adds a predefined amount each step until the maximum is reached, or the system performs badly, or the solution falls over. This option is suitable for testing the performance limitations of the system, like the maximum number of users is before the system falls. The test mix defines which tests are included in the load test and how they are distributed. The tester can select all the automated test types that are stored in the test projects of the solution. When selecting more than one test, the tester needs to define what percentage of the total load capacity should be executing each test, as shown in the figure below.
The browser mix to define the kinds of browser to use for web tests. The browsers types include various versions of Microsoft Internet Explorer, Netscape, Mozilla, Pocket Internet Explorer, and smartphones profiles. The network mix defines the kinds of network types are simulated, and ranges from LAN, dial-up through T3 connections for the load test. After finishing the New Load Test Wizard, VSTS gives the tester an overview of all properties of the load test as depicted in the figure below.
After defining the way to test the load on the system, the tester needs to identify wha information is important to collect during the test. Setting these so calle counter set is difficult task of the tester. Fortunately VSTS provides default counter sets to simplify the creatio of the load test Finally, the tester has to set the load tests Run Settings, where it is decided how much time th test needs to warm up, how long the test runs, and what the sample rate is. The warming up tim is the time between the start of the test and the first sample to be taken of the counters. Fo example, the system starts slow the first minute due to the lack of caching files and the teste does not want this warming up to influence the test results The sample rate is the time interval how often the counters are sampled. For instance, the teste prescribes VSTS to take test data samples of the counters every ten seconds During the execution of the load test, the tester is able to monitor the counters in real time an add or remove counters. The tests results, as shown in the figure below, are presented in table and graphs, which also can be modified during the test run by adding or removing counters
The test results are stored in a database or XML-file on the Visual Studio Team Foundatio Server to be available to all the team members or other stakeholders. From a failed test, a tester i able to create a bug work item that is linked to these test results to be addressed to a developer The VSTS project portal website provides the managers and other team members with extensiv test and bug-tracking reports to track bug work items Test Load Agen For large - scale applications, one computer might not be enough to simulate the desired load Visual Studio Team System 2008 Test Load Agent can distribute the work across differen machines. It can simulate approximately 1,000 users per processor. This product requires a
separate installation and requires one controller and at least one agent. To configure the environment select Administer Test Controller from the Test menu. There you can select a Controller and add Agents. Then from the Test Run Configuration window in the Controller and Agent node you can select to run the tests remotely and select the configured controller.
http://www.packtpub.com/article/load-testing-using-visual-studio-2008-part1
There are several papers available on the internet that addresses 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. I will begin by providing 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. 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.
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.
self-sorting naming convention can make future reporting across several .webtest (s) extremely easy. For example:
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.
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.
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.
Constructing .loadtest
The primary components of any .loadtest are the .webtest (s) that simulates the behavior of the business. The .loadtest packages these .webtest (s) into scenarios and then allows you to change the load profile of the group of .webtest (s) contained within that scenario. Within the test project that
contains your .webtest (s) you can add a new .loadtest this request invokes the .loadtest wizard. The .loadtest wizard walks you through the process of Instrumenting the Scenario, Counter Sets, and Run Settings.
Instrumenting a Scenario
Scenarios act to package .webtest (s) into user groups that share a common load profile. Each scenario can be instrumented in terms of: thinktime, load pattern, test mix, browser mix, and network mix. Once again, the .loadtest wizard will walk you through the actual instrumentation of the scenario and all instrumentation can be adjusted once the scenario exists.
Instrumenting a .loadtest
The overall analysis and execution profile of a .loadtest can be controlled by selecting appropriate counter sets, setting counter thresholds, and selecting appropriate run settings.
Executing .loadtest
VSTS executes .loadtest the same way it does .webtest (s) - the most significant difference being the type of real time information being supplied during execution. In the case of a .webtest the results focus on the request / response sequence while in a .loadtest the focus is on the metrics being captured and the load being applied. The test editor will show the progress during the test run and the results of the run can be opened anytime after the run is complete.
Graph view
The graph gives a high-level view of the test result, but I find the supplied graphs to be somewhat misleading and difficult to read. If you are going to
use Graphs to communicate the load test results, keep them simple and ensure the scales are clearly understood.
Table view
The table view of the load test results is much clearer and more precise than the graph view but the amount of information can be somewhat overwhelming. I suggest using the table view to identify specific performance issues to support but not directly communicate performance test findings.
Summary view
The summary view gives an overall performance report for the current .loadtest run. It reports on: Test Results, Page Results, Transaction Results, System under Test Resource consumption, Controller Resource consumption, and finally Agent Resource consumption.