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

1、Web 應(yīng)用程序的整體測試cwj007 yesky論壇隨著 Internet 的日益普及, 現(xiàn)在基于 B/S結(jié)構(gòu)的大型應(yīng)用越來越多, 可如何對這些應(yīng)用進(jìn)行測試成為日 益迫切的問題。有許多測試人員來信問我 B/S的測試如何做,由于工作較繁忙,對大家提出的問題也是頭 痛醫(yī)頭腳痛醫(yī)腳,沒有對 WEB 的測試過程做一個(gè)整體的概述。希望通過本篇能夠讓大家了解大型 Web 應(yīng) 用是如何來進(jìn)行測試的。B/S下的功能測試比較簡單,關(guān)鍵是如何做好性能測試。目前大多數(shù)的測試人員認(rèn)為只要跑一些測試 工具證明我的產(chǎn)品是可以達(dá)到性能的就 ok 了, 為了證明而去測試是沒有任何價(jià)值的, 關(guān)鍵是要發(fā)現(xiàn)產(chǎn)品性 能上的缺陷,定

2、位問題,解決問題,這才是測試要做的。首先我們從兩個(gè)方面分析如何進(jìn)行 WEB 測試,從技術(shù)實(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)開 始動(dòng)手測了,但還不知自己的系統(tǒng)要達(dá)到的性能指標(biāo)是什么。這里我簡單講一下測試的性能指標(biāo):1、通用指標(biāo)

3、(指 Web 應(yīng)用服務(wù)器、數(shù)據(jù)庫服務(wù)器必需測試項(xiàng) :* ProcessorTime: 指服務(wù)器 CPU 占用率,一般 平均達(dá)到 70%時(shí),服務(wù)就接近飽和;* Memory Available Mbyte : 可用內(nèi)存數(shù),如果測試時(shí)發(fā)現(xiàn)內(nèi)存有變化情況也要注意,如果是內(nèi)存泄露 則比較嚴(yán)重;* Physicsdisk Time : 物理磁盤讀寫時(shí)間情況;2、 Web 服務(wù)器指標(biāo):* Avg Rps: 平均每秒鐘響應(yīng)次數(shù)=總請求時(shí)間 / 秒數(shù);* Avg time to last byte per terstion (mstes :平均每秒業(yè)務(wù)角本的迭代次數(shù) , 有人會把這兩者混淆; * Succes

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

5、死鎖;* 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)一些錯(cuò)誤。對于定性的壓力測試我就不做過多的分析,工具很多,流行的主要有 LoadRunner,ACT,WAS,WebLoad, 各個(gè)工具有它的使用范圍,其中我各個(gè)認(rèn)為

6、LoadRunner 最全面,它提供 了多種協(xié)議的支持,對復(fù)雜的壓力測試都可以勝任, WAS 與 ACT 則對微軟的技術(shù)支持的比較好,其中 WAS 支持分布式機(jī)群測試 ,ACT 則是與 .NET 集成比較好, 支持 ViewState (.NET 下控件緩存的支持 的 測試,當(dāng)時(shí)我用時(shí),其它測試工具還不支持,現(xiàn)在應(yīng)該支持了吧。在這一階段測試你要不斷的跟據(jù)系數(shù)的測試目標(biāo)進(jìn)行變化,一開始由于系統(tǒng)過于龐大,所以我們要分 成若干個(gè)子系統(tǒng),各個(gè)子系統(tǒng)的性能目標(biāo)必需明確,主要是并發(fā)指標(biāo)定一個(gè)閥值,同時(shí)設(shè)定一些與系統(tǒng)相 關(guān)的測試參數(shù),應(yīng)用服務(wù)器,數(shù)據(jù)庫服務(wù)器都要有,對達(dá)不到閥值的與一些通用參數(shù)有問題的子系統(tǒng)

7、進(jìn)行 深入分析。比如它的并發(fā)達(dá)不到你的要求,證明子系統(tǒng)性能有問題,或是數(shù)據(jù)庫用戶連接過高,程序沒有 釋放用戶連接等等。這個(gè)我們要對子系統(tǒng)進(jìn)行詳細(xì)測試, 由于 B/S 結(jié)構(gòu)下 , 圖片的請求對性能的影響較大, 所以我們對子系 統(tǒng)測試時(shí)要分兩個(gè)部分進(jìn)行,一、非程序部分,即圖片等等 ; 二、應(yīng)用程序本身。通過事務(wù)或函數(shù)的分離, 可以把這兩塊實(shí)現(xiàn)單獨(dú)的測試,具體做法參考各個(gè)工具的手冊,我這里就不做說明。對子系統(tǒng)的測試參數(shù)的設(shè)置要求則更高,它有助你后面精確的定位問題,比如對異常,死鎖,網(wǎng)絡(luò)流 量等等前面沒有注意到的情況的增加,同時(shí)你要注意增加測試參數(shù)的收集對系統(tǒng)的性能影響比較大,所以 一般不要超過 10

8、個(gè), 剛剛介紹的整體的性能測試指標(biāo)也不要增加很多, 這樣影響會小一點(diǎn)。 最后在這一階 段要說明的是數(shù)據(jù)庫的數(shù)據(jù)量會很大程度的影響性能,所以要根據(jù)前面的性能需求說明書向數(shù)據(jù)庫中模擬 相應(yīng)的數(shù)據(jù)量,來進(jìn)行測試,這樣才有更高的可信度。上面所說的是對問題的發(fā)現(xiàn),下面就是分析問題原因,這一步的要求比較高,一般由測試人員與程序 員配合完成,當(dāng)然如果你有相當(dāng)?shù)拈_發(fā)經(jīng)驗(yàn),再做這方面的測試,就更為難得。下面我們說說如何精確定 位問題,出現(xiàn)問題的可能性可能有很多種,大致分以下幾種:一、性能達(dá)不到目標(biāo);二、性能達(dá)到目標(biāo),但有一些其它的問題,比如異常,死鎖,緩存命中過低,網(wǎng)絡(luò)流量較大;三、服務(wù)器穩(wěn)定性的問題,比如內(nèi)存

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

10、 Java , C# 代碼中與垃圾內(nèi)存 收集相關(guān)的錯(cuò)誤方面; Rational Quantity 則是一款針對函數(shù)級的性能分析利器, 使用它你可以從圖形化的界 面中得到函數(shù)調(diào)用的時(shí)間,百分比與次數(shù),以及子函數(shù)所占時(shí)間,使你可以更快的定位性能瓶頸。我們先說性能優(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秒,提升的效果并不明顯,而且寫過程序 的人都知道,后者性能優(yōu)化的代價(jià)更大。在性

11、能優(yōu)化的過程中,一般是先數(shù)據(jù)庫,后程序,因?yàn)閿?shù)據(jù)庫的 優(yōu)化不需要修改程序, 修改的風(fēng)險(xiǎn)很小。 但如何才能確定是數(shù)據(jù)庫的問題, 這就需要技巧, 在使用 Quantity 時(shí),你一路分析下去,大多數(shù)最終會發(fā)現(xiàn),是數(shù)據(jù)庫查詢函數(shù)占用時(shí)間比較大,比如什么, SqlCmd.ExecuteNoQuery 等等數(shù)據(jù)庫執(zhí)行函數(shù) , 這時(shí)你就需要分析數(shù)據(jù)庫。數(shù)據(jù)庫的分析原則是先索引,后存儲過程,最后表結(jié)構(gòu)視圖的優(yōu)化,索引的優(yōu)化是最簡單也是通常最 有效的方法,如果合理的使用會帶來意想不到不到的效果。在這里我要給大家簡單的介紹一下我的最愛, SQLProfile,SQL 查詢分析器, Precise,SQLProf

