Web應(yīng)用程序的整體測(cè)試

1、Web 應(yīng)用程序的整體測(cè)試cwj007 yesky論壇隨著 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)品性 能上的缺陷,定

2、位問(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)題,再由開發(fā)人員解決問(wèn)題。那么 B/S的結(jié)構(gòu)的測(cè)試如何來(lái)做?如何發(fā)現(xiàn)問(wèn)題是我首先要介紹的,在做 WEB 測(cè)試之前你需要一些資料,比如產(chǎn)品功能說(shuō)明書,性能 需求說(shuō)明書,不一定很完善,但一定要有,明確測(cè)試目標(biāo),這是基本的常識(shí),可是我往往看到的是已經(jīng)開 始動(dòng)手測(cè)了,但還不知自己的系統(tǒng)要達(dá)到的性能指標(biāo)是什么。這里我簡(jiǎn)單講一下測(cè)試的性能指標(biāo):1、通用指標(biāo)

3、(指 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 : 物理磁盤讀寫時(shí)間情況;2、 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ì)把這兩者混淆; * Succes

4、sful 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ù);3、數(shù)據(jù)庫(kù)服務(wù)器指標(biāo):* User 0 Connections :用戶連接數(shù),也就是數(shù)據(jù)庫(kù)的連接數(shù)量;* Number of deadlocks:數(shù)據(jù)庫(kù)

5、死鎖;* 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)為

6、LoadRunner 最全面,它提供 了多種協(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)行變化,一開始由于系統(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)

7、進(jìn)行 深入分析。比如它的并發(fā)達(dá)不到你的要求,證明子系統(tǒng)性能有問(wèn)題,或是數(shù)據(jù)庫(kù)用戶連接過(guò)高,程序沒(méi)有 釋放用戶連接等等。這個(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

8、個(gè), 剛剛介紹的整體的性能測(cè)試指標(biāo)也不要增加很多, 這樣影響會(huì)小一點(diǎn)。 最后在這一階 段要說(shuō)明的是數(shù)據(jù)庫(kù)的數(shù)據(jù)量會(huì)很大程度的影響性能,所以要根據(jù)前面的性能需求說(shuō)明書向數(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ù)拈_發(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)存

9、泄漏。要發(fā)現(xiàn)這些問(wèn)題起馬的要求要有一款使用的比較稱心的性能分析與優(yōu)化工具, 比如微軟的 .NET 下就有 自己開發(fā)的工具,對(duì) Borland 的 Java 開發(fā)工具中也有類似的工具,但我個(gè)人認(rèn)為更好的工具是 Rose 下的 Purify 與 Quantify, 主要是他對(duì) .net 與 java ,C+都有支持, 而且分析效果特別專業(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ò)誤,以及

10、 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秒,提升的效果并不明顯,而且寫過(guò)程序 的人都知道,后者性能優(yōu)化的代價(jià)更大。在性

11、能優(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ù)查詢函數(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)單的介紹一下我的最愛, SQLProfile,SQL 查詢分析器, Precise,SQLProf

12、ile 是一個(gè) SQL 語(yǔ)句跟蹤器,可以跟蹤程序流程使用的 SQL 語(yǔ)句與存儲(chǔ)過(guò)程,結(jié)合查詢分析器對(duì) SQL 的分析,可以對(duì)索引的優(yōu)化做出很好的判斷,但索引也不是萬(wàn)能 的,在增刪改較多的表,索引過(guò)多會(huì)引起這些操作的性能下降,所以判斷還是需要一定的經(jīng)驗(yàn)。同時(shí)針對(duì)用戶使用頻度最高的 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ò)多

13、,或是 DCOM 調(diào)用過(guò)多等等,但說(shuō)服程序員也是一件不容易 的事,你要在這一階段做的出色一定要有幾年的編程經(jīng)驗(yàn),并且要讓程序員感到聽你的性能會(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ì), 一般這類問(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+

14、 內(nèi)存問(wèn)題比較多, Java 與 .NET 比較少,一般由 GC 不合理引起。 C+的內(nèi)存錯(cuò)誤就比較多了,主要常見的有 :1、 Array Bounds Read (ABR :數(shù)組越界讀2、 Array Bounds Write (ABW:數(shù)組越界寫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)存讀寫8、 Memory Leak:內(nèi)存泄漏注