對於性能測試,以上性能指標必須要有清楚的理解,自己總結如下:
1. 響應時間(RT)
是指系統對請求作出響應的時間。這個指標與人對軟件性能的主觀感受是一致的，因為它完整地記錄了整個計算機系統處理請求的時間。由於一個系統通常會提供許多功能，而不同功能的處理邏輯也千差萬別，因而不同功能的響應時間也不盡相同，甚至同一功能在不同輸入數據的情況下響應時間也不相同。所以，在討論一個系統的響應時間時，人們通常是指該系統所有功能的平均時間或者所有功能的最大響應時間。當然，往往也需要對每個或每組功能討論其平均響應時間和最大響應時間。
對於單機的沒有並發操作的應用系統而言，人們普遍認為響應時間是一個合理且准確的性能指標。需要指出的是，響應時間的絕對值並不能直接反映軟件的性能的高低，軟件性能的高低實際上取決於用戶對該響應時間的接受程度。對於一個游戲軟件來說，響應時間小於100毫秒應該是不錯的，響應時間在1秒左右可能屬於勉強可以接受，如果響應時間達到3秒就完全難以接受了。而對於編譯系統來說，完整編譯一個較大規模軟件的源代碼可能需要幾十分鍾甚至更長時間，但這些響應時間對於用戶來說都是可以接受的。
注意: 在性能測試中, 響應時間要做更細致划分
2. 吞吐量(Throughput)
吞吐量是指系統在單位時間內處理完成的客戶端請求的數量, 直接體現軟件系統的性能承載能力。這是目前最常用的性能測試指標。對於服務器來講,吞吐量越高越好.吞吐量是一個很寬泛的概念, 通常情況下，用“請求數/秒”或者“頁面數/秒”來衡量。
體現:
1. 業務角度: 業務數/小時 或 訪問人數/天等
2. 網絡流量: 字節數/小時 或 字節數/天等
3. 服務器性能處理能力(重點): TPS(每秒事務數) 和 QPS(每秒查詢數):
對於無並發的應用系統而言，吞吐量與響應時間成嚴格的反比關系，實際上此時吞吐量就是響應時間的倒數。前面已經說過，對於單用戶的系統，響應時間（或者系統響應時間和應用延遲時間）可以很好地度量系統的性能，但對於並發系統，通常需要用吞吐量作為性能指標。
對於一個多用戶的系統，如果只有一個用戶使用時系統的平均響應時間是t，當有你n個用戶使用時，每個用戶看到的響應時間通常並不是n×t，而往往比n×t小很多（當然，在某些特殊情況下也可能比n×t大，甚至大很多）。這是因為處理每個請求需要用到很多資源，由於每個請求的處理過程中有許多不走難以並發執行，這導致在具體的一個時間點，所占資源往往並不多。也就是說在處理單個請求時，在每個時間點都可能有許多資源被閑置，當處理多個請求時，如果資源配置合理，每個用戶看到的平均響應時間並不隨用戶數的增加而線性增加。實際上，不同系統的平均響應時間隨用戶數增加而增長的速度也不大相同，這也是采用吞吐量來度量並發系統的性能的主要原因。一般而言，吞吐量是一個比較通用的指標，兩個具有不同用戶數和用戶使用模式的系統，如果其最大吞吐量基本一致，則可以判斷兩個系統的處理能力基本一致。
3. TPS(Transactions Per Second,每秒事務數)
TPS是單位時間內處理事務的數量,從代碼角度來說,一段代碼或多段代碼可以組成一個事務.單位時間內完成的事務數越多,服務器的性能越好
4.. QPS(Query Per Second,每秒查詢數)
QPS是單位時間內處理請求的數量,比TPS划分的更細致一些,因為一個事務可能會包含多個請求. 在一個事務當中, 假如只包含一個請求, 那么 QPS 就是指該請求過程中, 發起的數據查詢總次數. 注意: 在 JMeter 當中, 把 TPS 和 QPS 簡單的認為是同一個指標, 用來考察服務器性能好壞
TPS和QPS的區別?
TPS(transaction per second)是單位時間內處理事務的數量，QPS(query per second)是單位時間內請求的數量。TPS代表一個事務的處理，可以包含了多次請求。很多公司用QPS作為接口吞吐量的指標，也有很多公司使用TPS作為標准，兩者都能表現出系統的吞吐量的大小，TPS的一次事務代表一次用戶操作到服務器返回結果，QPS的一次請求代表一個接口的一次請求到服務器返回結果。當一次用戶操作只包含一個請求接口時，TPS和QPS沒有區別。當用戶的一次操作包含了多個服務請求時，這個時候TPS作為這次用戶操作的性能指標就更具有代表性了。
個人理解如下：
1、Tps即每秒處理事務數，包括了
1）用戶請求服務器
2）服務器自己的內部處理
3）服務器返回給用戶
這三個過程，每秒能夠完成N個這三個過程，Tps也就是N；
2、Qps基本類似於Tps，但是不同的是，對於一個頁面的一次訪問，形成一個Tps；但一次頁面請求，可能產生多次對服務器的請求，服務器對這些請求，就可計入“Qps”之中。
例如：訪問一個頁面會請求服務器3次，一次訪問，產生一個“T”，產生3個“Q”
5.並發數
並發測試的用戶數量, 指系統可以同時承載的正常使用系統功能的用戶的數量。與吞吐量相比，並發用戶數是一個更直觀但也更籠統的性能指標。實際上，並發用戶數是一個非常不准確的指標，因為用戶不同的使用模式會導致不同用戶在單位時間發出不同數量的請求。一網站系統為例，假設用戶只有注冊后才能使用，但注冊用戶並不是每時每刻都在使用該網站，因此具體一個時刻只有部分注冊用戶同時在線，在線用戶就在瀏覽網站時會花很多時間閱讀網站上的信息，因而具體一個時刻只有部分在線用戶同時向系統發出請求。這樣，對於網站系統我們會有三個關於用戶數的統計數字：注冊用戶數、在線用戶數和同時發請求用戶數。由於注冊用戶可能長時間不登陸網站，使用注冊用戶數作為性能指標會造成很大的誤差。而在線用戶數和同事發請求用戶數都可以作為性能指標。相比而言，以在線用戶作為性能指標更直觀些，而以同時發請求用戶數作為性能指標更准確些。
用戶數概念划分:
1. 並發用戶數: 同一時間內發送請求的用戶數量(同一個請求/非同一個請求)
2. 在線用戶數: 某段時間內在系統內的用戶數量(不是所有在線用戶都會發送請求)
3. 系統用戶數: 系統內注冊的用戶數量(存在一人擁有多個賬號的情況)
結論: 系統用戶數 > 在線用戶數 > 並發用戶數
6.點擊數HPS (每秒點擊次數)
是指發起請求時, 服務端對請求進行響應的頁面資源對應的請求數量.
注意:
1. 日常操作中, 對頁面的點擊動作不是這里說的點擊數
2. 該指標只在 Web 項目中需要注意
例如,訪問百度首頁
7.資源利用率
定義: 系統資源(CPU/內存/磁盤/網絡)使用占比(使用量/總量*100%)
利用率指標:(沒有特殊要求情況下)
1. CPU 不超過 75%-85%
2. 內存不超過 80%
3. 硬盤不超過 90%(容量占有率/讀寫時間比)
8.錯誤率
定義: 錯誤率指系統在負載情況下，失敗交易的概率。
錯誤率 ＝ (失敗交易數/交易總數)*100%
注意:
1. 大多系統都會要求無限接近於 100% 成功率, 因此, 錯誤率一般都非常低
2. 相對穩定的系統產生的錯誤率又稱超時率(由網絡傳輸導致的)