性能測試的概念
定義：軟件的性能是軟件的一種非功能特性，它關注的不是軟件是否能夠完成特定的功能，而是在完成該功能時展示出來的及時性。
由定義可知性能關注的是軟件的非功能特性，所以一般來說性能測試介入的時機是在功能測試完成之后。在系統基礎功能測試驗證完成、系統趨於穩定的情況下，才會進行性能測試，否則性能測試是無意義的。另外，由定義中的及時性可知性能也是一種指標，可以用時間或其它指標來衡量，通常我們會使用某些工具或手段來檢測軟件的某些指標是否達到了要求，這就是性能測試。
性能測試定義：指通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項性能指標進行測試。
性能測試類型
- 基准測試：在給系統施加較低壓力時，查看系統的運行狀況並記錄相關數做為基礎參考
- 負載測試：是指對系統不斷地增加壓力或增加一定壓力下的持續時間，直到-
系統的某項或多項性能指標達到安全臨界值，不斷加壓使系統達到瓶頸，為調優提供參考數據。- 壓力測試：
（1）穩定性壓力測試：在不同的給定的條件下（比如內存的使用，一定時間段內有多少請求等），系統表現出來的處理，反應能力（這里會考慮系統的容錯能力，恢復能力）
（2）破壞性壓力測試：不斷加壓，直至系統崩潰，掛掉，來得出系統的最大承受能力在哪兒- 穩定性測試：在給系統加載一定業務壓力的情況下，使系統運行一段時間，以此檢測系統是否穩定。
- 並發測試：測試多個用戶同時訪問同一個應用、同一個模塊或者數據記錄時是否存在死鎖或者其他性能問題，
- 失效恢復測試：針對有多余備份和負載均衡的系統設計,檢測如果系統局部發生故障，系統能否繼續使用
- 配置測試：通過對被測系統軟硬件環境的調整，了解各種不同環境對系統性能影響的程度，從而找到系統各項資源的最優分配原則
性能測試應用場景（領域）
性能測試應用場景（領域）主要有：
能力驗證、規划能力、性能調優、缺陷發現、性能基准比較，
下表簡單介紹和對比了這幾個場景的各自用途和特點：
下表為性能測試應用領域與測試方法關聯：
性能測試常用的指標
1、響應時間（Response Time）
定義：從用戶發送一個請求到用戶接收到服務器返回的響應數據這段時間就是響應時間
計算方法：Response time = （網絡時間 + 應用程序處理時間）
合理的響應時間 2/5/10 （2秒之內給客戶響應被用戶認為是非常有吸引力的，5秒之內，比較糟糕，10秒之內，糟糕的用戶體驗，超過10秒，請求失敗）
響應時間-負載對應關系：
圖中拐點說明：
1、響應時間突然增加
2、意味着系統的一種或多種資源利用達到的極限
3、通常可以利用拐點來進行性能測試分析與定位
2、吞吐量
定義：單位時間內系統處理的客戶端請求的數量
計算方法：Throughput = (number of requests) / (total time)
吞吐量-負載對應關系：
①上升階段：吞吐量隨着負載的增加而增加，吞吐量和負載成正比；
②平穩階段：吞吐量隨着負載的增加而保持穩定，無太大變化或波動；
③下降階段：吞吐量隨着負載的增加而下降，吞吐量和負載成反比；
a1面積越大，說明系統的性能能力越強，a2面積越大，說明系統穩定性越好，a3面積越大，說明系統的容錯能力越好
吞吐率
吞吐量/傳輸時間，即單位時間內網絡上傳輸的數據量，也可以指單位時間內處理客戶請求數量，它是衡量網絡性能的重要指標。
通常情況下，吞吐率用“字節數/秒”來衡量，當然，也可以用“請求數/秒”和“頁面數/秒”來衡量；
3、並發數
①狹義上的並發：所有用戶在同一時間點進行同樣的操作，一般指同一類型的業務場景，比如1000個用戶同時登陸系統；
②廣義上的並發：多個用戶與系統發生了交互，這些業務場景可以是相同的也可以是不同的，交叉請求和處理較多；
4、資源利用率
資源指標與硬件資源消耗直接相關，而系統指標則與用戶場景及需求直接相關：
資源指標：
CPU使用率：指用戶進程與系統進程消耗的CPU時間百分比，長時間情況下，一般可接受上限不超過85%；
內存利用率：內存利用率=（1-空閑內存/總內存大小）*100%，一般至少有10%可用內存，內存使用率可接受上限為85%；
磁盤I/O: 磁盤主要用於存取數據，因此當說到IO操作的時候，就會存在兩種相對應的操作，存數據的時候對應的是寫IO操作，取數據的時候對應的是是讀IO操作，一般使用% Disk Time（磁盤用於讀寫操作所占用的時間百分比）度量磁盤讀寫性能；
網絡帶寬：一般使用計數器Bytes Total/sec來度量，其表示為發送和接收字節的速率，包括幀字符在內；判斷網絡連接速度是否是瓶頸，可以用該計數器的值和目前網絡的帶寬比較；
系統指標：
並發用戶數：單位時間內與系統發生交互的用戶數；
在線用戶數：某段時間內訪問系統的用戶數，這些用戶並不一定同時向系統提交請求；
平均響應時間：系統處理事務的響應時間的平均值；事務的響應時間是從客戶端提交訪問請求到客戶端接收到服務器響應所消耗的時間；
事務成功率：性能測試中，定義事務用於度量一個或者多個業務流程的性能指標，如用戶登錄、保存訂單、提交訂單操作均可定義為事務，單位時間內系統可以成功完成多少個定義的事務，在一定程度上反應了系統的處理能力，一般以事務成功率來度量；
超時錯誤率：主要指事務由於超時或系統內部其它錯誤導致失敗占總事務的比率；
資源利用-負載對應關系：
圖中拐點說明：
1、服務器某件資源使用逐漸達到飽和
2、通常可以利用拐點來進行性能測試分析與定位
5、其它常用概念：
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%用戶響應時間等；
性能測試流程
需求分析
需要分析的系統信息
需要分析的業務信息
性能需求評估
在實施性能測試之前，我們需要對被測系統做相應的評估，主要目的是明確是否需要做性能測試。如果確定需要做性能測試，需要進一步確立性能測試點和指標，明確該測什么、性能指標是多少，測試通過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數據量大小：為了盡量符合生產場景，需要模擬線上大量數據情況，那么要往數據庫里提前插入一定的數據量。
性能測試執行和管理
執行測試腳本
在已部署好的測試環境中，按照業務場景和編號，按順序執行我們已經設計好的測試腳本
測試結果記錄
根據測試采用的工具不同，結果的記錄也有不同的形式；展現方式：折線圖，統計圖，表格等，現在大多的性能測試工具都提供比較完整的界面圖形化的測試結果，當然，對於服務器的資源使用等情況，可以利用一些計數器或第三方監控工具來對其進行記錄，執行完測試后，對結果進行整理分析，
性能測試結果分析與調優
測試環境的系統性能分析
根據之前記錄得到的測試結果，經過計算，與預定的性能指標進行對比，確定是否達到了我們需要的結果；如未達到，查看具體的瓶頸點，然后根據瓶頸點的具體數據，
瓶頸定位分析
吞吐量：二八原則 （即：80%的業務在20%的時間內完成/正太分布）
響應時間：2/5/10原則
內存，磁盤，IO，進程，網絡分析
硬件，操作系統，中間件，應用瓶頸
進行具體情況具體分析
性能調優
時間資源，人力資源
硬件資源，擴展性，影響
硬件設備對系統性能表現的影響分析
配置幾個不同的測試環境，故可以根據不同測試環境的硬件資源使用狀況圖進行分析，確定瓶頸是再數據庫服務器、應用服務器抑或其他方面，然后針對性的進行優化等操作
其他影響因素分析
影響系統性能的因素很多，可以從用戶能感受到的場景分析，哪里比較慢，哪里速度尚可，這里可以根據2\5\8原則對其進行分析；
至於其他諸如網絡帶寬、操作動作、存儲池、線程實現、服務器處理機制等一系列的影響因素，具體問題具體分析，
測試中發現的問題
在性能測試執行過程中，可能會發現某些功能上的不足或存在的缺陷，以及需要優化的地方，需要多次執行測試。
測試報告和跟蹤
性能測試報告是性能測試的里程碑，通過報告能展示出性能測試的最終成果，展示系統性能是否符合需求，是否有性能隱患
性能測試報告中需要闡明:
性能測試目標、
性能測試環境、
性能測試數據構造規則、
性能測試策略、
性能測試結果、
性能測試調優說明、
性能測試過程中遇到的問題和解決辦法等。
性能測試工程師完成該次性能測試后，需要將測試結果進行備案，並做為下次性能測試的基線標准，具體包括性能測試結果數據、性能測試瓶頸和調優方案等。同時需要將測試過程中遇到的問題，包括代碼瓶頸、配置項問題、數據問題和溝通問題，以及解決辦法或解決方案，進行知識沉淀。