性能測試推廣手冊

性能測試概述

性能測試主要內容

性能測試是經過自動化的測試工具模擬多種正常、峯值以及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬於性能測試，二者能夠結合進行。經過負載測試，肯定在各類工做負載下系統的性能，目標是測試當負載逐漸增長時，系統各項性能指標的變化狀況。壓力測試是經過肯定一個系統的瓶頸或者不能接收的性能點，來得到系統能提供的最大服務級別的測試。

性能測試在軟件的質量保證中起着重要的做用，它包括的測試內容豐富多樣。中國軟件評測中心將性能測試歸納爲三個方面：應用在客戶端性能的測試、應用在網絡上性能的測試和應用在服務器端性能的測試。一般狀況下，三方面有效、合理的結合，能夠達到對系統性能全面的分析和瓶頸的預測。

性能測試的目的

性能測試目的是驗證軟件系統是否可以達到用戶提出的性能指標，同時發現軟件系統中存在的性能瓶頸，優化軟件，最後起到優化系統的目的。

　　包括如下幾個方面

　　1．評估系統的能力，測試中獲得的負荷和響應時間數據能夠被用於驗證所計劃的模型的能力，並幫助作出決策。

　　2．識別體系中的弱點：受控的負荷能夠被增長到一個極端的水平，並突破它，從而修復體系的瓶頸或薄弱的地方。

　　3．系統調優：重複運行測試，驗證調整系統的活動獲得了預期的結果，從而改進性能。

　　檢測軟件中的問題：長時間的測試執行可致使程序發生因爲內存泄露引發的失敗，揭示程序中的隱含的問題或衝突。

　　4．驗證穩定性（resilience）可靠性（reliability）：在一個生產負荷下執行測試必定的時間是評估系統穩定性和可靠性是否知足要求的惟一方法。

性能

測試的方法

一、性能測試（performance testing）：它是一種咱們常見的一種方法，它是經過模擬生產運行的業務壓力量和使用場景組合，測試系統的性能是否知足生產性能的要求。簡單地說就是要在特定的運行條件下驗證體系統的能力情況。

這種方法的主要特色有：

1） 這種方法的主要目的是驗證系統是否有系統說明具備的能力

2） 這種方法須要事先了解被測試系統典型場景，並具備肯定的性能目標

3） 這種方法要求在已肯定的環境下運行

二、負載測試(load testing)：有時被叫作可量性測試，它主要是經過在被測系統上不斷增長壓力，直到性能達到預約目標或者資源達到飽和狀態。它能夠找到體系統的處理能力的極限，爲系統調優提供數據。

它的主要特色有

1）它的主要目的是找到系統處理能力的極限

2） 須要在給定的測試環境下進行，也須要考慮被測試體系統的業務壓力量和典型場景，使得測試結果具備業務上的意義

3） 通常用來了解系統的性能容量，或是配合性能調優來使用。

三、、 壓力測試 (stress testing) ：這種方法測試系統在必定飽和狀態下，系統可以處理的會話能力，以及體系學統是否會出現錯誤。

這種性能測試方法具備如下特色

1) 它的主要目的是檢查系統處於壓力狀況下時，應用的表現

2) 通常經過模擬負載等方法，使得系統的資源使用達到較高的水平

3) 通常用於測試系統的穩定性

四、併發測試（concurrency testing）：經過模擬用戶的併發訪問，測試多用戶併發訪問同一個應用、同一模塊或者數據記錄時是否存在死鎖或者其它性能的問題

1）主要目的是發現系統中可能隱藏的併發訪問時的問題

2）主要關注系統可能存在的併發問題，例如系統中的內存泄漏、死鎖等方面的問題

3）這種方法能夠在開發的各個階段使用，須要相關的測試工具的配合和支持

WEB性能測試目標

目標	說明
度量最終用戶響應時間	完成一個業務流程須要多長時間
度量系統容量	在沒有顯著性能降低的前提下，系統可以處理多大的負載
肯定瓶頸	哪些因素會延長響應時間

注：據中國IT實驗室調查，平均響應時間在2秒之內的網頁吸引力是最大的；平均響應時間在5秒之內的爲可接受；平均響應時間在10秒以上的爲煩躁型（即用戶不可接收型）。

性能測試流程

性能測試流程

第一，分析產品結構，明確性能測試的需求，包括併發、極限的性能要求。

第二，分析應用場景和用戶數據，細分用戶行爲和相關的數據流，肯定測試點或測試接口，列示系統接口的可能瓶頸，通常是先主幹接口再支線接口，並完成初步的測試用例設計。

第三，依據性能測試需求和肯定的測試點進行測試用例設計，並明確不一樣測試方案的重要程度或優先級做爲取捨評估的依據，必要時在前期產品設計中提出支持性能測試的可測試性設計方案和對測試工具的需求。

