用VS.NET中的測試工具測試ASP.NET程序
在編寫ASP.NET應用程序的時候，你會花費多長的時間來考慮性能的問題？很不幸，大多數開發者都對性能問題感到很后悔。性能的規劃和設計真的需要放在前面和中心位置。你需要考慮自己的目標，并且確保把良好的性能作為目標之一；接著你需要評估自己的程序，評估的方面越多，改善性能的機會就越大。
在本文中我將解釋微軟Visual Studio企業版中包含的一個重要工具：微軟Application Center Test。嚴肅的Web開發者都應該把這個工具放在自己的工具包中。
Application Center Test
在離開微軟之前，我參加了12個城市的ASP.NET說明會。其中一個覆蓋了性能問題，并且給很多開發者介紹了微軟Application Center Test。這個工具總是生成大量的有趣的信息，我對它有很多疑問。
你會發現Application Center Test是Application Center（可以在舊的MSDN CD或DVD中找到）的一部分，或者安裝在Visual Studio .NET企業版的Visual Studio .NET 2003Visual Studio .NET Enterprise Features目錄下面。當你第一次打開Application Center Test的時候，你可以看到一個用于導航可用的測試、結果和用戶的樹視圖。首先，我希望顯示出很容易建立測試。
使用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的知識，這樣你才能夠使用它來評估和改善自己的應用程序。請記住，建立基線、頻繁的評估（至少在每次重大的修改之后）并識別出關鍵的部分。遵循這些簡單的規則，你會對應用程序有更好的理解，并且很有希望找到提高性能的機會。
在本文中我將解釋微軟Visual Studio企業版中包含的一個重要工具：微軟Application Center Test。嚴肅的Web開發者都應該把這個工具放在自己的工具包中。
Application Center Test
在離開微軟之前，我參加了12個城市的ASP.NET說明會。其中一個覆蓋了性能問題，并且給很多開發者介紹了微軟Application Center Test。這個工具總是生成大量的有趣的信息，我對它有很多疑問。
你會發現Application Center Test是Application Center（可以在舊的MSDN CD或DVD中找到）的一部分，或者安裝在Visual Studio .NET企業版的Visual Studio .NET 2003Visual Studio .NET Enterprise Features目錄下面。當你第一次打開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的知識，這樣你才能夠使用它來評估和改善自己的應用程序。請記住，建立基線、頻繁的評估（至少在每次重大的修改之后）并識別出關鍵的部分。遵循這些簡單的規則，你會對應用程序有更好的理解，并且很有希望找到提高性能的機會。