用VS.NET中的測試載入器測試ASP.NET程式

使用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 伺服器（proxy）設定資訊被填充了，並且與正常值不同。這是因為Application Center Test開啟了一個新的瀏覽器執行個體並指示它使用Application Center Test啟動並執行專用Proxy 伺服器。經過瀏覽器的任何請求都會被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的知識，這樣你才能夠使用它來評估和改善自己的應用程式。請記住，建立基準、頻繁的評估（至少在每次重大的修改之後）並識別出關鍵的部分。遵循這些簡單的規則，你會對應用程式有更好的理解，並且很有希望找到提高效能的機會。