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

2019-11-17 04:45:37

字體：大中小

供稿：網(wǎng)友

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

　　B/S下的功能測試比較簡單，要害是如何做好性能測試。目前大多數(shù)的測試人員認(rèn)為只要跑一些測試工具證實我的產(chǎn)品是可以達到性能的就ok了，為了證實而去測試是沒有任何價值的，要害是要發(fā)現(xiàn)產(chǎn)品性能上的缺陷，定位問題，解決問題，這才是測試要做的。

　　首先我們從兩個方面分析如何進行WEB測試，從技術(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)開始動手測了，但還不知自己的系統(tǒng)要達到的性能指標(biāo)是什么。這里我簡單講一下測試的性能指標(biāo)：

　　1、通用指標(biāo)（指Web應(yīng)用服務(wù)器、數(shù)據(jù)庫服務(wù)器必需測試項）:

　　* PRocessorTime: 指服務(wù)器CPU占用率，一般平均達到70%時，服務(wù)就接近飽和；

　　* Memory Available Mbyte : 可用內(nèi)存數(shù)，假如測試時發(fā)現(xiàn)內(nèi)存有變化情況也要注重，假如是內(nèi)存泄露則比較嚴(yán)重；

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

　　2、Web服務(wù)器指標(biāo)：
　　
　　* Avg Rps: 平均每秒鐘響應(yīng)次數(shù)＝總請求時間 / 秒數(shù)；

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

　　* SUCcessful Rounds：成功的請求；

　　* Failed Rounds ：失敗的請求；

　　* Successful Hits ：成功的點擊次數(shù)；

　　* Failed Hits ：失敗的點擊次數(shù)；

　　* Hits Per Second ：每秒點擊次數(shù)；

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

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

　　* Attempted Connections ：嘗試鏈接數(shù)；

　　3、數(shù)據(jù)庫服務(wù)器指標(biāo)：

　　* User 0 Connections ：用戶連接數(shù)，也就是數(shù)據(jù)庫的連接數(shù)量；

　　* Number of deadlocks：數(shù)據(jù)庫死鎖；

　　* Butter Cache hit ：數(shù)據(jù)庫Cache的命中情況；

　　上面的指標(biāo)只是一些通用的指標(biāo),起到拋磚引玉的作用，對于不同的應(yīng)用你還必需作相應(yīng)的調(diào)整，比如程序使用的是.NET技術(shù)的，則必需加入一些針對性的測試指標(biāo)。對于這些指標(biāo)的具體了解，你可以參考Windows 下面的 SystemMonitor的幫助與LoadRunner、ACT的幫助。對于發(fā)現(xiàn)問題，指標(biāo)的設(shè)置非常重要，它會幫你定性的發(fā)現(xiàn)一些錯誤。對于定性的壓力測試我就不做過多的分析，工具很多，流行的主要有LoadRunner,ACT,WAS,WebLoad,各個工具有它的使用范圍，其中我各個認(rèn)為LoadRunner 最全面，它提供了多種協(xié)議的支持，對復(fù)雜的壓力測試都可以勝任，WAS與ACT則對微軟的技術(shù)支持的比較好，其中WAS支持分布式機群測試,ACT則是與.NET集成比較好，支持ViewState （.NET 下控件緩存的支持）的測試，當(dāng)時我用時，其它測試工具還不支持，現(xiàn)在應(yīng)該支持了吧。 QQread.com 推出各大專業(yè)服務(wù)器評測 linux服務(wù)器的安全性能 SUN服務(wù)器 HP服務(wù)器 DELL服務(wù)器 IBM服務(wù)器聯(lián)想服務(wù)器浪潮服務(wù)器曙光服務(wù)器同方服務(wù)器華碩服務(wù)器
寶德服務(wù)器
　　在這一階段測試你要不斷的跟據(jù)系數(shù)的測試目標(biāo)進行變化，一開始由于系統(tǒng)過于龐大，所以我們要分成若干個子系統(tǒng)，各個子系統(tǒng)的性能目標(biāo)必需明確，主要是并發(fā)指標(biāo)定一個閥值，同時設(shè)定一些與系統(tǒng)相關(guān)的測試參數(shù)，應(yīng)用服務(wù)器，數(shù)據(jù)庫服務(wù)器都要有，對達不到閥值的與一些通用參數(shù)有問題的子系統(tǒng)進行深入分析。比如它的并發(fā)達不到你的要求，證實子系統(tǒng)性能有問題，或是數(shù)據(jù)庫用戶連接過高，程序沒有釋放用戶連接等等。

