全國電腦技術與軟體專業技術資格（水平）考試【軟體評測師】-考試內容總結（十四）效能測試

標籤：blog   網路流   alt   恢複   cpu   nbsp   響應   提高   png   

14.效能測試14.1效能測試的定義

效能是一種指標，表明軟體系統或構件對於其及時性要求的符合程度；其次，效能是軟體產品的一種特性，可以用時間來度量。效能的及時性用回應時間或者輸送量來衡量。而回應時間是對請求做出響應所需要的時間。

14.1.1使用者角度的效能測試

比如一個典型的Web應用：使用者關注的是軟體對使用者操作的回應時間。

此回應時間=呈現時間+系統回應時間。

 

14.1.2管理員角度的效能測試

關注系統的回應時間。對於系統管理員來說，使用者用戶端所消耗的時間是不考慮的。

重點就考慮系統回應時間，包括網路耗時、各伺服器耗時等。還會關注系統狀態，比如資源使用率、系統可擴充性、系統容量、系統穩定性。

 

14.1.3開發角度的效能測試

關注於如何通過調整設計和代碼實現，或是如何通過調整系統設定等方法提高軟體的效能表現。和如何發現並解決軟體設計和開發過程中產生的由於多使用者訪問引起的缺陷。會從系統架構、資料庫設計、代碼品質等方面考慮效能。

 

14.2效能測試的主要術語14.2.1回應時間

對請求做出響應所需要的時間。回應時間=呈現時間+系統回應時間。

其中：

(1)呈現時間：取決於資料在被用戶端收到響應資料後呈現頁面所消耗的時間。

(2)系統回應時間：應用系統從請求發出開始到用戶端接收到資料所消耗的時間。

 

從設計角度考慮，更好的使用者體驗是，前端在等待資料結果時，提供進度條或逐步顯示資料。

進一步分解回應時間：網路傳輸時間+應用延遲時間（Web伺服器延遲時間+DB延遲時間）。

對於回應時間，其標準不一。一般頁面的回應時間，2秒是非常有吸引力，5秒是比較不錯的，10秒則是忍受的極限。視具體情況具體設定。

 

14.2.2並發使用者數

系統並發使用者數：同一時間內訪問系統的使用者數。針對的是伺服器最大承載量。關注的是瞬間最大訪問量。

業務並發使用者數：從使用者角度來說，在相當長的一段時間內，都會有基本固定數量的使用者訪問系統。

其中：

(1)系統使用者數：使用該系統的使用者總數。

(2)線上使用者數：同時線上的使用者數。

 

在做並發測試的時候，一般會採取兩種方法：

(1)是在並發數一定的情況下，按業務不同進行測試（業務一，多少人一起使用，什麼時候開始使用，使用多長時間）。這種方式更多的是業務並發測試。

(2)是在並發數一定的情況下，只做單純一樣的操作（查詢、修改、添加、刪除）。這種方式更多的是系統並發測試。

估算並發使用者的公式：C=nL/T

其中：C為平均並發使用者數；n為login session的數量；L為login session的平均時間長度；T為考察的時間段長度。

峰值並發數： m=C+3*

 

假設login session符合泊松分布。

比如：OA系統，共3000個使用者，每天大約有400個使用者訪問，對一個使用者來說，每天線上時間為4小時，而每天工作時間為8小時。則平均的並發使用者為C=400*4/8=200，並發使用者峰值為242。

實際應用過程中，要考慮時間的細粒度或結合業務峰值和穀值來更精確的估算並發使用者。

更一般的公式是：C=n/10，即以每天訪問系統使用者數的10%作為平均的並發使用者數

                Cm=r*C  r為調整因子，取值一般為2~3

對web伺服器的日誌分析，能得到更為精確的最大並發使用者訪問數。

 

14.2.3輸送量

單位時間內系統處理的客戶請求的數量。體現軟體系統的效能承載能力。

一般描述：請求數/秒或頁面數/秒。

業務角度來說，訪問人數/天或處理的業務數/小時。

網路角度：位元組數/天==網路流量。

 

作用：

(1)用於協助設計效能測試情境，以及衡量效能測試情境是否達到了預期的設計目標；

(2)用於協助分析效能瓶頸。比如以位元組數/秒主要反映受網路基礎設施、伺服器架構、應用伺服器制約；以單擊數/秒錶示主要受應用伺服器和應用代碼的制約。

 

在未遇到效能瓶頸時，計算公式：F=Nvu*R/T。

