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