隨著Internet的日益普及，現(xiàn)在基于B/S結(jié)構(gòu)的大型應(yīng)用越來(lái)越多，可如何對(duì)這些應(yīng)用進(jìn)行測(cè)試成為日益迫切的問(wèn)題。有許多測(cè)試人員來(lái)信問(wèn)我B/S的測(cè)試如何做，由于工作較繁忙，對(duì)大家提出的問(wèn)題也是頭痛醫(yī)頭腳痛醫(yī)腳，沒(méi)有對(duì)WEB的測(cè)試過(guò)程做一個(gè)整體的概述。希望通過(guò)本篇能夠讓大家了解大型Web應(yīng)用是如何來(lái)進(jìn)行測(cè)試的。
        B/S下的功能測(cè)試比較簡(jiǎn)單，關(guān)鍵是如何做好性能測(cè)試。目前大多數(shù)的測(cè)試人員認(rèn)為只要跑一些測(cè)試工具證明我的產(chǎn)品是可以達(dá)到性能的ok了，為了證明而去測(cè)試是沒(méi)有任何價(jià)值的，關(guān)鍵是要發(fā)現(xiàn)產(chǎn)品性能上的缺陷，定位問(wèn)題，解決問(wèn)題，這才是測(cè)試要做的。
        首先我們從兩個(gè)方面分析如何進(jìn)行WEB測(cè)試，從技術(shù)實(shí)現(xiàn)上來(lái)講一般的B/S結(jié)構(gòu)，無(wú)論是.NET還是J2EE，都是多層構(gòu)架，有界面層，業(yè)務(wù)邏輯層，數(shù)據(jù)層。而從測(cè)試的流程上來(lái)說(shuō)，首先是發(fā)現(xiàn)問(wèn)題，分析問(wèn)題，定位問(wèn)題，再由開(kāi)發(fā)人員解決問(wèn)題。那么B/S的結(jié)構(gòu)的測(cè)試如何來(lái)做？
        如何發(fā)現(xiàn)問(wèn)題是我首先要介紹的，在做WEB測(cè)試之前你需要一些資料，比如產(chǎn)品功能說(shuō)明書(shū)，性能需求說(shuō)明書(shū)，不一定很完善，但一定要有，明確測(cè)試目標(biāo)，這是基本的常識(shí)，可是我往往看到的是已經(jīng)開(kāi)始動(dòng)手測(cè)了，但還不知自己的系統(tǒng)要達(dá)到的性能指標(biāo)是什么。這里我簡(jiǎn)單講一下測(cè)試的性能指標(biāo)：

l 通用指標(biāo)（指Web應(yīng)用服務(wù)器、數(shù)據(jù)庫(kù)服務(wù)器必需測(cè)試項(xiàng)）:
* ProcessorTime: 指服務(wù)器CPU占用率，一般 平均達(dá)到70%時(shí)，服務(wù)接近飽和；
* Memory Available Mbyte :   可用內(nèi)存數(shù)，如果測(cè)試時(shí)發(fā)現(xiàn)內(nèi)存有變化情況也要注意，如果是內(nèi)存泄露則比較嚴(yán)重；
* Physicsdisk Time  : 物理磁盤(pán)讀寫(xiě)時(shí)間情況；
l Web服務(wù)器指標(biāo)：
* Avg Rps: 平均每秒鐘響應(yīng)次數(shù)＝總請(qǐng)求時(shí)間 / 秒數(shù)；
* Avg time to last byte per terstion （mstes）:平均每秒業(yè)務(wù)角本的迭代次數(shù) ，有人會(huì)把這兩者混淆；
* Successful Rounds：成功的請(qǐng)求；
* Failed  Rounds ：失敗的請(qǐng)求；
* Successful  Hits ：成功的點(diǎn)擊次數(shù)；
* Failed  Hits ：失敗的點(diǎn)擊次數(shù)；
* Hits Per Second ：每秒點(diǎn)擊次數(shù)；
* Successful  Hits Per Second ：每秒成功的點(diǎn)擊次數(shù)；
* Failed  Hits Per Second ：每秒失敗的點(diǎn)擊次數(shù)；
* Attempted  Connections ：嘗試鏈接數(shù)；

