測試步驟

系統性能測試中的幾大步驟 1.明確測試目標；瞭解性能測試需求； 2.編寫性能測試計劃； 3.分析性能測試需求； 4.編寫性能測試方案，設計測試場景； 5.相關資源準備(人力資源，硬件資源，軟件資源)； 6.測試程序開發；腳本維護，測試數據準備，測試監控準備； 7.執行性能測試並收集測試結果； 8.分析結果； 9.系統調優及再測試；

 

1.明確測試目標；瞭解性能測試需求；     性能測試啓動階段要肯定測試的負責人和組織結構.明確測試的整體目標和範圍,確認資源狀況.獲取

性能測試需求；業務列表,性能指標,測試環境,數據量等詳細需求.爲策劃作準備； 　性能調優是無止境的，因此在測試以前一肯定一個明確性能調優目標，這也是後面評估"性能驗證"

的一個基準，也是測試終止的一個基準； 在這個階段要明確如下信息： .肯定本次測試對象的相關背景； .整體目標和範圍：1)客戶需求和指望；2)實際業務需求；3)系統需求； .系統構架：之前測試的歷史記錄；系統目前的狀況；與之相關的非性能需求； 　　以上提到的這些內容在初期只是從總體上作一個瞭解，具體的需求內容，將在測試需求分析章節

講到．

 

2. 編寫性能測試計劃；     性能測試計劃中包含測試目的和測試目標相關信息,還肯定了實施和執行測試時使用的策略,方法;同

時肯定了測試工具,所需資源.日程表等;

性能測試計劃關鍵點: .階段任務描述(階段,子階段劃分清晰;階段關聯關係明確;里程碑定義準確) .時間安排(知足項目預期週期要求,具備彈性) .文檔定義(各階段輸入輸出文檔定義清晰) .所需資源(人力資源,資金資源等符合項目要求)

 

3. 分析性能測試需求； 測試需求分析 1)需求獲取     需求的獲取很是複雜,並且要求測試人員具備挖掘可能形成系統瓶頸因素的洞察力和敏銳,這個過程

在測試總體過程當中是很是關鍵的一環.要獲取的需求在後面幾節中將會講到. 2)需求分類     性能測試需求分析主要目的是要找出可能形成系統瓶頸的因素,爲後面測試場景設計提供依據.影響

系統性能有不少種種緣由,在此應關注以下幾個關鍵點: a.環境配置性能需求     應用配置需求:例如應用總體框架,涉及到哪些第三方的組件,應用層與數據庫層的接口,使用了什麼

數據庫等;     系統配置需求:例如用戶客戶端配置,客戶端與服務器端的網絡配置,應用服務器或數據庫服務器操做

系統等等; b.服務器性能指標要求:     預期的在上線系統中服務器資源使用狀況,吞吐量,軟件運行狀況等等; c.系統設計需求:     系統架構,系統的技術實現,與其它系統接口關係及其技術實現,本系統測試數據及其與相關係統測試

數據關係等等; d.工做負載需求:     用戶使用狀況需求:例如用戶分佈狀況;哪些模塊用戶比較頻繁;在用戶操做的數據有哪些特色等等;

這些需求須要具體定位到系統的哪些功能模塊,功能點; e.客戶端性能指標要求:     請求響應時間分佈;請求的準確率等等;

根據性能需求的提出,需求又能夠分爲: . 用戶提出的性能需求:例如業務量大,使用頻繁的功能; . 開發提出的性能需求:例如系統處理相對較複雜的位置; . 系統自己的理想化性能展示:例如理想化的系統性能情況;

3)測試環境需求     環境需求主要包括:服務器環境配置要求,客戶端機器配置要求,網絡環境等等硬件因素,還包括一些

軟件因素:如服務器使用的數據庫,中間件類型和版本,客戶端的類型版本,網絡傳輸協議版本等等,這些

因素都會對系統產生不一樣程度的影響.

4)工做負載需求     根據測試項目類型的不一樣,要求的測試指標也不同.最能反映系統性能狀況的是:點擊數,處理量,響

應時間,硬件的使用狀況. 測試指標包括如:併發用戶數,事務,事務響應時間,每秒點擊數,鏈接數,每秒

增長鏈接數.系統吞吐量等等.

4. 編寫性能測試方案，設計測試場景；     測試內容通常包括併發性能測試,疲勞強度測試,大數據量測試以及系統資源監控等,性能調優測試時

主要是作併發性能測試以及系統資源監控這些方面的工做.從對系統產生併發性能測試過程當中監控系統

中各類資源的變化,來判斷致使性能瓶頸的緣由. 1)注意事項     測試案例主要是根據測試需求分析的結果制定出在測試執行時系統的執行方法,在測試案例設計時應

