性能測試的概念（重點）

性能測試的概念

定義：軟件的性能是軟件的一種非功能特性，它關注的不是軟件是否可以完成特定的功能，而是在完成該功能時展現出來的及時性。

由定義可知性能關注的是軟件的非功能特性，因此通常來講性能測試介入的時機是在功能測試完成以後。在系統基礎功能測試驗證完成、系統趨於穩定的狀況下，纔會進行性能測試，不然性能測試是無心義的。另外，由定義中的及時性可知性能也是一種指標，能夠用時間或其它指標來衡量，一般咱們會使用某些工具或手段來檢測軟件的某些指標是否達到了要求，這就是性能測試。

性能測試定義：指經過自動化的測試工具模擬多種正常、峯值以及異常負載條件來對系統的各項性能指標進行測試。

性能測試類型

• 基準測試：在給系統施加較低壓力時，查看系統的運行情況並記錄相關數作爲基礎參考
• 負載測試：是指對系統不斷地增長壓力或增長必定壓力下的持續時間，直到-
  系統的某項或多項性能指標達到安全臨界值，不斷加壓使系統達到瓶頸，爲調優提供參考數據。
• 壓力測試：
  （1）穩定性壓力測試：在不一樣的給定的條件下（好比內存的使用，必定時間段內有多少請求等），系統表現出來的處理，反應能力（這裏會考慮系統的容錯能力，恢復能力）
  （2）破壞性壓力測試：不斷加壓，直至系統崩潰，掛掉，來得出系統的最大承受能力在哪兒
• 穩定性測試：在給系統加載必定業務壓力的狀況下，使系統運行一段時間，以此檢測系統是否穩定。
• 併發測試：測試多個用戶同時訪問同一個應用、同一個模塊或者數據記錄時是否存在死鎖或者其餘性能問題，
• 失效恢復測試：針對有多餘備份和負載均衡的系統設計,檢測若是系統局部發生故障，系統可否繼續使用
• 配置測試：經過對被測系統軟硬件環境的調整，瞭解各類不一樣環境對系統性能影響的程度，從而找到系統各項資源的最優分配原則

 

image.png

性能測試應用場景（領域）

性能測試應用場景（領域）主要有：
能力驗證、規劃能力、性能調優、缺陷發現、性能基準比較，

下表簡單介紹和對比了這幾個場景的各自用途和特色：

 

image.png

下表爲性能測試應用領域與測試方法關聯：

 

 

image.png

性能測試經常使用的指標

一、響應時間（Response Time）

定義：從用戶發送一個請求到用戶接收到服務器返回的響應數據這段時間就是響應時間

計算方法：Response time = （網絡時間 + 應用程序處理時間）

合理的響應時間 2/5/10 （2秒以內給客戶響應被用戶認爲是很是有吸引力的，5秒以內，比較糟糕，10秒以內，糟糕的用戶體驗，超過10秒，請求失敗）

響應時間-負載對應關係：

 

image.png

圖中拐點說明：

一、響應時間忽然增長

二、意味着系統的一種或多種資源利用達到的極限

三、一般能夠利用拐點來進行性能測試分析與定位

二、吞吐量

定義：單位時間內系統處理的客戶端請求的數量

計算方法：Throughput = (number of requests) / (total time)

吞吐量-負載對應關係：

①上升階段：吞吐量隨着負載的增長而增長，吞吐量和負載成正比；

②平穩階段：吞吐量隨着負載的增長而保持穩定，無太大變化或波動；

③降低階段：吞吐量隨着負載的增長而降低，吞吐量和負載成反比；

 

image.png

a1面積越大，說明系統的性能能力越強，a2面積越大，說明系統穩定性越好，a3面積越大，說明系統的容錯能力越好

吞吐率

吞吐量/傳輸時間，即單位時間內網絡上傳輸的數據量，也能夠指單位時間內處理客戶請求數量，它是衡量網絡性能的重要指標。

