Test ASP. Net program with a test tool in vs. net

Use Application Center Test

First, create a simple Web ApplicationProgram. For example, I will use the page shown in figure 1 (note that I have used some tips for compiling ASP. NET pages online, and you do not need to write a complete page_load event Declaration ).

Sample Web Application

<% @ Page Language = "C #" %> <% @ Import namespace = "system. Data" %> <% @ Import namespace = "system. Data. sqlclient" %> <% @ Import namespace = "system. Configuration" %> <SCRIPT runat = "server"> Public void page_load (){ Using (sqlconnection connection = New sqlconnection (configurationsettings. receivettings ["northwind"]) { Sqlcommand command = new sqlcommand ("select * from products", connection ); Connection. open (); Datagrid1.datasource = command. executereader (); Datagrid1.databind (); } } </SCRIPT> <Form runat = "server"> <Asp: DataGrid id = "datagrid1" runat = "server"/> </Form>

The aboveCodeAlthough it is not a recommended method for constructing an application, it is simple enough to execute some basic tests on it. Open this page in a Web browser and a filled data table is returned, which is displayed as an HTML table.

Now that you know that this page can work, copy the link to the clipboard and you still need to use it. The link to this example on my computer is http: // localhost/blackbelt/outputcache/test. aspx.

Next, navigate to Application Center Test, right-click "tests (TEST)", and select "new test )". It opens the "New Test Wizard" Welcome Page. Click "Next" to selectSource codeAnd select "record new test ". Click "Next" again to select the test type. When you are prompted to select the script language (we do not modify the default value), click "Next". The interface shown in Figure 1 is displayed:

Figure 1: New Test Wizard

"Record Test" makes application center test easy to use. Click "start record" to open a new browser instance. Do not enter a URL in the address bar (it should be about: blank ). In this new browser instance, select Tools | Internet, and browse the "connection" property page. Click "LAN Settings". The page shown in Figure 2 is displayed:

Figure 2: connection settings

You will find that the proxy settings are filled and different from normal values. This is because Application Center Test opens a new browser instance and instructs it to use the dedicated proxy server running application center test. Any browser request will be captured by the Application Center Test proxy.

To complete the test, close the browser dialog box and paste the link to the ASP. NET page for the test to the address bar. Click the "go to" button in the browser or press the Enter key to display the data table again. Next, close the browser and you may see information similar to Figure 3:

Figure 3: captured requests

The request details section in the preceding dialog box is filled with the requests captured by the Application Center Test proxy. This is also an HTTP request sent by the browser. Click "Stop record" and then "Next ". You will be prompted to enter a name for the test (I used "my test"). Then you can click "finish" to close the wizard.

Congratulations! You are now a Performance Testing Engineer-very easy, right?

You can also select many other settings and configuration options. Right-click the "my test" node in the "test" list and select "properties" to view these settings. In these options, you can simulate parameters of multiple browsers, multiple users, and "warm-up" time (the results are not reported) and the test duration. You can study these settings and read about the testing principles and testing strategies.Article. We don't spend too much time on details. Run the test directly.
Run the test and establish a baseline

To run the test just created, simply right-click the test and select start test ". After the test starts, click "Show Details. The details box displays a chart of a running test and any errors that may occur during the test (Figure 5 ). The first time we run this test, we have established a baseline. We can compare it with the current and future performance. Figure 4 shows that the baseline is about 90 requests per second.

Figure 4: Baseline chart

Now that you have a definite baseline, you can make some modifications to the application to measure the performance improvement or reduction caused by the modifications. Indeed, the test examples I use are extremely simple, but I will show that a small amount of modifications to this small piece of code may have a great impact on the performance of the application.

Understand the improvements

The more aspects of evaluation, the more opportunities for improvement. In this example, I will make some minor changes to the application and evaluate it after each modification. Although in reality, you cannot perform such a test in every step of the modification, you should have the habit of periodically checking performance. For our company's Community Server product, we have a baseline for evaluating the overall application overhead. If significant changes are made, developers can use the previous test data to study performance improvement or reduction.

The first modification to the sample application is to change the limit on the returned data volume. I changed the SQL query select * from products to select top 25 * from products. This seems to be a slight modification to the code. After all, I only limit the amount of data output on the screen, but the results are amazing. Its performance has increased from 90 requests per second to more than 200-its performance has increased by more than 100%. Because you have a baseline, you know that limiting the amount of data bound to a data table will definitely affect performance. I want to modify other things.

Next, modify the <asp: DataGrid/> Server Control and add enableviewstate = "false ":

<Asp: DataGrid enableviewstate = "false" id = "datagrid1" runat = "server"/>

Viewstate is an important feature of ASP. NET, but it is not always necessary. In fact, most data tables that use viewstate do not need viewstate. In this example, by disabling viewstate, I can improve the performance by 166%. Let's continue!

Next, add the following code to activate the output buffer (outputcaching ):

<% @ Outputcache duration = "60" varybyparam = "NONE" %>

Figure 5: output buffer

Run the test again. Amazing! The performance is improved by 600%, as shown in Figure 5. You can adjust the continuous value of outputcache. For example, you can set the continuous value of outputcache to 1 second. You can see that the performance has changed a lot again.

Create a test environment

The test operation is a CPU-intensive transaction, so when you run the test, you may see that the CPU usage is close to 100%. When sharing the CPU time with the test part, it will take away the resources of the application being tested. All configuration options affect the test results. Some of them simulate the real world. For example, if SQL Server and ASP. NET are on the same computer, the network I/O overhead cannot be simulated. Most applications use databases not on Web servers.

In order to establish a real test environment, a large number of old computers used for development are used as clients. Do not use virtual machines. Run Application Center Test on these computers. Next, simulate the real world as much as possible. Run the web application on a server operating system that does not run any other applications and connect it to the database of another server.

It should be noted that there is no error in running the "smoke screen" test in the development environment. Smoke screen tests cannot simulate the real world, but can still provide a large amount of valuable data and can be used to predict the results of the same tests in the real world.

Subsequent steps and test coverage

Now you have some knowledge about how to test and evaluate your application. I recommend that you use application center test on your application. It is advantageous to know how your users can use applications in typical situations: Which pages are better executed and which pages are not improved?

For example, we run multiple types of performance tests on the Community Server. The mainline test contains anonymous and authentication information. This may significantly change performance in a large number of personalized applications.

The main line test also contains common paths throughout the system, such as network logs, charts, the main view of the Forum, and different views of each screen. Obviously, the execution of these main lines is very important, and it is best to spend a lot of time here to ensure their correctness.

If you manage or run projects that must support two or more concurrent users, and you do not know how many requests can be processed on your home page per second, you may encounter problems.

If you have a performance test script, you should evaluate it after each important modification. If the code is actually constructed by yourself, you can often go deep into the source code and evaluate the parts and recompile them. This helps you check whether the program is poorly written or not. 90% of other causes are in the data access code section.
You can also test common paths in applications. During the record test, you only need to enter the common navigation path that the user may use. Application Center test records this information and you can play the correct script again. If you like, you can edit the generated VBScript file to introduce latency or other meaningful input information to your test script.

I recommend that you do a lot of work for the final test. For example, in Community Server, our developers want to test how many post operations an application can support every minute. To test it, we do not write the content into the form, but create a new ASP. NET page, which uses APIs to input the content. Then this page runs in Application Center test, and the number of post operations supported by the application is generated every second. In other words, sometimes you may need to do more work to test all the situations.

Conclusion

I did not explain all the information provided by Application Center test, but I hope this article gives you enough knowledge to use application center test, in this way, you can use it to evaluate and improve your applications. Remember to establish baselines and frequent evaluations (at least after each major modification) and identify key parts. By following these simple rules, you will have a better understanding of the application and hope to find opportunities to improve performance.