l 數(shù)據(jù)庫(kù)服務(wù)器指標(biāo)：
* User 0  Connections ：用戶(hù)連接數(shù)，也是數(shù)據(jù)庫(kù)的連接數(shù)量；
* Number of deadlocks：數(shù)據(jù)庫(kù)死鎖；
* Butter Cache hit ：數(shù)據(jù)庫(kù)Cache的命中情況； 

        上面的指標(biāo)只是一些通用的指標(biāo)，起到拋磚引玉的作用，對(duì)于不同的應(yīng)用你還必需作相應(yīng)的調(diào)整，比如程序使用的是.NET技術(shù)的，則必需加入一些針對(duì)性的測(cè)試指標(biāo)。對(duì)于這些指標(biāo)的詳細(xì)了解，你可以參考Windows 下面的 SystemMonitor的幫助與LoadRunner、ACT的幫助。對(duì)于發(fā)現(xiàn)問(wèn)題，指標(biāo)的設(shè)置非常重要，它會(huì)幫你定性的發(fā)現(xiàn)一些錯(cuò)誤。對(duì)于定性的壓力測(cè)試我不做過(guò)多的分析，工具很多，流行的主要有
        LoadRunner，ACT，WAS，WebLoad，各個(gè)工具有它的使用范圍，其中我各個(gè)認(rèn)為L(zhǎng)oadRunner 全面，它提供了多種協(xié)議的支持，對(duì)復(fù)雜的壓力測(cè)試都可以勝任，WAS與ACT則對(duì)微軟的技術(shù)支持的比較好，其中WAS支持分布式機(jī)群測(cè)試，ACT則是與.NET集成比較好，支持ViewState （.NET 下控件緩存的支持） 的測(cè)試，當(dāng)時(shí)我用時(shí)，其它測(cè)試工具還不支持，現(xiàn)在應(yīng)該支持了吧，呵呵。在這一階段測(cè)試你要不斷的跟據(jù)系數(shù)的測(cè)試目標(biāo)進(jìn)行變化，一開(kāi)始由于系統(tǒng)過(guò)于龐大，所以我們要分成若干個(gè)子系統(tǒng)，各個(gè)子系統(tǒng)的性能目標(biāo)必需明確，主要是并發(fā)指標(biāo)定一個(gè)閥值，同時(shí)設(shè)定一些與系統(tǒng)相關(guān)的測(cè)試參數(shù)，應(yīng)用服務(wù)器，數(shù)據(jù)庫(kù)服務(wù)器都要有，對(duì)達(dá)不到閥值的與一些通用參數(shù)有問(wèn)題的子系統(tǒng)進(jìn)行深入分析。比如它的并發(fā)達(dá)不到你的要求，證明子系統(tǒng)性能有問(wèn)題，或是數(shù)據(jù)庫(kù)用戶(hù)連接過(guò)高，程序沒(méi)有釋放用戶(hù)連接等等。這個(gè)我們要對(duì)子系統(tǒng)進(jìn)行詳細(xì)測(cè)試，由于B/S 結(jié)構(gòu)下，圖片的請(qǐng)求對(duì)性能的影響較大，所以我們對(duì)子系統(tǒng)測(cè)試時(shí)要分兩個(gè)部分進(jìn)行，一、非程序部分，即圖片等等;二、應(yīng)用程序本身。通過(guò)事務(wù)或函數(shù)的分離，可以把這兩塊實(shí)現(xiàn)單獨(dú)的測(cè)試，具體做法參考各個(gè)工具的手冊(cè)，我這里不做說(shuō)明。對(duì)子系統(tǒng)的測(cè)試參數(shù)的設(shè)置要求則更高，它有助你后面精確的定位問(wèn)題，比如對(duì)異常，死鎖，網(wǎng)絡(luò)流量等等前面沒(méi)有注意到的情況的增加，同時(shí)你要注意增加測(cè)試參數(shù)的收集對(duì)系統(tǒng)的性能影響比較大，所以一般不要超過(guò)10個(gè)，剛剛介紹的整體的性能測(cè)試指標(biāo)也不要增加很多，這樣影響會(huì)小一點(diǎn)。后在這一階段要說(shuō)明的是數(shù)據(jù)庫(kù)的數(shù)據(jù)量會(huì)很大程度的影響性能，所以要根據(jù)前面的性能需求說(shuō)明書(shū)向數(shù)據(jù)庫(kù)中模擬相應(yīng)的數(shù)據(jù)量，來(lái)進(jìn)行測(cè)試，這樣才有更高的可信度。
        上面所說(shuō)的是對(duì)問(wèn)題的發(fā)現(xiàn)，下面是分析問(wèn)題原因，這一步的要求比較高，一般由測(cè)試人員與程序員配合完成，當(dāng)然如果你有相當(dāng)?shù)拈_(kāi)發(fā)經(jīng)驗(yàn)，再做這方面的測(cè)試，更為難得。下面我們說(shuō)說(shuō)如何精確定位問(wèn)題，出現(xiàn)問(wèn)題的可能性可能有很多種，大致分以下幾種，一、性能達(dá)不到目標(biāo)；二、性能達(dá)到目標(biāo)，但有一些其它的問(wèn)題，比如異常，死鎖，緩存命中過(guò)低，網(wǎng)絡(luò)流量較大；三、服務(wù)器穩(wěn)定性的問(wèn)題，比如內(nèi)存泄漏……。要發(fā)現(xiàn)這些問(wèn)題起馬的要求要有一款使用的比較稱(chēng)心的性能分析與優(yōu)化工具，比如微軟的.NET下有自己開(kāi)發(fā)的工具，對(duì)Borland的Java開(kāi)發(fā)工具中也有類(lèi)似的工具，但我個(gè)人認(rèn)為更好的工具是Rose下的Purify與Quantify，主要是他對(duì).net 與java ，C++都有支持，而且分析效果特別專(zhuān)業(yè)，我們先了解一下Rational Purify，  Rational Purify 能自動(dòng)找出Visual C/C++ 和Java 代碼中與內(nèi)存有關(guān)的錯(cuò)誤，確保整個(gè)應(yīng)用程序的質(zhì)量和可靠性。在查找典型的Visual C/C++ 程序中的傳統(tǒng)內(nèi)存訪問(wèn)錯(cuò)誤，以及Java，C# 代碼中與垃圾內(nèi)存收集相關(guān)的錯(cuò)誤方面；Rational Quantity 則是一款針對(duì)函數(shù)級(jí)的性能分析利器，使用它你可以從圖形化的界面中得到函數(shù)調(diào)用的時(shí)間，百分比與次數(shù)，以及子函數(shù)所占時(shí)間，使你可以更快的定位性能瓶頸。
        我們先說(shuō)性能優(yōu)化與異常的處理，性能優(yōu)化有一個(gè)原則，即用時(shí)間比例大的進(jìn)行優(yōu)化，效果才明顯，比如有個(gè)函數(shù)它的執(zhí)行時(shí)間為30秒，如果你優(yōu)化了一百倍則執(zhí)行時(shí)間為0.3秒，提升了29.7秒，而如果它的執(zhí)行時(shí)間為0.3秒，優(yōu)化后為0.003秒，實(shí)際提升了0.297秒，提升的效果并不明顯，而且寫(xiě)過(guò)程序的人都知道，后者性能優(yōu)化的代價(jià)更大。在性能優(yōu)化的過(guò)程中，一般是先數(shù)據(jù)庫(kù)，后程序，因?yàn)閿?shù)據(jù)庫(kù)的優(yōu)化不需要修改程序，修改的風(fēng)險(xiǎn)很小。但如何才能確定是數(shù)據(jù)庫(kù)的問(wèn)題，這需要技巧，在使用Quantity時(shí)，你一路分析下去，大多數(shù)終會(huì)發(fā)現(xiàn)，是數(shù)據(jù)庫(kù)查詢(xún)函數(shù)占用時(shí)間比較大，比如什么，SqlCmd.ExecuteNoQuery等等數(shù)據(jù)庫(kù)執(zhí)行函數(shù)，這時(shí)你需要分析數(shù)據(jù)庫(kù)，呵呵。數(shù)據(jù)庫(kù)的分析原則是先索引，后存儲(chǔ)過(guò)程，后表結(jié)構(gòu)視圖的優(yōu)化，索引的優(yōu)化是簡(jiǎn)單也是通常有效的方法，如果合理的使用會(huì)帶來(lái)意想不到不到的效果。在這里我要給大家簡(jiǎn)單的介紹一下我的愛(ài)，SQLProfile，SQL查詢(xún)分析器，Precise，SQLProfile是一個(gè)SQL語(yǔ)句跟蹤器，可以跟蹤程序流程使用的SQL語(yǔ)句與存儲(chǔ)過(guò)程，結(jié)合查詢(xún)分析器對(duì)SQL的分析，可以對(duì)索引的優(yōu)化做出很好的判斷，但索引也不是的，在增刪改較多的表，索引過(guò)多會(huì)引起這些操作的性能下降，所以判斷還是需要一定的經(jīng)驗(yàn)。同時(shí)針對(duì)用戶(hù)使用頻度高的SQL進(jìn)行優(yōu)化也是行之有效的，這時(shí)我則需要Precise，它可以觀測(cè)某一個(gè)較長(zhǎng)時(shí)間內(nèi)的SQL語(yǔ)句的執(zhí)行情況。數(shù)據(jù)庫(kù)優(yōu)化的潛能挖光后，如果還是達(dá)不到性能要求或是還有問(wèn)題，則要從程序來(lái)進(jìn)行優(yōu)化，這是程序員做的事，測(cè)試人員要做的，是告訴他們，哪個(gè)函數(shù)執(zhí)行過(guò)多引起了性能下降，比如異常過(guò)多，某個(gè)循環(huán)過(guò)多，或是DCOM調(diào)用過(guò)多等等，但說(shuō)服程序員也是一件不容易的事，你要在這一階段做的出色一定要有幾年的編程經(jīng)驗(yàn)，并且要讓程序員感到聽(tīng)你的性能會(huì)有提升，這是一件很不容易的事情哦。
        內(nèi)存的分析，一般是一個(gè)長(zhǎng)期分析的過(guò)程，要做好不容易，首先要有長(zhǎng)期奮戰(zhàn)的準(zhǔn)備，其次內(nèi)存泄漏的分析好是放在單元測(cè)試之中同步進(jìn)行，而不是要等到后再去發(fā)現(xiàn)問(wèn)題，當(dāng)然出了問(wèn)題也只好面對(duì)，一般這類(lèi)問(wèn)題都是在服務(wù)器運(yùn)行了很久才暴露出來(lái)，一旦發(fā)現(xiàn)問(wèn)題后，則需要定位問(wèn)題，分析的原則采用子系統(tǒng)相互獨(dú)立運(yùn)行，找到小問(wèn)題的系統(tǒng)集，或是借助內(nèi)存分析工具觀察內(nèi)存對(duì)象情況，初步定位問(wèn)題，再用Purify進(jìn)行運(yùn)行時(shí)分析，通常C++ 內(nèi)存問(wèn)題比較多，Java與.NET比較少，一般由GC不合理引起。C++的內(nèi)存錯(cuò)誤比較多了，主要常見(jiàn)的有:
1、 Array Bounds Read (ABR) ：數(shù)組越界讀
2、 Array Bounds Write (ABW)：數(shù)組越界寫(xiě)
3、 Beyond stack Read (BSR)：堆棧越界讀
4、 Free Memory Read(FMR)：空閑內(nèi)存讀
5、 Invalid pointer Read(IPR)：非法指針閱讀
6、 Null Pointer Read(NPR)：  空指針閱讀
7、  Uninitialized Memory Read(UMR)：未初始化內(nèi)存讀寫(xiě)
8、 Memory Leak：內(nèi)存泄漏

注：如果需要更多的信息，可以參見(jiàn)Purify的幫助信息。         順便提一句，為什么我要說(shuō)單元測(cè)試時(shí)做這個(gè)比較好，由于單元測(cè)試針對(duì)的是單一功能，這時(shí)結(jié)合單元測(cè)試案例做內(nèi)存分析會(huì)更快的定位問(wèn)題，同時(shí)由于問(wèn)題較早的發(fā)現(xiàn)，則后期的風(fēng)險(xiǎn)則會(huì)減少，當(dāng)然如果結(jié)合代碼覆蓋工具PureCoverage 來(lái)做更完美了，呵呵。
       完成此文，已經(jīng)是凌晨了，也算是回答了前一段時(shí)間提出要進(jìn)行B/S結(jié)構(gòu)測(cè)試又無(wú)從下手的朋友的要求，在這里要向大家表達(dá)一下歉意，由于工作比較忙，難免對(duì)大家的來(lái)信有所疏漏，請(qǐng)大家原諒。此文的要求的讀者，對(duì)測(cè)試工具有所了解，希望進(jìn)入更深測(cè)試的同仁，希望我的文章給大家?guī)?lái)幫助，同時(shí)也借此文表達(dá)一些曾經(jīng)幫助過(guò)我的朋友與同事。

        注：本篇只是對(duì)B/S應(yīng)用的測(cè)試過(guò)程作一個(gè)整體的描述，對(duì)某一個(gè)階段使用的工具只是作大概的介紹，你也可使用你比較熟悉的工具達(dá)到相同的目標(biāo)。