一般狀況下，吞吐率用「字節數/秒」來衡量，固然，也能夠用「請求數/秒」和「頁面數/秒」來衡量；

三、併發數

①狹義上的併發：全部用戶在同一時間點進行一樣的操做，通常指同一類型的業務場景，好比1000個用戶同時登錄系統；

②廣義上的併發：多個用戶與系統發生了交互，這些業務場景能夠是相同的也能夠是不一樣的，交叉請求和處理較多；

四、資源利用率

資源指標與硬件資源消耗直接相關，而系統指標則與用戶場景及需求直接相關：

 

image.png

資源指標：
CPU使用率：指用戶進程與系統進程消耗的CPU時間百分比，長時間狀況下，通常可接受上限不超過85%；

內存利用率：內存利用率=（1-空閒內存/總內存大小）*100%，通常至少有10%可用內存，內存使用率可接受上限爲85%；

磁盤I/O: 磁盤主要用於存取數據，所以當說到IO操做的時候，就會存在兩種相對應的操做，存數據的時候對應的是寫IO操做，取數據的時候對應的是是讀IO操做，通常使用% Disk Time（磁盤用於讀寫操做所佔用的時間百分比）度量磁盤讀寫性能；

網絡帶寬：通常使用計數器Bytes Total/sec來度量，其表示爲發送和接收字節的速率，包括幀字符在內；判斷網絡鏈接速度是不是瓶頸，能夠用該計數器的值和目前網絡的帶寬比較；

系統指標：
併發用戶數：單位時間內與系統發生交互的用戶數；

在線用戶數：某段時間內訪問系統的用戶數，這些用戶並不必定同時向系統提交請求；

平均響應時間：系統處理事務的響應時間的平均值；事務的響應時間是從客戶端提交訪問請求到客戶端接收到服務器響應所消耗的時間；

事務成功率：性能測試中，定義事務用於度量一個或者多個業務流程的性能指標，如用戶登陸、保存訂單、提交訂單操做都可定義爲事務，單位時間內系統能夠成功完成多少個定義的事務，在必定程度上反應了系統的處理能力，通常以事務成功率來度量；

超時錯誤率：主要指事務因爲超時或系統內部其它錯誤致使失敗佔總事務的比率；

資源利用-負載對應關係：

 

image.png

圖中拐點說明：

一、服務器某件資源使用逐漸達到飽和

二、一般能夠利用拐點來進行性能測試分析與定位

五、其它經常使用概念：

TPS

Transaction Per Second：每秒事務數，指服務器在單位時間內（秒）能夠處理的事務數量，通常以request/second爲單位；

QPS是查詢，而TPS是事務，事務是查詢的入口，也包含其餘類型的業務場景，所以QPS應該是TPS的子集！

QPS

Query Per Second：每秒查詢率，指服務器在單位時間內（秒）處理的查詢請求速率；

TPS和QPS都是衡量系統處理能力的重要指標，通常和併發結合起來判斷系統的處理能力；

Thinking Time

思考時間，在性能測試中，模擬用戶的真實操做場景。用戶操做的事務與事務之間是有必定間隔的，此時間內是不對服務器產生壓力的，引入這個概念是爲了併發測試（有交叉業務場景）時，業務場景比率更符合真實業務場景；

PV

Page View：頁面瀏覽量，一般是衡量一個頁面甚至網站流量的重要指標；

細分的話，有獨立訪問者數量、重複訪問者數量、單獨頁面訪問數量、用戶停留時間等類型；

RT/ART

Response Time/average Response Time：響應時間/平均響應時間，指一個事務花費多長時間完成；

通常來講，性能測試中平均響應時間更有表明意義。細分的話，還有最小最大響應時間，50%、90%用戶響應時間等；

性能測試流程

需求分析

須要分析的系統信息

 

image.png

須要分析的業務信息

 

image.png

性能需求評估