　　這個我們要對子系統(tǒng)進行具體測試，由于B/S 結(jié)構(gòu)下,圖片的請求對性能的影響較大，所以我們對子系統(tǒng)測試時要分兩個部分進行，一、非程序部分，即圖片等等;二、應(yīng)用程序本身。通過事務(wù)或函數(shù)的分離，可以把這兩塊實現(xiàn)單獨的測試，具體做法參考各個工具的手冊，我這里就不做說明。

　　對子系統(tǒng)的測試參數(shù)的設(shè)置要求則更高，它有助你后面精確的定位問題，比如對異常，死鎖，網(wǎng)絡(luò)流量等等前面沒有注重到的情況的增加，同時你要注重增加測試參數(shù)的收集對系統(tǒng)的性能影響比較大，所以一般不要超過10個，剛剛介紹的整體的性能測試指標(biāo)也不要增加很多，這樣影響會小一點。最后在這一階段要說明的是數(shù)據(jù)庫的數(shù)據(jù)量會很大程度的影響性能，所以要根據(jù)前面的性能需求說明書向數(shù)據(jù)庫中模擬相應(yīng)的數(shù)據(jù)量，來進行測試，這樣才有更高的可信度。

　　上面所說的是對問題的發(fā)現(xiàn)，下面就是分析問題原因，這一步的要求比較高，一般由測試人員與程序員配合完成，當(dāng)然假如你有相當(dāng)?shù)拈_發(fā)經(jīng)驗，再做這方面的測試，就更為難得。下面我們說說如何精確定位問題，出現(xiàn)問題的可能性可能有很多種，大致分以下幾種：

　　一、性能達不到目標(biāo)；

　　二、性能達到目標(biāo)，但有一些其它的問題，比如異常，死鎖，緩存命中過低，網(wǎng)絡(luò)流量較大；

　　三、服務(wù)器穩(wěn)定性的問題，比如內(nèi)存泄漏……。

　　要發(fā)現(xiàn)這些問題起馬的要求要有一款使用的比較稱心的性能分析與優(yōu)化工具，比如微軟的.NET下就有自己開發(fā)的工具，對Borland的java開發(fā)工具中也有類似的工具，但我個人認(rèn)為更好的工具是Rose下的Purify與Quantify,主要是他對.net 與java ,C++都有支持，而且分析效果非凡專業(yè)，我們先了解一下Rational Purify, Rational Purify 能自動找出Visual C/C++ 和Java 代碼中與內(nèi)存有關(guān)的錯誤，確保整個應(yīng)用程序的質(zhì)量和可靠性。在查找典型的Visual C/C++ 程序中的傳統(tǒng)內(nèi)存訪問錯誤，以及Java，C# 代碼中與垃圾內(nèi)存收集相關(guān)的錯誤方面；Rational Quantity 則是一款針對函數(shù)級的性能分析利器，使用它你可以從圖形化的界面中得到函數(shù)調(diào)用的時間，百分比與次數(shù)，以及子函數(shù)所占時間，使你可以更快的定位性能瓶頸。