第四，完成性能測試用例設計、分類選擇和依據用戶行爲分析設計測試規程，並準備好測試用例將用到的測試數據。

第五，肯定採用的測試工具。

第六，進行初驗測試，根據測試結果分析性能瓶頸，經過迭代保證基本的指標等測試的環境。

第七，迭代進行全面的性能測試，完成計劃中的性能測試用例的執行。

第八，完成性能測試評估報告。

性能測試結果的分析流程

具體問題具體分析（這是因爲不一樣的應用系統，不一樣的測試目的，不一樣的性能關注點）

• 查找瓶頸時按如下順序，由易到難。

服務器硬件瓶頸-〉網絡瓶頸（對局域網，能夠不考慮）-〉服務器操做系統瓶頸（參數配置）-〉中間件瓶頸（參數配置，數據庫，web服務器等）-〉應用瓶頸（SQL語句、數據庫設計、業務邏輯、算法等）

注：以上過程並非每一個分析中都須要的，要根據測試目的和要求來肯定分析的深度。對一些要求低的，咱們分析到應用系統在未來大的負載壓力（併發用戶數、數據量）下，系統的瓶頸在哪兒就夠了。

分析的信息來源：

•1 根據場景運行過程當中的錯誤提示信息

•2 根據測試結果收集到的監控指標數據

設計性能測試用例的原則

設計性能測試用例注意的原則：

能夠知足預期性能指標測試用例要求的，就沒有必要設計更多的內容，由於用例越多，執行的本也越高。

必定要服從總體性能測試策略，千萬不能僅從技術角度來考慮設計「全面」的測試用例，「全面」應該以是否知足本身的測試要求做爲標準。

只有根據實際項目的特色制定合理的性能測試策略、編寫適當的性能測試用例，並在測試實施中靈活地變通才能夠作好性能測試工做。

性能測試輸出文檔：

測試計劃：主要包含測試範圍、測試環境、測試方案簡介、風險分析等，測試計劃要進行評審後方可生效。

測試報告：主要包含測試過程記錄、測試分析結果、系統調整建議等。

測試經驗總結：不斷總結工做經驗是創建學習型團隊的基礎，實踐－總結－再實踐

參考文檔

性能測試術語及縮寫詞

測試時間：一輪測試從開始到結束所使用的時間

併發線程數：測試時同時訪問被測系統的線程數。注意，因爲測試過程當中，每一個線程都是以儘量快的速度發請求，與實際用戶的使用有極大差異，因此，此數據不等同於實際使用時的併發用戶數。

每次時間間隔：測試線程發出一個請求，並獲得被測系統的響應後，間隔多少時間發出下一次請求。

平均響應時間：測試線程向被測系統發請求，全部請求的響應時間的平均值。

處理能力：在某一特定環境下，系統處理請求的速度。

cache影響係數：測試數據未必如實際使用時分散，cache在測試過程當中會比實際使用時發揮更大做用，從而使測試出的最高處理能力偏高，考慮到這個因素而引入的係數。

用戶習慣操做頻率：根據用戶使用習慣估算出來的，單個用戶在一段時間內，使用此類功能的次數。一般以一天內某段固定的高峯使用時間來統計，若是一天內沒有哪段時間是固定的高峯使用時間，則以一天的工做時間來統計。

預期平均響應時間：由用戶提出的，但願系統在多長時間內響應。注意，這個值並非某一次訪問的時間，而是一段時間屢次訪問後的平均值。

最大併發用戶數：在給定的預期平均響應時間下，系統最多能支持多少個併發用戶。這個數據就是實際能夠同時使用系統的用戶數。

併發：狹義的併發通常分兩種狀況。一種是嚴格意義上的併發，即全部用戶在同一時刻作同一件事情或操做，這種操做通常針對同一類型的業務。另外一種併發是廣義的併發。這種併發與狹義的併發的區別是儘管多個用戶對系統發出了請求或進行了操做，可是這些請求或操做能夠是相同的，也能夠是不一樣的。對總體系統而言，任然有不少用戶同時對系統進行操做，所以，仍然屬於併發的範疇。

能夠看出，廣義的併發是包含狹義的併發的，並且廣義的併發更接近用戶的實際使用狀況，由於對大多數系統而言，只有數量不多的用戶進行「嚴格意義上的併發」。對於性能測試而言，這兩種併發通常都須要進行測試，一般的作法是先進行嚴格意義上的併發測試。嚴格意義上的併發通常發生在使用比較頻繁的模塊中，儘管發生的機率不是特別高，可是一旦發生性能問題，後果極可能是致命的。嚴格意義上的併發測試每每和功能測試關聯起來，由於只要併發功能遇到異常一般都是程序的問題，這種測試也是健壯性和穩定性測試的一部分。