在實施性能測試以前，咱們須要對被測系統作相應的評估，主要目的是明確是否須要作性能測試。若是肯定須要作性能測試，須要進一步確立性能測試點和指標，明確該測什麼、性能指標是多少，測試經過or不經過的標準？性能指標也會根據狀況評估，要求被測系統能知足未來必定時間段的業務壓力。
業務角度:
系統是公司內部 or 對外？系統使用的人數的多少？
系統角度：
a）系統架構：b）數據庫要求：c）系統特殊要求：

肯定性能測試點：

• 關鍵業務：
  肯定被測項目是否屬於關鍵業務，有哪些主要的業務邏輯點，特別是跟交易相關的功能點。例如轉帳，扣款等接口。若是項目（或功能點）不屬於關鍵業務（或關鍵業務點）

• 日請求量：
  肯定被測項目各功能點的日請求量（能夠統計不一樣時間粒度下的請求量如：小時，日，周，月）。若是日請求量很高，系統壓力很大，並且又是關鍵業務，該項目須要作性能測試，並且關鍵業務點，能夠被肯定爲性能點

• 邏輯複雜度：
  斷定被測項目各功能點的邏輯複雜度。若是一個主要業務的日請求量不高，可是邏輯很複雜，則也須要經過性能測試。緣由是，在分佈式方式的調用中，當某一個環節響應較慢，就會影響到其它環節，形成雪崩效應。

• 運營推廣活動：
  根據運營的推廣計劃來斷定待測系統將來的壓力。未雨綢繆、防患於未然、下降運營風險是性能測試的主要目標。被測系統的性能不只能知足當前壓力，更須要知足將來必定時間段內的壓力。所以，事先了解運營推廣計劃，對性能點的制定有很大的做用。例如，運營計劃作活動，要求系統天天能支撐多少 PV、多少 UV，或者一個季度後，須要能支撐多大的訪問量等等數據。當新項目（或功能點）屬於運營重點推廣計劃範疇以內，則該項目（或功能點）也須要作性能測試。

創建性能指標

a.選取核心業務流程（重要程度/頻繁）
b.併發用戶數
c.事物吞吐需求
d.響應時間需求
e.系統佔用資源需求
f.可擴展性需求

創建系統負載模型

• 業務層面：
  （a）核心業務流程吞吐率
  （b）高峯期業務分佈時段

• 系統負載：
  （a） 高峯/日常場景吞吐率
  （b）CPU/IO/MEM/NETWORK

• 數據來源：
  （a）服務器端監控
  （b）數據庫日誌
  （c）用戶提出需求

制定測試計劃的實施時間和方案

預設本次性能測試各子模塊的起止時間和結束時間
測試環境的配置：局域網，虛擬機，操縱系統，數據庫，中間件
參與人員：誰負責哪些任務，測試策略。
產出：測試方案，分析結果

搭建測試環境

測試機環境

執行機環境：這個就是用來生成負載的執行機，一般須要在物理機上運行。
負載工具：JDK/Eclipse/LoadRuner or Jmeter或Galting等
監控工具：準備性能測試時的服務器資源、JVM、數據庫監控工具，以便進行後續的性能測試分析與調優

服務器環境

系統運行環境：這個一般就是咱們的測試環境，Linux系統/數據庫/應用服務/各類監控工具。
大部分公司的測試環境會低於生產環境，同時還須要考慮到不一樣的硬件配置是否會是制約系統性能的重要因素！所以在測試環境中，須要部署多個不一樣的測試環境，在不一樣的硬件配置上檢查應用系統的性能，配置大概是以下幾類：
①數據庫服務器
②應用服務器
③負載模擬器
④軟件運行環境，
平臺並對不一樣配置下系統的測試結果進行分析，得出最優結果（最適合當前系統的配置）

測試場景設計

經過和業務部門溝通以及以往用戶操做習慣，肯定用戶操做習慣模式，以及不一樣的場景用戶數量，操做次數，肯定測試指標，以及性能監控等

測試用例設計和腳本開發

選擇LoadRuner或者Jmeter，我使用的是Jmeter。