注意以下幾點:     .明確測試目的,測試範圍;明確項目功能需求以及負載分佈狀況.     .分析測試環境中可能出現瓶頸的位置,重點測試;     .綜合業務場景中:穩中有操做的併發量,所佔有百分比,準備完成請求數量,頻率等等典型行爲是明確

的;虛擬用戶的操做步驟要儘可能相似於真實用戶的操做;操做的數據要類同於真實用戶實際使用數據;在

案例設計時要充分考慮到需求中用戶對模塊的使用頻率.使得在模擬時每一個模塊使用狀況儘可能地相似於

真實環境;    .明確的經過指標;爲每一個典型業務制定測試經過的指標;    .有效的測試工具;須要產生負載的應用能夠在合理的時間內達到你指望的負載,而後再緩慢增長;   . 詳細的結果記錄:對於每一個請求的響應時間,開始時間,結束時間,響應時間細分,傳輸數據量,請求內

容等等作詳細的記錄,以方便性能測試進行分析;   . 資源利用率的監測:有效的資源監控方式,使能得到全部需在的資源數據;    .軟硬伯環境一致性;    .數據庫或文件系統中測試數據與正式環境數據的數量和內容的一致性; 2)測試場景      性能測試在軟件測試中佔有重要的地位,性能測試包含的內容是不少的.例如針對一個網站進行性能

測試,常規性能測試,壓力,負載測試,大數據量測試,強度測試等等都應該包含在內的.     測試方案中可能把測試按照類型劃分,每一個類型下又設計N個場景.一般測試中會使用的一些場景: 預期性能指標測試:一般系統在設計前都會提出一些性能指標,這些指標是性能測試要完成的首要工做

之一.針對每一個指標都要編寫多個測試用例來驗證是否達到要求. 單一功能加壓測試:這類場景主要爲了驗證某一特定功能的性能情況,或者檢測該功能是否存在隱藏的

性能問題.     複雜場景測試:根據業務數據分析,設計與真實狀況相似的場景,測試系統總體性能.通常,預期性能指標

驗證.整個系統性能評定.整個系統的性能調優測試都採用這種場景;

5. 相關資源準備(人力資源，硬件資源，軟件資源)； 測試環境準備及配置:     包括被測應用和應用環境的申請,部署,壓力發生環境準備,監控系統準備和網絡環境申請和部署,提

供符合需求可以使用的測試環境;     包括被測應用系統,壓力發生系統.監控系統,網絡系統的配置等等.

測試場景準備:     根據業務模型肯定測試場景;

    測試腳本開發.數據準備,參數化數據,腳本預驗證;     測試腳本的開發;     基礎數據的得到,數據量評估和基礎數據設計;     設置測試程序中需參數化的字段,使全部參數化數據能夠正確執行場景.保證參數化的測試腳本與基

礎數據結合可以在測試執行環境下正確運行;     驗證最終但是腳本能夠在測試環境正確執行,而且自身無性能問題.     監控系統與數據分析系統準備:     設計合理的監控方案,並設計相應的監控工具實施監控;     對監控數據和結果數據進行分析的腳本或者程序;

 

測試環境準備      測試環境:配置測試環境是測試實施的一個重要階段,測試環境的適合與否會嚴重影響測試結果的真實

性和正確性.測試環境包括硬件環境和軟件環境,硬件環境指測試必需的服務器,客戶端.網絡鏈接設備

以及打印/掃描儀等輔助硬件設備所構成的環境;軟件環境指被測試軟件運行時的操做系統,數據庫及其

他應用軟件構成的環境;       一個充分準備好的測試環境有四具優勢:一個穩定,可重複的測試環境,可以保證測試結果的正確;保

證達到執行的技術需求;保證獲得正確的,可重複的以及晚理解的測試結果;與真實環境的一致或儘可能保

持一致.      性能測試環境,要求和真實環境一致或存在可比性.

6. 測試程序開發；腳本維護，測試數據準備，測試監控準備； 測試程序開發       性能測試場景設計和性能測試腳本設計中需在注意如下幾個問題: 場景真實性:       每一個腳本的具體操做步驟,是和真實環境操做相似的,每一個場景內的測試程序之間的邏輯關係,壓力比

重也是與真實環境相似的.在測試方案設計中已經將這些真實環境的信息量化到可用程序模擬程度.     場景中各個腳本所佔的比例主要是經過線程組來控制的,便可以控制多少個線程在某一階段運行哪一

個或幾個腳本;     具體操做步驟須要注意兩個相鄰的操做動做之間的習慣性時間間隔,某些特定操做的集合在特定時間

同時發起請求等等;

數據驅動:

    肯定某個操做步驟中須要將輸入數據進行參數化,參數化數據儘可能選擇讀文件的方式,在數據庫中讀