併發用戶數量：關於併發用戶數量，有兩種常見的錯誤觀點。一種錯誤觀點是把併發用戶數量理解爲使用系統的所有用戶的數量，理由是這些用戶可能同時使用系統；還有一種比較接近正確的觀點是把用戶在線數量理解爲併發用戶數量。實際上，在線用戶不必定會和其餘用戶發生併發，例如正在瀏覽網頁信息的用戶，對服務器是沒有任何影響的。可是，用戶在線數量是統計併發用戶數量的主要依據之一。

併發主要針對服務器而言，是否併發的關鍵是看用戶的操做是否對服務器產生了影響。所以，併發用戶數量的正確理解是，在同一時刻與服務器進行交互的在線用戶數量。這些用戶的最大特徵是和服務器發生了交互，這種交互既能夠是單向傳送數據的，也能夠是雙向傳送數據的。

併發用戶數量的統計方法目前尚未準確的公式，由於不一樣的系統會有不一樣的併發特色。例如OA系通通計併發用戶的經驗公式爲：使用系統的用戶數量*（5%~20%）。對於這個公式，沒有必要拘泥於計算出的結果，由於爲了保證系統的擴展空間，測試時的併發用戶數量就會稍稍大一些，除非要測試系統能承受的最大併發用戶數量。舉例說明：若是一個OA系統的指望用戶爲1000個，只要測試出系統能支持200個併發用戶就能夠了。

請求響應時間：請求響應時間是指從客戶端發出請求到獲得響應的整個過程的時間。這個過程從客戶端發出一個請求開始計時，到客戶端接收到從服務器端返回的響應結果計時結束。在某些工具中，請求響應時間一般會被稱爲"TTLB"，即"Time to last byte"，意思是從發送一個請求開始，到客戶端接收到最後一個字節的響應爲止所耗費的時間。請求響應時間的單位通常爲「秒」或「毫秒」。

事物響應時間：事物可能由一系列請求組成，事物的響應時間主要針對用戶而言，屬於宏觀上的概念，是爲了向用戶說明業務響應時間而提出來的。例如：跨行取款食物的響應時間就是由一系列的請求組成的。事物響應時間和業務吞吐率都是直接衡量系統性能的參數。

吞吐量：指在一次性能測試過程當中網絡上傳輸的數據量的總和。吞吐量/傳輸時間，就是吞吐率。

吞吐率（Throughput）：一般用來指單位時間內網絡上傳輸的數據量，也能夠指單位時間內處理的客戶端請求數量。是衡量網絡性能的重要指標。

可是從用戶或業務角度來看，吞吐率也能夠用「請求數/秒」或「頁面數/秒」、「業務數/小時或天」、「訪問人數/天」、「頁面訪問量/天」來衡量。例如在銀行卡審批系統中，能夠用「千件/每小時」來衡量系統的業務處理能力。

TPS（Transaction Per Second）：每秒鐘系統可以處理的交易或事物的數量。它是衡量系統處理能力的重要指標。TPS是LoadRunner中重要的性能參數指標。

點擊率（Hit Per Second）：秒鐘用戶向Web服務器提交的HTTP請求書。這個指標是Web應用特有的一個指標：Web應用是「請求-響應」模式，用戶發出一次申請，服務器就要處理一次，因此「點擊」是Web應用可以處理交易的最小單位。若是把每次點擊定義爲一次交易，點擊率和TPS就是一個概念。不難看出，點擊率越大，對服務器的壓力也越大。點擊率只是一個性能參考指標，重要的是分析點擊時產生的影響。

須要注意的是，這裏的點擊不是指鼠標的一次「單擊」操做，而是在一次「單擊」操做中，客戶端可能向服務器發出多個HTTP請求。

資源利用率：資源利用率指的是對不一樣系統資源的使用程度，例如服務器的CPU利用率、磁盤利用率等。資源利用率是分析系統性能指標而改善性能的主要依據，所以，它是Web性能測試工做的重點。

資源利用率主要針對Web服務器、操做系統、數據庫服務器、網絡等，是測試和分析瓶頸的主要參數。在性能測試中，要根據需求採集具體的資源利用率參數來進行分析。

成功率＝成功次數÷（成功次數＋失敗次數）

處理能力＝成功次數÷測試時間

最短平均響應時間＝MIN（平均響應時間）

最高處理能力＝MAX（處理能力）×（1－cache影響係數）

最大併發用戶數＝（最高處理能力－1÷（預期平均響應時間－最短平均響應時間＋（1÷最高處理能力）））÷用戶習慣操做頻率

注：公式要注意各時間單位的不一樣和轉換