Nvu表示虛擬使用者的個數(Virtual Users)；R表示每個VU發出的請求(單擊)數量；T表示測試時間。

 

14.2.4效能計算機

效能計算機Counter:描述伺服器或作業系統效能的一些資料指標。

資源使用率：系統各種資源的使用狀況。

 

14.2.5考慮時間

考慮時間Think Time：從業務角度來說，指使用者在進行操作時，每個請求之間的間隔時間。

考慮時間與迭代次數、並發使用者數和輸送量之間存在一定的關係。

 

計算公式：R=T/Tt

R：每個使用者發出的請求數；T為測試時間；Tt為考慮時間。

 

計算考慮時間的一般步驟：

(1)首先計算出系統的並發使用者數；

(2)統計出系統平均的輸送量

(3)統計出平均每個使用者發出的請求數量

(4)根據上面公式計算出考慮時間。

 

如果測試目的是為了驗證應用系統具有預期的能力，即能力驗證，則盡量類比使用者真實的考慮時間；如果是更一般的研究，瞭解系統在壓力下的效能水平或瞭解系統承受壓力的能力，即規劃能力，則可考慮0考慮時間。

 

14.3效能測試方法14.3.1效能測試(Performance Testing)

類比生產運行壓力量和使用情境組合，測試系統的效能是否滿足生產效能要求。在特定的運行條件下驗證系統的能力狀況。

確定使用者情境、給出需要關注的效能指標、測試執行和測試分析。

效能目標描述：系統在100個並發使用者下進行某種業務操作，回應時間不超過5秒。

 

14.3.2負載測試(Load Testing)

通過在被測系統上不斷增加壓力，直到效能指標。找到系統的處理極限，為系統調優提供資料。亦稱為可量性測試(Scalability Testing)。

極限描述：在給定條件下最多允許120個並發使用者訪問 或 在給定條件下最多在1小時內處理2100筆業務。

預期的效能指標：回應時間不超過10S 或 伺服器平均CPU利用率低於65%。

 

14.3.3壓力測試(Stress Testing)

測試系統在一定飽和狀態下，如CPU、記憶體等在飽和使用方式下，系統能夠處理的會話能力，以及系統是否會出現錯誤。

(1)主要目的是檢察系統處於壓力情況下時，應用的表現。通過增加訪問壓力，如增加並發使用者，使應用系統的資源使用保持在一定的水平。檢測此時的表現，有無錯誤資訊，回應時間等。

(2)通過類比負載等方法，使系統的資源使用達到較高的水平。比如設定為“CPU 75%，記憶體70%”情況下，有無錯誤、系統回應時間。其他，如JVM記憶體、DB串連數、DB的CPU等。

(3)測試系統的穩定性。如果一個系統能夠在壓力環境下穩定運行一段時間，那麼這個系統在通常的運行條件下應該可以達到令人滿意的穩定程度。

 

14.3.4配置測試(Configuration Testing)

對被測系統的軟/硬體環境的調整，瞭解各種不同環境對系統效能影響的程度，從而找到系統各項資源的最優分配原則。

(1)瞭解各種不同因素對系統效能影響的程度，從而判斷出最值得進行的調優操作。

(2)規劃領域內評估該如何調整才能實現系統的擴充性。

 

14.3.5並發測試(Concurrency Testing)

通過類比使用者的並發訪問，測試多使用者並發訪問同一個應用、模組或者資料記錄時是否存在死結或者其他效能問題。

(1)發現系統中可能隱藏的並發訪問時的問題。

(2)關注某些效能指標，如記憶體泄露、死結、長事務、線程/進程同步失敗等。

並發測試可驗證某種架構或設計的合理性，可作代碼層級的檢查和定位。如Jprofile、JProbe工具。

 

14.3.6可靠性測試(Reliablity Testing)

通過給系統載入一定的業務壓力(如資源在70-90%的使用率)的情況下，讓應用持續運行一段時間，測試系統在這種條件下是否能夠穩定運行。

(1)驗證系統是否能夠支援長期穩定的運行

(2)需要在壓力下持續一段時間的運行。

(3)關注系統的健全狀態。關注記憶體、CPU、系統回應時間有無明顯變化。

 

14.3.7失效恢複測試(Failover Testing)

針對有冗餘備份和負載平衡的系統設計的。用來檢驗如果系統局部發生故障，使用者能否繼續使用系統；以及如果發生，使用者將受到多大程度的影響。還關注問題發生時，能支援多少使用者訪問和採取何種應急措施。一般說來，只有對系統持續運行指標有明確要求的系統才需要進行此類測試。

 