12、ile 是一個(gè) SQL 語句跟蹤器,可以跟蹤程序流程使用的 SQL 語句與存儲過程,結(jié)合查詢分析器對 SQL 的分析,可以對索引的優(yōu)化做出很好的判斷,但索引也不是萬能 的,在增刪改較多的表,索引過多會引起這些操作的性能下降,所以判斷還是需要一定的經(jīng)驗(yàn)。同時(shí)針對用戶使用頻度最高的 SQL 進(jìn)行優(yōu)化也是最行之有效的, 這時(shí)我則需要 Precise , 它可以觀測某 一個(gè)較長時(shí)間內(nèi)的 SQL 語句的執(zhí)行情況。 數(shù)據(jù)庫優(yōu)化的潛能挖光后,如果還是達(dá)不到性能要求或是還有問 題,則要從程序來進(jìn)行優(yōu)化,這是程序員做的事,測試人員要做的,就是告訴他們,哪個(gè)函數(shù)執(zhí)行過多引 起了性能下降,比如異常過多,某個(gè)循環(huán)過多

13、,或是 DCOM 調(diào)用過多等等,但說服程序員也是一件不容易 的事,你要在這一階段做的出色一定要有幾年的編程經(jīng)驗(yàn),并且要讓程序員感到聽你的性能會有提升,這 是一件很不容易的事情。內(nèi)存的分析,一般是一個(gè)長期分析的過程,要做好不容易,首先要有長期奮戰(zhàn)的準(zhǔn)備,其次內(nèi)存泄漏 的分析最好是放在單元測試之中同步進(jìn)行,而不是要等到最后再去發(fā)現(xiàn)問題,當(dāng)然出了問題也只好面對, 一般這類問題都是在服務(wù)器運(yùn)行了很久才暴露出來,一旦發(fā)現(xiàn)問題后,則需要定位問題,分析的原則采用 子系統(tǒng)相互獨(dú)立運(yùn)行,找到最小問題的系統(tǒng)集 , 或是借助內(nèi)存分析工具觀察內(nèi)存對象情況,初步定位問題, 再用 Purify 進(jìn)行運(yùn)行時(shí)分析,通常 C+

14、 內(nèi)存問題比較多, 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)存泄漏注