取會嚴重影響速度.若是數據量不大,能夠在併發程序開始執行前先將數據讀到內存;     值得注意的是,不是全部的數據均可以經過讀取預先定製的文件來得到.而是在程序執行過程當中,在返

回結果中獲取這個數據信息,而後運用到下一操做中.測試界把它稱做"關聯"經常使用測試工具都提供關聯功能,本身編寫程序時也能夠指導它做爲單獨的程序模塊來編寫,方便在後續的項目中利用.

事務:     一個複雜的操做應該是有不少個事務組合而成的.使用事務能夠更方便靈活的進行數據統計.

檢查點:     檢查點的做用是驗證操做結果是否正確.它能夠寫在程序中,能夠經過操做返回結果來判斷.具體實

現的方式不固定的.只要可以方便的檢查,咱們運行的併發請求是否都是有效的.可是檢查點不宜設置過

多,由於在檢查時會有系統消耗,影響併發性;

保存登陸信息     不少系統性能測試場景是須要在用戶登陸狀態下操做的.那麼保存登陸用戶信息也很重要,需

要咱們注意;

 

測試數據準備 性能測試中用到的數據有兩類: 1)測試環境中系統應該具有的初始數據以及和正式環境同等數據量(或加權值)的有效數據,或者在系統

生命週期內預期能達到的最大數據量的數據,儘可能保證其真實性. 2)運行測試腳本需用到的數據,參數化數據.     在測試需求調研過程當中也要明確數據量要求,數據準備必定要關注數據的質量和數量,不要出現一些

不符合業務邏輯的廢數據,而且數據量要知足測試運行的須要.不然會致使測試執行結果出現大的誤差.

數據的部署也應該儘可能保證真實性.     若是是配置測試或者測試數據對測試結果影響很大的場景,要保證測試過程基準一致,不然測試結果

將沒有可比性.因此,測試數據建立完成後,要及時備份,以便多個場景中重複使用這些數據,能夠建立一

個測試庫來管理測試數據.

 

測試監控準備   根據測試的目的不一樣,測試監控的對象不一樣,測試的主要指標也不相同.   測試指標通常分爲兩大類:業務處理指標,系統資源指標.其中,業務處理性能指標主要包括:業務結果

的正確性.每分鐘處理請求數,事務響應時間(Min,Max,Avg,90%響應時間範圍,響應時間變化,分佈等

等),併發用戶數,系統吞量等等,系統資源指標主要是指CPU,內存,硬盤,網絡等系統資源使用及變化情

況.

 

7.執行性能測試並收集測試結果； 測試執行     在性能測試啓動以前,須要就被系統是否符合准入標準,和實施性能測試的可行性和必要性進行分析.

考察破壞性測試系統是否具有性能測試的條件.      測試執行過程當中,要特別注意測試腳本和場景的運行是有效的.在測試程序開發過程當中,咱們加入了

檢查點就是爲了保證程序正確的執行,產生咱們所須要的負載.可是,在測試程序長期執行過程當中,咱們

還須要常常檢查測試是否正確執行.不然,得出的測試結果多是錯誤的,無心義的.     測試執行與監控的主要目的是根據設計方案去驗證系統是否存在瓶頸,給測試分析提供各類分析數據

.此過程會與測試分析過程不斷進行重複執行,直至真正肯定出系統瓶頸所在.

測試執行關鍵點     執行測試的過程當中,有一些須要重點關注的事件:     在測試執行前,須要確認:用例和場景確認;測試環境確認;測試數據確認;測試腳本確認;測試 工具和

監控工具確認;     執行過程當中注意:執行每一個場景時都須要作執行記錄,結果蒐集等工做.     執行完成後注意:數據恢復.環境清理,結果整理.

測試記錄     測試過程當中要記錄以下信息:運行前的系統配置,運行前的參數或者軟件調整狀況;運行過程當中的系統

資源的使用狀況;運行過程當中的故障現象;請求的響應時間;單位時間內的處理請求數;請求的成功率;等

等.

 

8.分析結果； 測試分析:     測試分析的主要目的是要根據測試執行獲取到的數據去判斷形成系統出現瓶頸的位置,挖掘形成系統

瓶頸的真正緣由.這個過程是技術含量最高的一環.     性能分析一般要圍繞三個方面進行:軟件,服務器,網絡.      軟件主要是分析具體事務執行時間,尤爲併發用戶部分,根據測試工具測試出的結果分析那些事務執

行的慢,而後能夠分析執行較慢的代碼,針對網頁能夠分析具體的頁面元素執行狀況.      服務器的分析要結合軟件的運行狀況進行分析,着重分析硬件的執行參數,CPU,硬盤,內存,中斷,內存

等狀況,分析尤爲要注意對這些參數進行綜合分析,每每各個參數之間會互相影響,最後在調查,分析整

