Original address: HTTP://WWW.16ASPX.COM/ARTICLE/62
In the context of Web performance testing, the addition of loops (Loops) and Conditions (Conditions) allows developers to write more complex, smarter tests for their applications, with 64-bit agents and controllers added to the load test. Enable testers to use the available hardware resources more efficiently to generate load. In addition, the licensing of load test agents and controllers has been changed, providing more flexibility and indirect cost savings.
Web testing allows you to impersonate a user on your ASP. NET Web application to perform a set of actions – usually a defined use case, and then verify that the program's response results are consistent with the expected results, and when you have defined the Web test, you can organize them together to form a load test. Load tests allow you to see how your application behaves under pressure. This article will focus on how to perform Web tests using Visual Studio 2010, which will be covered in a separate article.
Create a Web test
Web tests are typically created using the IE Web Test toolbar, which details the user's click action on the Web application from beginning to end, and in the sample code we use in this article, our visual The studio test project is called Com.Benday.WebTesting.WebTests, and of course you can right-click on this project and choose "New Web Test" to create a new Web test.
After you add a new Web test to your project, Visual Studio will open IE, you will see the Web Test Recorder panel in your browser, and then you can go to any Web site and act as you normally would, and each of your operations will be recorded by the Web Test Recorder. As shown in 1.
Figure 1 Actions recorded by the Web Test recorder
When you want to record the operation completed, click the "Stop" button, return to Visual Studio 2010, you will see in a *.webtest file of your operation, 2 shows.
Figure 2 Record of operations in a. webtest file
More complex Web tests
The previously recorded Web test is not of much practical value, it only replays your original operation, does not check the returned value, and does not know how your application works, but it is the basis for creating more complex, more comprehensive web tests.
You can use a validation rule, extract rules, and test contexts in a Web test request to create smarter tests, check the HTML returned from the server, verify that the application is working as you expect, extract rules to check the HTML, propose values, and keep the so-called test context dictionary structure, These values can be used to respond to subsequent test requests, creating dynamic behavior and dynamic validation.
In the sample code used in this article, I provide a Web application that manages personal information, each with a name, phone number, email address, and primary key ID, as shown in Figure 3, database table structure 4, This ID value will be used in our web application to determine which person's record is displayed and edited.
Figure 3 Person class diagram
Figure 4 Person database table structure
Suppose you want to simulate a group of people creating personal information in a database through your Web application, here are the steps to create a new user:
1. Access the application in the browser.
2. Click "Create a new user".
2.1 Verify that the Create new user interface is displayed.
2.2 Verify that all text input boxes are blank, and that the ID value equals-1, if 1 indicates that you are creating a new user, as shown in 5.
Figure 5 Creating a new user
3. Enter the information for the new user, as shown in 6.
Figure 6 Entering new user information
4. Click "Save". Verify that the ID value is no longer 1, if not 1 indicates that the new user has been created successfully, as shown in 7.
Figure 7 ID value is no longer-1 after user creation succeeds
5. Return to the People list interface to verify that the newly created user is in the list, 8.
Figure 8 The newly created user is in the list
6. Open the record of the new user and verify that the content is consistent with what you entered.
If you use the Web Test Recorder, it is easy to record the most basic actions, but each time you add a user, the ID value is a primary key, so each time it changes, which makes the playback operation more complicated.
Let's start with the 2nd step, add a validation rule to check if the id value equals-1, to do this, you need to know two things: 1) which Web request launches the Create new user page, 2) displays the name of the ASP. NET label control for the ID value.
The best way to solve both of these problems is to run a Web test and then analyze the results, and the results record clearly the requests you send to the Web application and the results returned from the Web application, and by looking at the HTML content, you can determine what happens to each request, which Web controls are used, Their names are all clear, as shown in 9.
Figure 9 Click the Response tab, view the HTML, find the display ID information the name of the label control
When you know the name of the control-in this case called m_labelid– also figure out which Web request you need, right-click on the request, select "Add Validation Rule", open the Add Validation Rule dialog box, 10.
Figure 10 Adding a validation rule to a request
In Visual Studio 2010, you can use the tag text (tag Inner text) validation rule to read the value of the M_labelid control, and if you are using Visual Studio 2008, you need to write your own validation rules to get its value.
Next we create a rule to ensure that the person ID value is not equal to 1 after the save succeeds, this time you can use the Find text rule to set the discovery text to No (False) by using the (pass If text Found) property, as shown in 11. If you find that the text and value of the label control is-1, the rule validation fails, indicating that it was not saved successfully.
Figure 11 Adding a text Discovery validation rule to the Save button
You may also want to add a fetch rule to this request, extract the value of the m_labelid, and make it easy for subsequent tests to use, for this requirement, you can extract the M_labelid value using the Tag Text extraction rule (tag Inner text Extraction rule). It then puts it in the context parameter called PersonID, which is shown in 12.
Figure 12 Adding an extraction rule to a person PersonID value
Web Test parameters
When you extract the value you want, save it in the test context, you can use the Web test parameters to insert values from the test context into the Web test request, in our Web application example, the Editperson.aspx page uses a query string parameter named ID to load the person information.
When you record a Web test, it saves the value you use, so when you reload the person's information, you will find that the value in the query string parameter is a hard-coded value, as shown in 13.
Figure 13 The value of the query string parameter is hard-coded
If you click on the ID parameter, you will see its Properties dialog box, on the "Value" property, you can click the drop-down list to see all the data context values, what you need to do is to select the PersonID context value, 14, after the query string parameter value is dynamically populated.
Figure 14 Binding The PersonID context value to the ID query string parameter
Parameterization has a best practice that should be used in all Web tests – parameterized Web server addresses, especially when you intend to use these Web tests in the final load test, fortunately, there is a button in the Web Test Editor that provides this functionality, as shown in 15, after the parameterized Web server address, All Web test requests will be transferred to the parameterized Web server address.
Figure 15 Parameterized Web Server button
At the bottom of the Web test you should see a context Parameters node that expands it to see all the Web servers referenced during the test, as shown in 16, which is useful because the environment in which you run your Web tests may differ from the environment in which you run your load tests. In addition, you might associate Web tests and load tests with a daily build, and the server changes depending on your build type, even if you don't need it now, you'll like the flexibility.
Figure 16 Parameterized Web server in the context of the test
Data sources and data binding
Parameterization with data context values is just the beginning of building complex Web tests and load tests, you can also attach a data source containing test data to a Web test, and you can use parametric thinking for the data source, one line at a time for each Web test.
The simplest way to get a data source is to create a CSV file that consists of comma-separated values and import it into your Visual Studio test project, shown in 17.
Figure 17 comma-delimited data source files
After importing this CSV file, right-click on the Web test, select "Add Data Source", 18, start the Add Data Source Wizard, 19 as shown.
Figure 18 Adding a data source to a Web test
Figure 19 New Test Data Source wizard dialog box
Once you have configured your data source, you can use parameter bindings to attach data row values to your Web test requests, for example, if you want to populate the fields in the Create New user Web page with the values of the data source, you can bind the form post parameter of each TextBox control to a field in the data source. 20, 21 shown.
Figure 20 Binding The M_textfirstname post parameter to the FirstName column of the data source
Figure 21 Data-bound form post parameters
When you run a data-driven Web test, you see that the test uses a row of data from the data source every time it executes, as shown in 22, so that not only can you create a dynamic test, but you can also run tests on a large data set.
Figure 22 Performing multiple iterations of a Web test using a data source
Summary
Web performance testing is the basis for testing your Web application to ensure quality and performance, a data-driven Web performance test that brings load testing closer to the real world, and every row of data from a data source is used by the load test agent to impersonate a user to perform a similar use case, but each time the data is used differently , if the data sent to the server is the same each time, such a test is not really a test.
The enhanced Web testing and load testing features in Visual Studio 2010 Ultimate Release provide an excellent way to reduce QA cycles and quickly determine if your application works as expected if you are from Team Foundation Server 2010 automatically builds execution tests, so you can perform these high-quality tests every time you build.
The sample program referenced in this article is all source code from http://visualstudiomagazine.com/~/media/ECG/visualstudiomagazine/Code%20Download/2010/06/ Benday_webtesting_vs2010.ashx download.
Original name: Web performance Testing with Visual Studio 2010
Web Performance test: You should take VisualStudio2010.