用VS.NET中的测试工具测试ASP.NET程序
使用Application Center Test
首先，建立一个简单的Web应用程序。例如，我将使用图1所示的页面（请注意，我使用了一些联机编写ASP.NET页面的小技巧，你不需要编写完整的Page_Load事件声明）。
示例Web应用程序
上面的代码虽然不是推荐的用于构造应用程序的方法，但是它也足够简单，我们能够在它上面执行一些基本的测试。在Web 浏览器中打开这个页面会返回一个填充了的数据表格，它显示为HTML表格。
现在你知道这个页面可以工作了，把链接复制到剪贴板上，你还需要使用它的。在我的计算机上这个例子的链接是http://localhost/blackbelt/outputcache/test.aspx。
下一步，导航到Application Center Test，右键点击"Tests（测试）"并选择"New Test（新建测试）"。它会打开"新建测试向导"欢迎页面。点击"下一步"选择新测试的源代码，并选中"记录新测试"。再次点击"下一步"以选择测试类型，提示选择脚本语言（我们不修改默认值）的时候，点击"下一步"，出现了图1所示的界面：
"记录测试"使Application Center Test易于使用。点击"开始记录"会打开一个新的浏览器实例。不要在地址栏中输入URL（应该为about:blank）。我们的操作是，在这个新的浏览器实例中选择Tools | Internet选择，并浏览"连接"属性页。接着点击"局域网设置"按钮，会看到图2所示的界面：
你会发现代理服务器（proxy）设置信息被填充了，并且与正常值不同。这是因为Application Center Test打开了一个新的浏览器实例并指示它使用Application Center Test运行的专用代理服务器。经过浏览器的任何请求都会被Application Center Test代理捕捉到。
为了完成测试，请关闭浏览器对话框并把用于测试的ASP.NET页面的链接粘贴到地址栏中。点击浏览器的"转到"按钮或直接按下回车键，再次出现了数据表格。下一步，关闭浏览器，你可能看到与图3类似的信息：
上面的对话框中的请求的详细信息部分现在被Application Center Test代理捕捉到的请求所填充了。这也是浏览器发送的HTTP请求。现在点击"停止记录"，接着点击"下一步"。你会得到一个提示，需要给该测试输入一个名称（我用的是"My Test"），接着你可以点击"完成"关闭向导。
恭喜你！你现在是一个性能测试工程师了--很容易，对吗？
你还可以选择很多其它的设置信息和配置选项。你右键点击"测试"列表中的"My Test"节点并选择"属性" 可以看到这些设置。在这些选项中你可以模拟多个浏览器、多个用户、"热身"时间的参数（不会被报告其结果）以及测试的持续时间。你可以以后研究这些设置并阅读一些讨论测试原理和测试策略的文章。我们不在细节上花费太多时间，直接运行测试吧。
运行测试并建立基线
要运行刚才建立的测试，只需要简单地右键点击该测试并选择"开始测试"。测试开始以后，点击"显示详细信息"按钮。细节框中将显示正在运行的测试的一个图表，同时显示在运行测试过程中可能出现的任何错误（图5所示）。第一次运行这个测试建立了基线，我们可以把它与当前的和未来的性能进行对比。图4显示的基线是每秒大约90个请求。
现在你拥有了一个确定的基线了，你可以对应用程序作一些修改以测量修改所引起的性能提升或降低。的确，我使用的测试示例极其简单，但是我会显示出对这一小段代码进行少量的修改可能对应用程序的性能产生很大的影响。
了解改善的部分
评估的方面越多，改善的机会就越大。在例子中我将对应用程序作一些小的修改，并在每个修改之后进行评估。尽管在现实情况下你不可能每步修改都进行这样的测试，但是你应该有周期性检查性能的习惯。对于我们公司的Community Server产品，我们拥有一套用于评估总体应用程序开销的基线。如果进行了重大的修改，开发者就可以使用前面的测试数据来研究性能的提升或降低。
我对示例应用程序的第一处修改是改变返回数据量的限制。我把SQL查询SELECT * FROM Products改变为SELECT TOP 25 * FROM Products。这好像只是对代码进行了微小的修改。毕竟我只是限制屏幕中输出的数据量，但是其结果却是惊人的。其性能从每秒90个请求上升到200以上--性能提高了100％以上。由于你拥有基线，你知道了限制绑定到数据表格的数据量一定会影响性能。我还要修改其它一些东西。
下一步，修改＜asp:DataGrid/＞服务器控件，添加EnableViewState="false"：
ViewState是ASP.NET的一个重要的特性，但是并非总是需要的。实际上，大多数使用了ViewState的数据表格都是不需要它的。在例子中，通过禁止ViewState，我可以提高166％的性能。我们继续！
下一步，添加下面的代码以激活输出缓冲（OutputCaching）：
现在重新运行该测试。太惊人了！性能提高了600％，如图5所示。你可以调整OutputCache的持续数值，例如把OutputCache的持续值设置为1秒--你可以看到性能再次有很大的变化。
建立测试环境
测试操作是CPU密集型的事务，因此在运行测试的时候，你可能看到CPU的占用率接近100％。它在与测试部件分享CPU时间的时候会拿走正在测试的应用程序的资源。所有的配置选项都会影响测试结果，其中一部分模拟现实世界要真实一些。例如，如果SQL Server和ASP.NET在同一台计算机上，就无法模拟网络I/O的开销。大多数应用程序使用的数据库都不在Web服务器上。
为了建立真实的测试环境，把大量的旧的用于开发的计算机作为客户端使用。不要使用虚拟机。在这些计算机上运行Application Center Test。下一步尽可能地模拟现实世界。在一个没有运行其它任何应用程序的服务器操作系统上运行该Web应用程序，并且连接到另一台服务器的数据库。
需要说明的是，在开发环境中运行"烟幕"测试也没有什么错误。烟幕测试不能模拟现实世界，但是仍然可以提供大量的有价值的数据，并且可以用于预计在现实世界中同样的测试产生的结果。
后续的步骤和测试覆盖
现在你对如何测试和评估有了一些了解了，我推荐你在自己的应用程序上使用Application Center Test。了解你的用户在典型情况下如何使用应用程序是有好处的：哪些页面执行得更好，哪些页面没有改善？
例如，在Community Server中我们运行了多种类型的性能测试。主线（Mainline）测试包含了匿名和验证的情况。在大量个性化的应用程序中这一点可能显著的改变性能情况。
主线测试还包含了贯穿系统的通用路径，例如网络日志、图表、论坛的主视图，以及每个屏幕的不同视图。很明显，这些主线情形良好的执行情况是非常重要的，最好在这儿花费大量的时间以确保其正确性。
如果你管理或运行那些必须支持两个或多个并发用户的项目，并且你不知道自己的主页面每秒钟可以处理多少个请求，那么就遇到问题了。
如果你拥有性能测试脚本，那么在每次重要的修改之后都应该进行评估。如果实际上是你自己构造的代码，那么就可以经常深入源代码并且评价各部分和重新编译。这可以帮助你检查出问题在于程序编写得不好还是其它的原因。其它的原因有90％都出在数据访问代码部分。
你还可以测试应用程序中的通用路径。记录测试的时候，只需要输入用户可能使用的通用导航路径。Application Center Test将记录下这些信息，并且你可以重新播放准确的脚本。如果你喜欢，可以编辑生成的VBScript文件，给你的测试脚本引入延迟或其它有意义的输入信息。
我推荐的最后的测试需要做很多工作。例如，在Community Server中我们的开发者希望测试应用程序可以每分钟可以支持多少个post（张贴）操作。为了测试它，我们不是把内容写入窗体，而是建立一个新ASP.NET页面，它使用API来输入内容。接着这个页面在Application Center Test中运行，应用程序支持的每秒钟张贴操作的数量就产生了。换句话说，有时候为了测试所有的情形，你可能需要多做一些工作。
结论
我没有解释Application Center Test提供的所有信息，但是我希望本文给了你足够的使用Application Center Test的知识，这样你才能够使用它来评估和改善自己的应用程序。请记住，建立基线、频繁的评估（至少在每次重大的修改之后）并识别出关键的部分。遵循这些简单的规则，你会对应用程序有更好的理解，并且很有希望找到提高性能的机会。
首先，建立一个简单的Web应用程序。例如，我将使用图1所示的页面（请注意，我使用了一些联机编写ASP.NET页面的小技巧，你不需要编写完整的Page_Load事件声明）。
示例Web应用程序
| ＜%@ 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.AppSettings["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＞ |
上面的代码虽然不是推荐的用于构造应用程序的方法，但是它也足够简单，我们能够在它上面执行一些基本的测试。在Web 浏览器中打开这个页面会返回一个填充了的数据表格，它显示为HTML表格。
现在你知道这个页面可以工作了，把链接复制到剪贴板上，你还需要使用它的。在我的计算机上这个例子的链接是http://localhost/blackbelt/outputcache/test.aspx。
下一步，导航到Application Center Test，右键点击"Tests（测试）"并选择"New Test（新建测试）"。它会打开"新建测试向导"欢迎页面。点击"下一步"选择新测试的源代码，并选中"记录新测试"。再次点击"下一步"以选择测试类型，提示选择脚本语言（我们不修改默认值）的时候，点击"下一步"，出现了图1所示的界面：
图1：新建测试向导 |
"记录测试"使Application Center Test易于使用。点击"开始记录"会打开一个新的浏览器实例。不要在地址栏中输入URL（应该为about:blank）。我们的操作是，在这个新的浏览器实例中选择Tools | Internet选择，并浏览"连接"属性页。接着点击"局域网设置"按钮，会看到图2所示的界面：
图2：连接设置 |
你会发现代理服务器（proxy）设置信息被填充了，并且与正常值不同。这是因为Application Center Test打开了一个新的浏览器实例并指示它使用Application Center Test运行的专用代理服务器。经过浏览器的任何请求都会被Application Center Test代理捕捉到。
为了完成测试，请关闭浏览器对话框并把用于测试的ASP.NET页面的链接粘贴到地址栏中。点击浏览器的"转到"按钮或直接按下回车键，再次出现了数据表格。下一步，关闭浏览器，你可能看到与图3类似的信息：
图3：捕捉到的请求 |
上面的对话框中的请求的详细信息部分现在被Application Center Test代理捕捉到的请求所填充了。这也是浏览器发送的HTTP请求。现在点击"停止记录"，接着点击"下一步"。你会得到一个提示，需要给该测试输入一个名称（我用的是"My Test"），接着你可以点击"完成"关闭向导。
恭喜你！你现在是一个性能测试工程师了--很容易，对吗？
你还可以选择很多其它的设置信息和配置选项。你右键点击"测试"列表中的"My Test"节点并选择"属性" 可以看到这些设置。在这些选项中你可以模拟多个浏览器、多个用户、"热身"时间的参数（不会被报告其结果）以及测试的持续时间。你可以以后研究这些设置并阅读一些讨论测试原理和测试策略的文章。我们不在细节上花费太多时间，直接运行测试吧。
运行测试并建立基线
要运行刚才建立的测试，只需要简单地右键点击该测试并选择"开始测试"。测试开始以后，点击"显示详细信息"按钮。细节框中将显示正在运行的测试的一个图表，同时显示在运行测试过程中可能出现的任何错误（图5所示）。第一次运行这个测试建立了基线，我们可以把它与当前的和未来的性能进行对比。图4显示的基线是每秒大约90个请求。
图4：基线图表 |
现在你拥有了一个确定的基线了，你可以对应用程序作一些修改以测量修改所引起的性能提升或降低。的确，我使用的测试示例极其简单，但是我会显示出对这一小段代码进行少量的修改可能对应用程序的性能产生很大的影响。
了解改善的部分
评估的方面越多，改善的机会就越大。在例子中我将对应用程序作一些小的修改，并在每个修改之后进行评估。尽管在现实情况下你不可能每步修改都进行这样的测试，但是你应该有周期性检查性能的习惯。对于我们公司的Community Server产品，我们拥有一套用于评估总体应用程序开销的基线。如果进行了重大的修改，开发者就可以使用前面的测试数据来研究性能的提升或降低。
我对示例应用程序的第一处修改是改变返回数据量的限制。我把SQL查询SELECT * FROM Products改变为SELECT TOP 25 * FROM Products。这好像只是对代码进行了微小的修改。毕竟我只是限制屏幕中输出的数据量，但是其结果却是惊人的。其性能从每秒90个请求上升到200以上--性能提高了100％以上。由于你拥有基线，你知道了限制绑定到数据表格的数据量一定会影响性能。我还要修改其它一些东西。
下一步，修改＜asp:DataGrid/＞服务器控件，添加EnableViewState="false"：
| ＜asp:DataGrid EnableViewState="false" id="DataGrid1" runat="server" /＞ |
ViewState是ASP.NET的一个重要的特性，但是并非总是需要的。实际上，大多数使用了ViewState的数据表格都是不需要它的。在例子中，通过禁止ViewState，我可以提高166％的性能。我们继续！
下一步，添加下面的代码以激活输出缓冲（OutputCaching）：
| ＜%@ OutputCache Duration="60" VaryByParam="none" %＞ |
图5：输出缓冲 |
现在重新运行该测试。太惊人了！性能提高了600％，如图5所示。你可以调整OutputCache的持续数值，例如把OutputCache的持续值设置为1秒--你可以看到性能再次有很大的变化。
建立测试环境
测试操作是CPU密集型的事务，因此在运行测试的时候，你可能看到CPU的占用率接近100％。它在与测试部件分享CPU时间的时候会拿走正在测试的应用程序的资源。所有的配置选项都会影响测试结果，其中一部分模拟现实世界要真实一些。例如，如果SQL Server和ASP.NET在同一台计算机上，就无法模拟网络I/O的开销。大多数应用程序使用的数据库都不在Web服务器上。
为了建立真实的测试环境，把大量的旧的用于开发的计算机作为客户端使用。不要使用虚拟机。在这些计算机上运行Application Center Test。下一步尽可能地模拟现实世界。在一个没有运行其它任何应用程序的服务器操作系统上运行该Web应用程序，并且连接到另一台服务器的数据库。
需要说明的是，在开发环境中运行"烟幕"测试也没有什么错误。烟幕测试不能模拟现实世界，但是仍然可以提供大量的有价值的数据，并且可以用于预计在现实世界中同样的测试产生的结果。
后续的步骤和测试覆盖
现在你对如何测试和评估有了一些了解了，我推荐你在自己的应用程序上使用Application Center Test。了解你的用户在典型情况下如何使用应用程序是有好处的：哪些页面执行得更好，哪些页面没有改善？
例如，在Community Server中我们运行了多种类型的性能测试。主线（Mainline）测试包含了匿名和验证的情况。在大量个性化的应用程序中这一点可能显著的改变性能情况。
主线测试还包含了贯穿系统的通用路径，例如网络日志、图表、论坛的主视图，以及每个屏幕的不同视图。很明显，这些主线情形良好的执行情况是非常重要的，最好在这儿花费大量的时间以确保其正确性。
如果你管理或运行那些必须支持两个或多个并发用户的项目，并且你不知道自己的主页面每秒钟可以处理多少个请求，那么就遇到问题了。
如果你拥有性能测试脚本，那么在每次重要的修改之后都应该进行评估。如果实际上是你自己构造的代码，那么就可以经常深入源代码并且评价各部分和重新编译。这可以帮助你检查出问题在于程序编写得不好还是其它的原因。其它的原因有90％都出在数据访问代码部分。
你还可以测试应用程序中的通用路径。记录测试的时候，只需要输入用户可能使用的通用导航路径。Application Center Test将记录下这些信息，并且你可以重新播放准确的脚本。如果你喜欢，可以编辑生成的VBScript文件，给你的测试脚本引入延迟或其它有意义的输入信息。
我推荐的最后的测试需要做很多工作。例如，在Community Server中我们的开发者希望测试应用程序可以每分钟可以支持多少个post（张贴）操作。为了测试它，我们不是把内容写入窗体，而是建立一个新ASP.NET页面，它使用API来输入内容。接着这个页面在Application Center Test中运行，应用程序支持的每秒钟张贴操作的数量就产生了。换句话说，有时候为了测试所有的情形，你可能需要多做一些工作。
结论
我没有解释Application Center Test提供的所有信息，但是我希望本文给了你足够的使用Application Center Test的知识，这样你才能够使用它来评估和改善自己的应用程序。请记住，建立基线、频繁的评估（至少在每次重大的修改之后）并识别出关键的部分。遵循这些简单的规则，你会对应用程序有更好的理解，并且很有希望找到提高性能的机会。