Web應用程序的整體測試

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

2、位問題,解決問題,這才是測試要做的。首先我們從兩個方面分析如何進行 WEB 測試,從技術實現上來講一般的 B/S結構,無論是 .NET 還是 J2EE, 都是多層構架,有界面層,業(yè)務邏輯層,數據層。而從測試的流程上來說,首先是發(fā)現問題,分析問 題,定位問題,再由開發(fā)人員解決問題。那么 B/S的結構的測試如何來做?如何發(fā)現問題是我首先要介紹的,在做 WEB 測試之前你需要一些資料,比如產品功能說明書,性能 需求說明書,不一定很完善,但一定要有,明確測試目標,這是基本的常識,可是我往往看到的是已經開 始動手測了,但還不知自己的系統(tǒng)要達到的性能指標是什么。這里我簡單講一下測試的性能指標:1、通用指標

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

4、sful Rounds:成功的請求;* Failed Rounds :失敗的請求;* Successful Hits :成功的點擊次數;* Failed Hits :失敗的點擊次數;* Hits Per Second :每秒點擊次數;* Successful Hits Per Second :每秒成功的點擊次數;* Failed Hits Per Second :每秒失敗的點擊次數;* Attempted Connections :嘗試鏈接數;3、數據庫服務器指標:* User 0 Connections :用戶連接數,也就是數據庫的連接數量;* Number of deadlocks:數據庫

5、死鎖;* Butter Cache hit :數據庫 Cache 的命中情況;上面的指標只是一些通用的指標 , 起到拋磚引玉的作用,對于不同的應用你還必需作相應的調整,比如 程序使用的是 .NET 技術的,則必需加入一些針對性的測試指標。對于這些指標的詳細了解,你可以參考 Windows 下面的 SystemMonitor 的幫助與 LoadRunner 、 ACT 的幫助。對于發(fā)現問題,指標的設置非常重 要,它會幫你定性的發(fā)現一些錯誤。對于定性的壓力測試我就不做過多的分析,工具很多,流行的主要有 LoadRunner,ACT,WAS,WebLoad, 各個工具有它的使用范圍,其中我各個認為

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

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

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

9、泄漏。要發(fā)現這些問題起馬的要求要有一款使用的比較稱心的性能分析與優(yōu)化工具, 比如微軟的 .NET 下就有 自己開發(fā)的工具,對 Borland 的 Java 開發(fā)工具中也有類似的工具,但我個人認為更好的工具是 Rose 下的 Purify 與 Quantify, 主要是他對 .net 與 java ,C+都有支持, 而且分析效果特別專業(yè), 我們先了解一下 Rational Purify, Rational Purify 能自動找出 Visual C/C+ 和 Java 代碼中與內存有關的錯誤, 確保整個應用程序的質 量和可靠性。在查找典型的 Visual C/C+ 程序中的傳統(tǒng)內存訪問錯誤,以及

10、 Java , C# 代碼中與垃圾內存 收集相關的錯誤方面; Rational Quantity 則是一款針對函數級的性能分析利器, 使用它你可以從圖形化的界 面中得到函數調用的時間,百分比與次數,以及子函數所占時間,使你可以更快的定位性能瓶頸。我們先說性能優(yōu)化與異常的處理,性能優(yōu)化有一個原則,即用時間比例最大的進行優(yōu)化,效果才最明 顯,比如有個函數它的執(zhí)行時間為 30秒,如果你優(yōu)化了一百倍則執(zhí)行時間為 0.3秒 , 提升了 29.7秒,而如 果它的執(zhí)行時間為 0.3秒,優(yōu)化后為 0.003秒,實際提升了 0.297秒,提升的效果并不明顯,而且寫過程序 的人都知道,后者性能優(yōu)化的代價更大。在性

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

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

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

14、 內存問題比較多, Java 與 .NET 比較少,一般由 GC 不合理引起。 C+的內存錯誤就比較多了,主要常見的有 :1、 Array Bounds Read (ABR :數組越界讀2、 Array Bounds Write (ABW:數組越界寫3、 Beyond stack Read (BSR:堆棧越界讀4、 Free Memory Read(FMR:空閑內存讀5、 Invalid pointer Read(IPR:非法指針閱讀6、 Null Pointer Read(NPR:空指針閱讀7、 Uninitialized Memory Read(UMR:未初始化內存讀寫8、 Memory Leak:內存泄漏注