隨著 Internet 的日益普及，現在基于 B/S 結構的大型應用越來越多，可如何對這些應用進行測試成為日益迫切的問題。有許多測試人員來信問我 B/S 的測試如何做，由于工作較繁忙，對大家提出的問題也是頭痛醫頭腳痛醫腳，沒有對 Web 的測試過程做一個整體的概述。希望通過本篇能夠讓大家了解大型 Web 應用是如何來進行測試的。
B/S 下的功能測試比較簡單，關鍵是如何做好性能測試。目前大多數的測試人員認為只要跑一些測試工具證明我的產品是可以達到性能的就 OK 了，為了證明而去測試是沒有任何價值的，關鍵是要發現產品性能上的缺陷，定位問題，解決問題，這才是測試要做的。
首先我們從兩個方面分析如何進行 Web 測試，從技術實現上來講一般的 B/S 結構，無論是 .NET 還是 J2EE，都是多層構架，有界面層、業務邏輯層、數據層。而從測試的流程上來說，首先是發現問題，分析問題，定位問題，再由開發人員解決問題。那么 B/S 的結構的測試如何來做呢？
如何發現問題是我首先要介紹的，在做 Web 測試之前你需要一些資料，比如產品功能說明書，性能需求說明書，不一定很完善，但一定要有，明確測試目標，這是基本的常識，可是我往往看到的是已經開始動手測了，但還不知自己的系統要達到的性能指標是什么。這里我簡單講一下測試的性能指標：
通用指標（指 Web 應用服務器、數據庫服務器必需測試項）：
Processor Time：指服務器 CPU 占用率，一般平均達到 70% 時，服務就接近飽和；
Memory Available Mbyte：可用內存數，如果測試時發現內存有變化情況也要注意，如果是內存泄露則比較嚴重；
Physicsdisk Time：物理磁盤讀寫時間情況。
Web 服務器指標：
Avg Rps：平均每秒鐘響應次數=總請求時間/秒數；
Avg time to last byte per terstion（mstes）：平均每秒業務角本的迭代次數，有人會把這兩者混淆；
Successful Rounds：成功的請求；
Failed Rounds：失敗的請求；
Successful Hits：成功的點擊次數；
Failed Hits：失敗的點擊次數；
Hits Per Second：每秒點擊次數；
Successful Hits Per Second：每秒成功的點擊次數；
Failed Hits Per Second：每秒失敗的點擊次數；
Attempted Connections：嘗試鏈接數。
數據庫服務器指標：
User 0 Connections：用戶連接數，也就是數據庫的連接數量；
Number of deadlocks：數據庫死鎖；
Butter Cache hit：數據庫 Cache 的命中情況。
上面的指標只是一些通用的指標，起到拋磚引玉的作用，對于不同的應用你還必需作相應的調整，比如程序使用的是 .NET 技術的，則必需加入一些針對性的測試指標。對于這些指標的詳細了解，你可以參考 Windows 下面的 SystemMonitor 的幫助與 LoadRunner、ACT 的幫助。對于發現問題，指標的設置非常重要，它會幫你定性的發現一些錯誤。對于定性的壓力測試我就不做過多的分析，工具很多，流行的主要有 LoadRunner、ACT、WAS、WebLoad 各個工具有它的使用范圍；其中我各個認為：
LoadRunner 最全面，它提供了多種協議的支持，對復雜的壓力測試都可以勝任；
WAS 與 ACT 則對微軟的技術支持的比較好，其中 WAS 支持分布式機群測試；
ACT 則是與 .NET 集成比較好，支持 ViewState（.NET 下控件緩存的支持）的測試。
在這一階段測試你要不斷的跟據系數的測試目標進行變化，一開始由于系統過于龐大，所以我們要分成若干個子系統，各個子系統的性能目標必需明確，主要是并發指標定一個閾值，同時設定一些與系統相關的測試參數，應用服務器，數據庫服務器都要有，對達不到閾值的與一些通用參數有問題的子系統進行深入分析。比如它的并發達不到你的要求，證明子系統性能有問題，或是數據庫用戶連接過高，程序沒有釋放用戶連接等等。這個我們要對子系統進行詳細測試，由于 B/S 結構下，圖片的請求對性能的影響較大，所以我們對子系統測試時要分兩個部分進行：
非程序部分，即圖片等等；
應用程序本身。
通過事務或函數的分離，可以把這兩塊實現單獨的測試，具體做法參考各個工具的手冊，我這里就不做說明。對子系統的測試參數的設置要求則更高，它有助你后面精確的定位問題，比如對異常、死鎖、網絡流量等等前面沒有注意到的情況的增加；同時你要注意增加測試參數的收集對系統的性能影響比較大，所以一般不要超過 10 個。剛剛介紹的整體的性能測試指標也不要增加很多，這樣影響會小一點。最后在這一階段要說明的是數據庫的數據量會很大程度的影響性能，所以要根據前面的性能需求說明書向數據庫中模擬相應的數據量，來進行測試，這樣才有更高的可信度。
上面所說的是對問題的發現，下面就是分析問題原因，這一步的要求比較高，一般由測試人員與程序員配合完成，當然如果你有相當的開發經驗，再做這方面的測試，就更為難得。下面我們說說如何精確定位問題，出現問題的可能性可能有很多種，大致分以下幾種：
性能達不到目標；
性能達到目標，但有一些其它的問題，比如異常、死鎖。緩存命中過低，網絡流量較大；
服務器穩定性的問題，比如內存泄漏等。
發現這些問題起馬的要求要有一款使用的比較稱心的性能分析與優化工具，比如微軟的 .net 下就有自己開發的工具，對 Borland 的 Java 開發工具中也有類似的工具，但我個人認為更好的工具是 Rose 下的 Purify 與 Quantify，主要是他對.net 與 Java、C++ 都有支持，而且分析效果特別專業。我們先了解一下 Rational Purify。
Rational Purify 能自動找出 Visual C/C++ 和 Java 代碼中與內存有關的錯誤，確保整個應用程序的質量和可靠性。在查找典型的 Visual C/C++ 程序中的傳統內存訪問錯誤，以及 Java，C# 代碼中與垃圾內存收集相關的錯誤方面；Rational Quantity 則是一款針對函數級的性能分析利器，使用它你可以從圖形化的界面中得到函數調用的時間，百分比與次數，以及子函數所占時間，使你可以更快的定位性能瓶頸。
我們先說性能優化與異常的處理，性能優化有一個原則，即用時間比例最大的進行優化，效果才最明顯。比如有個函數它的執行時間為 30 秒，如果你優化了一百倍則執行時間為 0.3 秒，提升了 29.7 秒；而如果它的執行時間為 0.3 秒，優化后為 0.003 秒，實際提升了 0.297 秒，提升的效果并不明顯但寫過程序的人都知道，后者性能優化的代價更大。
在性能優化的過程中，一般是先數據庫，后程序。因為數據庫的優化不需要修改程序，修改的風險很小。但如何才能確定是數據庫的問題，這就需要技巧，在使用 Quantity 時，你一路分析下去，大多數最終會發現，是數據庫查詢函數占用時間比較大，比如什么 SqlCmd.ExecuteNoQuery 等等數據庫執行函數，這時你就需要分析數據庫。
數據庫的分析原則是先索引，后存儲過程，最后表結構視圖的優化。索引的優化是最簡單也是通常最有效的方法，如果合理的使用會帶來意想不到不到的效果。在這里我要給大家簡單的介紹一下我的最愛：SQLProfile、SQL 查詢分析器。
Precise SQLProfile 是一個 SQL 語句跟蹤器，可以跟蹤程序流程使用的 SQL 語句與存儲過程，結合查詢分析器對 SQL 的分析，可以對索引的優化做出很好的判斷，但索引也不是萬能的，在增刪改較多的表，索引過多會引起這些操作的性能下降，所以判斷還是需要一定的經驗。同時針對用戶使用頻度最高的 SQL 進行優化也是最行之有效的，這時我則需要 Precise，它可以觀測某一個較長時間內的 SQL 語句的執行情況。
數據庫優化的潛能挖光后，如果還是達不到性能要求或是還有問題，則要從程序來進行優化，這是程序員做的事。測試人員要做的，就是告訴他們，哪個函數執行過多引起了性能下降，比如異常過多，某個循環過多，或是 DCOM 調用過多等等，但說服程序員也是一件不容易的事，你要在這一階段做的出色一定要有幾年的編程經驗，并且要讓程序員感到聽你的性能會有提升，這是一件很不容易的事情哦。
內存的分析，一般是一個長期分析的過程，要做好不容易，首先要有長期奮戰的準備，其次內存泄漏的分析最好是放在單元測試之中同步進行，而不是要等到最后再去發現問題，當然出了問題也只好面對，一般這類問題都是在服務器運行了很久才暴露出來，一旦發現問題后，則需要定位問題，分析的原則采用子系統相互獨立運行，找到最小問題的系統集，或是借助內存分析工具觀察內存對象情況，初步定位問題，再用 Purify 進行運行時分析，通常 C++ 內存問題比較多， Java 與 .NET 比較少，一般由 GC 不合理引起。C++ 的內存錯誤就比較多了，主要常見的有：
Array Bounds Read（ABR）：數組越界讀
Array Bounds Write（ABW）：數組越界寫
Beyond stack Read（BSR）：堆棧越界讀
Free Memory Read（FMR）：空閑內存讀
Invalid pointer Read（IPR）：非法指針閱讀
Null Pointer Read（NPR）： 空指針閱讀
Uninitialized Memory Read（UMR）：未初始化內存讀寫
Memory Leak：內存泄漏
注：如果需要更多的信息，可以參見 Purify 的幫助信息。
順便提一句，為什么我要說做單元測試時做內存分析比較好，由于單元測試針對的是單一功能，這時結合單元測試案例做內存分析會更快的定位問題，同時由于問題較早的發現，則后期的風險則會減少，當然如果結合代碼覆蓋工具 PureCoverage 來做就更完美了。
注：本篇只是對 B/S 應用的測試過程作一個整體的描述，對某一個階段使用的工具只是作大概的介紹，你也可使用你比較熟悉的工具達到相同的目標。