體系統的基礎上,找出影響服務器總體性能的瓶頸,肯定相應的升級需求.      網絡性能分析要結合服務器和目標軟件,一般網絡傳輸慢會有軟件和服務器方面的緣由,甚至有時候

會有客戶端方面的緣由.不過目前網絡的環境廣泛能夠,無論是局域網仍是廣域網,網絡的環境愈來愈好

.

測試分析建議     測試分析小組應該由具備如下素質的人員組成:開發,測試,應用服務器.數據庫,操做系統,網絡,存儲

等等.     在測試分析時使用較多的一種方式是排除法,根據開始獲取到的信息大概能將問題定位在某一層面上

.但具體在什麼地方,就能夠採起排除的方法去定位;     儘可能使用一些較成熟的工具協助分析工做,這樣將大大減輕工做負擔.     在肯定出真正的性能瓶頸時,能夠作一些小的模型去作驗證,肯定分析的正確性.

 

瓶頸分析 1) 處理器分析方法     首先查看System\%Total Processor time計數器的值.該值體現的是CPU的平均利用率,若超過90%,則

說明存在處理器方面的瓶頸.     其次查看每一個CPU的Processor\%User Time計數器的值.若應用服務器的%User Time值較大,能夠考慮

是否能經過算法優化等方法下降這個值.若數據服務器的%User Time值較大,可考慮對數據庫系統進行

優化.     查看System\Processor Queue Length計數器的值.當該值大於CPU數量的總數+1時,說明存在處理器

方面的問題. 2)磁盤I/O分析方法     查看%Disk Time計數器的值.該值較大,則可能存在磁盤瓶頸問題.     與Processor\Privileged Time合併進行分析.若%Disk Time值較大,而Processor\Privileged Time

的值適中,則可判斷存在磁盤問題,若Processor\Privileged Time較大,持續超過80%,則多是內存泄

漏.     根據Disk sec/Transfer進行分析.該值超過60ms,則磁盤存在問題. 3)網絡分析方法     查看Network Interface\Bytes Total/sec 計數器的值.用 Bytes Total/sec計數器的值和網絡的帶

寬進行比較,若超過 50%,則說明網絡存在性能瓶頸問題. 4)軟件瓶頸分析方法     分析事務響應時間,吞吐量,肯定是否存在性能問題,若發現存在性能問題,則找出響應時間不符合要

求或者出現多個失敗的事務,對其進行分解,而後對其進行網頁細分,以肯定影響性能的元素.

 

內存泄漏 對於C++或java系統,若是GC處理不合理,會引發不少內存堆棧問題.常見有: 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 Leaka: 內存泄漏.

 

WEB 響應時間細分 響應時間: Time = DNS + Conn +Handshaking +FTPAuthentication + Send + ServerTime + Rec + Client;; ServerTime = logic +DB*n + .....;

 

吞吐量等指標變化狀況   不斷的增長用戶數,提升壓力.各性能指標變化狀況;   響應時間和吞吐量會受到負載的影響.隨着服務器上負載的增長,吞吐量會不斷攀升,直到到達一個點

.     最初的一段時間,執行隊列的長度爲零,而後就開始以穩定的速度增加.     在某一點上,執行隊列開始增加,由於服務器上全部的線程都已投入使用,傳入的請求再也不被當即處理

,而是放入隊列中,當線程空閒時再處理.     當系統達到飽和點,服務器吞吐量保持穩定後,就達到了給定條件下的系統上限.可是,隨着服務器負

載的繼續增加,系統和響應時間也隨之延長,雖然吞吐量保持穩定.     進入飽和狀態後繼續增長負載,服務器吞吐量保持穩定,系統的響應時間延長,最終會出現系統不可能

用,宕機等狀況.

 

9.系統調優及再測試； 配置優化 緩存機制,但是設置多級緩存; 數據壓縮機制,減少網絡傳輸;(減小每一個請求的大小) 大數據塊分塊傳輸; 負載平衡,用來水平放服務器的結構; 分爲讀寫服務器和只讀服務器,還要對服務器羣負載平衡; 增長更多的硬件資源:CPU,內存,磁盤等; 增長網絡的帶寬;等等.

 

瓶頸分析工具   應用層:開發人員能夠經過Profilers來發現低效率的代碼,好比說較差的查找算法.   數據庫層:開發人員和數據庫管理員(DBA)能夠經過特定的數據庫Profilers及事件探查器(query optimizers)   操做系統層:系統工程師可使用一些工具如在Unix類的操做系統中的top,vmstat,iostat,在Windows系統中的PerfMon來監控CPU,內存,swap，磁盤I/O等硬件資源;專門的內核監控軟件也能夠在這一層面上被使用.    網絡層:網絡工程師可使用報文探測器(如tcpdump),網絡協議分析器(如ethereal),還有其它的工具(如netstat,MRTG,ntop,mii-tool)