我使用Jmeter的工具進行錄製，
(PS:能直接寫腳本就本身寫儘可能少錄製，錄製有時候會有干擾)

對腳本進行修改，加強腳本，讓腳本更符合業務邏輯，可用性更強。
（1）參數化用戶輸入
（2）關聯數據
（3）增長事物
（4增長檢查點）

調試腳本
（1）Vugen單次回放
（2）Vugen屢次回放
（3）Controller單腳本多用戶
（4）Controller多腳本多用戶
（5）查看回放日誌

驗證腳本
（1）經過檢查點驗證
（2）經過查看後臺服務器日誌驗證
（3）經過測試系統查看運行後臺變化
（4）利用SQL語句查詢/插入/更新/修改，查看效果

測試數據準備

獲取數據有兩種方式：

（1）拉取生產數據，儘可能保持數據一致以及量級足夠
（2）利用腳本自動生成數據或者利用測試工具生成數據，（如：利用JDBC預埋數據）

a）負載測試數據：併發測試時須要多少數據？好比登陸場景？

b）DB數據量大小：爲了儘可能符合生產場景，須要模擬線上大量數據狀況，那麼要往數據庫裏提早插入必定的數據量。

性能測試執行和管理

執行測試腳本

在已部署好的測試環境中，按照業務場景和編號，按順序執行咱們已經設計好的測試腳本

測試結果記錄

根據測試採用的工具不一樣，結果的記錄也有不一樣的形式；展示方式：折線圖，統計圖，表格等，如今大多的性能測試工具都提供比較完整的界面圖形化的測試結果，固然，對於服務器的資源使用等狀況，能夠利用一些計數器或第三方監控工具來對其進行記錄，執行完測試後，對結果進行整理分析，

 

image.png

性能測試結果分析與調優

測試環境的系統性能分析

根據以前記錄獲得的測試結果，通過計算，與預約的性能指標進行對比，肯定是否達到了咱們須要的結果；如未達到，查看具體的瓶頸點，而後根據瓶頸點的具體數據，

瓶頸定位分析
吞吐量：二八原則 （即：80%的業務在20%的時間內完成/正太分佈）
響應時間：2/5/10原則
內存，磁盤，IO，進程，網絡分析
硬件，操做系統，中間件，應用瓶頸
進行具體狀況具體分析

性能調優
時間資源，人力資源
硬件資源，擴展性，影響

硬件設備對系統性能表現的影響分析

配置幾個不一樣的測試環境，故能夠根據不一樣測試環境的硬件資源使用情況圖進行分析，肯定瓶頸是再數據庫服務器、應用服務器抑或其餘方面，而後針對性的進行優化等操做

其餘影響因素分析

影響系統性能的因素不少，能夠從用戶能感覺到的場景分析，哪裏比較慢，哪裏速度尚可，這裏能夠根據2\5\8原則對其進行分析；
至於其餘諸如網絡帶寬、操做動做、存儲池、線程實現、服務器處理機制等一系列的影響因素，具體問題具體分析，

測試中發現的問題

在性能測試執行過程當中，可能會發現某些功能上的不足或存在的缺陷，以及須要優化的地方，須要屢次執行測試。

測試報告和跟蹤

性能測試報告是性能測試的里程碑，經過報告能展現出性能測試的最終成果，展現系統性能是否符合需求，是否有性能隱患

性能測試報告中須要闡明:
性能測試目標、
性能測試環境、
性能測試數據構造規則、
性能測試策略、
性能測試結果、
性能測試調優說明、
性能測試過程當中遇到的問題和解決辦法等。

性能測試工程師完成該次性能測試後，須要將測試結果進行備案，並作爲下次性能測試的基線標準，具體包括性能測試結果數據、性能測試瓶頸和調優方案等。同時須要將測試過程當中遇到的問題，包括代碼瓶頸、配置項問題、數據問題和溝通問題，以及解決辦法或解決方案，進行知識沉澱。