Web下的整體測試 --效能測試及最佳化思路

標籤：style   java   使用   os   io   資料   問題   cti   

隨著Internet的日益普及，現在基於B/S結構的大型應用越來越多，可如何對這些應用進行測試成為日益迫切的問題。有許多測試人員來信問我B/S的測試如何做，由於工作較繁忙，對大家提出的問題也是頭痛醫頭腳痛醫腳，沒有對WEB的測試過程做一個整體的概述。希望通過本篇能夠讓大家瞭解大型Web應用是如何來進行測試的。

B/S下的功能測試比較簡單，關鍵是如何做好效能測試。目前大多數的測試人員認為只要跑一些測試載入器證明我的產品是可以達到效能的就ok了，為了證明而去測試是沒有任何價值的，關鍵是要發現產品效能上的缺陷，定位問題，解決問題，這才是測試要做的。

首先我們從兩個方面分析如何進行WEB測試，從技術實現上來講一般的B/S結構，無論是.NET還是J2EE,都是多層構架，有介面層，商務邏輯層，資料層。而從測試的流程上來說，首先是發現問題，分析問題，定位問題，再由開發人員解決問題。那麼B/S的結構的測試如何來做？

如何發現問題是我首先要介紹的，在做WEB測試之前你需要一些資料，比如產品功能說明書，效能需求說明書，不一定很完善，但一定要有，明確測試目標，這是基本的常識，可是我往往看到的是已經開始動手測了，但還不知自己的系統要達到的效能指標是什麼。這裡我簡單講一下測試的效能指標：

l 通用指標（指Web應用伺服器、資料庫伺服器必需測試項）:

* ProcessorTime: 指伺服器CPU佔用率，一般 平均達到70%時，服務就接近飽和；

* Memory Available Mbyte : 可用記憶體數，如果測試時發現記憶體有變化情況也要注意，如果是記憶體泄露則比較嚴重；

* Physicsdisk Time : 物理磁碟讀寫時間情況；

l Web伺服器指標：

* Avg Rps: 平均每秒鐘響應次數＝總請求時間 / 秒數；

* Avg time to last byte per terstion （mstes）:平均每秒業務角本的迭代次數 ,有人會把這兩者混淆；

* Successful Rounds：成功的請求；

* Failed Rounds ：失敗的請求；

* Successful Hits ：成功的點擊次數；

* Failed Hits ：失敗的點擊次數；

* Hits Per Second ：每秒點擊次數；

* Successful Hits Per Second ：每秒成功的點擊次數；

* Failed Hits Per Second ：每秒失敗的點擊次數；

* Attempted Connections ：嘗試連結數；

l 資料庫伺服器指標：

* User 0 Connections ：使用者串連數，也就是資料庫的串連數量；

* Number of deadlocks：資料庫死結；

* Butter Cache hit ：資料庫Cache的命中情況；

上面的指標只是一些通用的指標,起到拋磚引玉的作用，對於不同的應用你還必需作相應的調整，比如程式使用的是.NET技術的，則必需加入一些針對性的測試單位。對於這些指標的詳細瞭解，你可以參考Windows 下面的 SystemMonitor的協助與LoadRunner、ACT的協助。對於發現問題，指標的設定非常重要，它會幫你定性的發現一些錯誤。對於定性的壓力測試我就不做過多的分析，工具很多，流行的主要有LoadRunner,ACT,WAS,WebLoad,各個工具有它的使用範圍，其中我各個認為LoadRunner 最全面，它提供了多種協議的支援，對複雜的壓力測試都可以勝任，WAS與ACT則對微軟的支援人員的比較好，其中WAS支援分布式機群測試,ACT則是與.NET整合比較好，支援ViewState （.NET 下控制項緩衝的支援） 的測試，當時我用時，其它測試載入器還不支援，現在應該支援了吧，呵呵。在這一階段測試你要不斷的跟據係數的測試目標進行變化，一開始由於系統過於龐大，所以我們要分成若干個子系統，各個子系統的效能目標必需明確，主要是並髮指標定一個閥值，同時設定一些與系統相關的測試參數，應用伺服器，資料庫伺服器都要有，對達不到閥值的與一些通用參數有問題的子系統進行深入分析。比如它的並發達不到你的要求，證明子系統效能有問題，或是資料庫使用者串連過高，程式沒有釋放使用者串連等等。這個我們要對子系統進行詳細測試，由於B/S 結構下,圖片的請求對效能的影響較大，所以我們對子系統測試時要分兩個部分進行，一、非程式部分，即圖片等等;二、應用程式本身。通過事務或函數的分離，可以把這兩塊實現單獨的測試，具體做法參考各個工具的手冊，我這裡就不做說明。對子系統的測試參數的設定要求則更高，它有助你後面精確的定位問題，比如對異常，死結，網路流量等等前面沒有注意到的情況的增加，同時你要注意增加測試參數的收集對系統的效能影響比較大，所以一般不要超過10個，剛剛介紹的整體的效能測試指標也不要增加很多，這樣影響會小一點。最後在這一階段要說明的是資料庫的資料量會很大程度的影響效能，所以要根據前面的效能需求說明書向資料庫中類比相應的資料量，來進行測試，這樣才有更高的可信度。