　　我們先說性能優(yōu)化與異常的處理，性能優(yōu)化有一個原則，即用時間比例最大的進行優(yōu)化，效果才最明顯，比如有個函數(shù)它的執(zhí)行時間為30秒，假如你優(yōu)化了一百倍則執(zhí)行時間為0.3秒,提升了29.7秒，而假如它的執(zhí)行時間為0.3秒，優(yōu)化后為0.003秒，實際提升了0.297秒，提升的效果并不明顯，而且寫過程序的人都知道，后者性能優(yōu)化的代價更大。在性能優(yōu)化的過程中，一般是先數(shù)據(jù)庫，后程序，因為數(shù)據(jù)庫的優(yōu)化不需要修改程序，修改的風(fēng)險很小。但如何才能確定是數(shù)據(jù)庫的問題，這就需要技巧，在使用Quantity時，你一路分析下去，大多數(shù)最終會發(fā)現(xiàn)，是數(shù)據(jù)庫查詢函數(shù)占用時間比較大，比如什么，SqlCmd.ExecuteNoQuery等等數(shù)據(jù)庫執(zhí)行函數(shù),這時你就需要分析數(shù)據(jù)庫。

　　數(shù)據(jù)庫的分析原則是先索引，后存儲過程，最后表結(jié)構(gòu)視圖的優(yōu)化，索引的優(yōu)化是最簡單也是通常最有效的方法，假如合理的使用會帶來意想不到不到的效果。在這里我要給大家簡單的介紹一下我的最愛，SQLProfile,SQL查詢分析器，Precise,SQLProfile是一個SQL語句跟蹤器，可以跟蹤程序流程使用的SQL語句與存儲過程，結(jié)合查詢分析器對SQL的分析，可以對索引的優(yōu)化做出很好的判定，但索引也不是萬能的，在增刪改較多的表，索引過多會引起這些操作的性能下降，所以判定還是需要一定的經(jīng)驗。

　　同時針對用戶使用頻度最高的SQL進行優(yōu)化也是最行之有效的，這時我則需要Precise，它可以觀測某一個較長時間內(nèi)的SQL語句的執(zhí)行情況。數(shù)據(jù)庫優(yōu)化的潛能挖光后，假如還是達不到性能要求或是還有問題，則要從程序來進行優(yōu)化，這是程序員做的事，測試人員要做的，就是告訴他們，哪個函數(shù)執(zhí)行過多引起了性能下降，比如異常過多，某個循環(huán)過多，或是DCOM調(diào)用過多等等，但說服程序員也是一件不輕易的事，你要在這一階段做的出色一定要有幾年的編程經(jīng)驗，并且要讓程序員感到聽你的性能會有提升，這是一件很不輕易的事情。

　　內(nèi)存的分析，一般是一個長期分析的過程，要做好不輕易，首先要有長期奮戰(zhàn)的預(yù)備，其次內(nèi)存泄漏的分析最好是放在單元測試之中同步進行，而不是要等到最后再去發(fā)現(xiàn)問題，當(dāng)然出了問題也只好面對，一般這類問題都是在服務(wù)器運行了很久才暴露出來，一旦發(fā)現(xiàn)問題后，則需要定位問題，分析的原則采用子系統(tǒng)相互獨立運行，找到最小問題的系統(tǒng)集,或是借助內(nèi)存分析工具觀察內(nèi)存對象情況，初步定位問題，再用Purify進行運行時分析，通常C++ 內(nèi)存問題比較多，Java與.NET比較少，一般由GC不合理引起。C++的內(nèi)存錯誤就比較多了，主要常見的有:

　　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)存泄漏

　　注：假如需要更多的信息，可以參見Purify的幫助信息。

　　順便提一句，為什么我要說單元測試時做這個比較好，由于單元測試針對的是單一功能，這時結(jié)合單元測試案例做內(nèi)存分析會更快的定位問題，同時由于問題較早的發(fā)現(xiàn)，則后期的風(fēng)險則會減少，當(dāng)然假如結(jié)合代碼覆蓋工具PureCoverage 來做就更完美了。

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

上一篇：軟件項目如何進行需求分析

下一篇：模式和框架簡介