14.4效能測試分析方法14.4.1效能測試的一般步驟

效能測試的一般步驟如下：

(1)制定目標和分析系統

(2)選擇測試度量的方法

(3)學習的相關技術和工具

(4)制定評估標準

(5)設計測試的情境和用例

(6)運行測試案例

(7)分析測試結果

 

14.4.2效能測試的估算方法14.4.2.1效能80-20原理方法

用以下例子來說明。

有200個使用者使用用戶端軟體進行業務處理（並發度至少要達到200並發），每年通過軟體進行處理的總業務量為：2000萬筆業務/年。

測試強度估算時採用如下假設前提：

全年的業務量集中在10個月完成，每個月20個工作日，每個工作日8個小時；

採用80-20原理，每個工作日中80%的業務在20%的時間內完成，即每天80%的業務在1.6小時內完成；

 

測試壓力的估算結果：

去年全年處理業務約2000萬筆，其中15%的業務處理每筆業務需對應用伺服器提交3次請求；70%的業務處理每筆業務需對應用伺服器提交2次請求；其餘15%的業務每筆業務嚮應用伺服器提交1次請求。根據以往統計結果，每年的業務增量為15%，考慮到今後三年業務發展的需要，測試需按現有業務量的2倍進行。

每年總的請求數量為：（2000*15%*3+2000*70%*2+2000*15%*1）*2="8000萬次/年。

每天的請求數量為：8000/200="40萬次/天。

每秒的請求數量為：（400000*80%）/（8*3600*20%）=55.6次/秒。

正常情況下，應用伺服器處理請求的能力至少應達到：56次/秒。

 

14.4.2.2效能下降曲線分析法

效能下降曲線實際上描述的是效能隨使用者數增長而出現下降趨勢的曲線。而這裡所說的“效能”可以是回應時間，也可以是輸送量或是單擊數/秒的資料。當然，一般來說，“效能”主要是指回應時間。

 

給出了一個“回應時間下降曲線”的樣本。

從圖1.6可以看到，一條曲線可以分為以下幾個部分：

(1)單使用者地區：對系統的一個單使用者的回應時間。這對建立效能的參考值很有作用。

(2)效能平坦區：在不進行更多效能調優情況下所能期望達到的最佳效能。這個地區可被用作基準或是benchmark。

(3)壓力地區：應用“輕微下降”的地方。典型的、最大的建議使用者負載是壓力地區的開始。

(4)效能拐點：效能開始“急劇下降”的點。

 

這幾個地區實際上明確標識了系統效能最優秀的區間，系統效能開始變壞的區間，以及系統效能出現急劇下降的點。對效能測試來說，找到這些區間和拐點，也就可以找到效能瓶頸產生的地方。

 

因此，對效能下降曲線分析法來說，主要關注的是效能下降曲線上的各個區間和相應的拐點，通過識別不同的區間和拐點，從而為效能瓶頸識別和效能調優提供依據。

 

14.4.3效能測試LoadRunner測試過程

給出了LoadRunner的效能測試過程。LoadRunner將效能測試過程分為計劃測試、測試設計、建立VU指令碼、建立測試情境、運行測試情境和分析結果6個步驟。

測試過程如下：

(1)計劃測試階段

主要進行測試需求的收集、典型情境的確定；

 

(2)測試設計階段

主要進行測試案例的設計；

 

(3)建立VU指令碼階段

主要根據設計的用例建立指令碼；

 

(4)建立測試情境階段

主要進行測試情境的設計和設定，包括監控指標的設定；

 

(5)運行測試情境階段

對已建立的測試情境進行執行，收集相應資料；

 

(6)分析結果階段

主要進行結果分析和報告工作。

 

14.5效能測試模型PTGM

效能測試模型PTGM（Performance Testing General Model），該效能測試模型將效能測試過程分為測試前期準備、測試載入器引入、測試計劃、測試設計與開發、測試執行和管理以及測試分析等6個步驟，

效能測試模型PTGM如所示。

 

 

 

在PTGM模型的描述中，作者為每個步驟設計了相應的活動，囊括了從“測試團隊組建”到“測試分析”的全部過程，每個活動都有詳細的活動指引和參考模板。

 

全國電腦技術與軟體專業技術資格（水平）考試【軟體評測師】-考試內容總結（十四）效能測試