上面所說的是對問題的發現，下面就是分析問題原因，這一步的要求比較高，一般由測試人員與程式員配合完成，當然如果你有相當的開發經驗，再做這方面的測試，就更為難得。下面我們說說如何精確定位問題，出現問題的可能性可能有很多種，大致分以下幾種，一、效能達不到目標；二、效能達到目標，但有一些其它的問題，比如異常，死結，快取命中過低，網路流量較大；三、伺服器穩定性的問題，比如記憶體流失……。要發現這些問題起馬的要求要有一款使用的比較稱心的效能分析與最佳化工具，比如微軟的.NET下就有自己開發的工具，對Borland的Java開發工具中也有類似的工具，但我個人認為更好的工具是Rose下的Purify與Quantify,主要是他對.net 與java ,C++都有支援，而且分析效果特別專業，我們先瞭解一下Rational Purify, Rational Purify 能自動找出Visual C/C++ 和Java 代碼中與記憶體有關的錯誤，確保整個應用程式的品質和可靠性。在尋找典型的Visual C/C++ 程式中的傳統記憶體訪問錯誤，以及Java，C# 代碼中與垃圾記憶體收集相關的錯誤方面；Rational Quantity 則是一款針對函數級的效能分析利器，使用它你可以從圖形化的介面中得到函數調用的時間，百分比與次數，以及子函數所佔時間，使你可以更快的定位效能瓶頸。

我們先說效能最佳化與異常的處理，效能最佳化有一個原則，即用時間比例最大的進行最佳化，效果才最明顯，比如有個函數它的執行時間為30秒，如果你最佳化了一百倍則執行時間為0.3秒,提升了29.7秒，而如果它的執行時間為0.3秒，最佳化後為0.003秒，實際提升了0.297秒，提升的效果並不明顯，而且寫過程式的人都知道，後者效能最佳化的代價更大。在效能最佳化的過程中，一般是先資料庫，後程式，因為資料庫的最佳化不需要修改程式，修改的風險很小。但如何才能確定是資料庫的問題，這就需要技巧，在使用Quantity時，你一路分析下去，大多數最終會發現，是資料庫查詢函數佔用時間比較大，比如什麼，SqlCmd.ExecuteNoQuery等等資料庫執行函數,這時你就需要分析資料庫，呵呵。資料庫的分析原則是先索引，後預存程序，最後表結構視圖的最佳化，索引的最佳化是最簡單也是通常最有效方法，如果合理的使用會帶來意想不到不到的效果。在這裡我要給大家簡單的介紹一下我的最愛，SQLProfile,SQL查詢分析器，Precise,SQLProfile是一個SQL語句跟蹤器，可以跟蹤程式流程使用的SQL語句與預存程序，結合查詢分析器對SQL的分析，可以對索引的最佳化做出很好的判斷，但索引也不是萬能的，在增刪改較多的表，索引過多會引起這些操作的效能下降，所以判斷還是需要一定的經驗。同時針對使用者使用頻度最高的SQL進行最佳化也是最行之有效，這時我則需要Precise，它可以觀測某一個較長時間內的SQL語句的執行情況。資料庫最佳化的潛能挖光後，如果還是達不到效能要求或是還有問題，則要從程式來進行最佳化，這是程式員做的事，測試人員要做的，就是告訴他們，哪個函數執行過多引起了效能下降，比如異常過多，某個迴圈過多，或是DCOM調用過多等等，但說服程式員也是一件不容易的事，你要在這一階段做的出色一定要有幾年的編程經驗，並且要讓程式員感到聽你的效能會有提升，這是一件很不容易的事情哦。

記憶體的分析，一般是一個長期分析的過程，要做好不容易，首先要有長期奮戰的準備，其次記憶體流失的分析最好是放在單元測試之中同步進行，而不是要等到最後再去發現問題，當然出了問題也只好面對，一般這類問題都是在伺服器運行了很久才暴露出來，一旦發現問題後，則需要定位問題，分析的原則採用子系統相互獨立運行，找到最小問題的系統集,或是藉助記憶體分析工具觀察記憶體對象情況，初步定位問題，再用Purify進行運行時分析，通常C++ 記憶體問題比較多，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)： null 指標閱讀

7、 Uninitialized Memory Read(UMR)：未初始化記憶體讀寫

8、 Memory Leak：記憶體流失

註：如果需要更多的資訊，可以參見Purify的協助資訊。

順便提一句，為什麼我要說單元測試時做這個比較好，由於單元測試針對的是單一功能，這時結合單元測試案例做記憶體分析會更快的定位問題，同時由於問題較早的發現，則後期的風險則會減少，當然如果結合代碼覆蓋工具PureCoverage 來做就更完美了，呵呵。

完成此文，已經是淩晨了，也算是回答了前一段時間提出要進行B/S結構測試又無從下手的朋友的要求，在這裡要向大家表達一下歉意，由於工作比較忙，難免對大家的來信有所疏漏，請大家原諒。此文的要求的讀者，對測試載入器有所瞭解，希望進入更深測試的同仁，希望我的文章給大家帶來協助,同時也藉此文表達一些曾經協助過我的朋友與同事。

註：本篇只是對B/S應用的測試過程作一個整體的描述，對某一個階段使用的工具只是作大概的介紹,你也可使用你比較熟悉的工具達到相同的目標。