從兩個層面定義性能場景的需求指標：業務指標和技術指標
業務指標和性能指標之間的關系：
從圖中可以知道：
所有的技術指標都是在有業務場景的前提下制定的
技術指標和業務指標之間也要有詳細的換算過程
性能測試行業常用的性能指標表示法：
1、TPS（Transactions Per Second）：每秒事務數
在性能測試過程中，TPS 之所以重要，是因為它可以反應出一個系統的處理能力。TPS 在不同的行業、不同的業務中定義的粒度都是不同的。所以不管在哪里用 TPS，一定要有一個前提，就是所有相關的人都要知道你的 T 是如何定義的。
通常情況下，我們會根據場景的目的來定義 TPS 的粒度。如果是接口層性能測試，T 可以直接定義為接口級；如果業務級性能測試，T 可以直接定義為每個業務步驟和完整的業務流。
舉個例子：
如果我們要單獨測試接口 1、2、3，那 T 就是接口級的；如果我們要從用戶的角度來下一個訂單，那 1、2、3 應該在一個 T 中，這就是業務級的了
2、QPS（Query Per Second）：SQL 的每秒執行條數
從第一個例子中QPS其實描述的是服務后面接的數據庫中 SQL 的每秒執行條數。如果描述的是前端的每秒查詢數，那就不包括插入、更新、刪除操作了。顯然這樣的指標用來描述系統整體的性能是不夠全面的。所以不建議用 QPS 來描述系統整體的性能，以免產生誤解。
3、RPS（Request per second）：每秒請求數
請求這個詞比較廣泛，要看是哪個層面的請求
如果一個用戶點擊了一次，發出來 3 個 HTTP Request，調用了 2 次訂單服務，調用了 2 次庫存服務，調用了 1 次積分服務，那么這個請求數是3+2+2+1=8嗎？不是的，如果要描述整體，最多算是有 3 個 RPS。
4、HPS（Hits Per Second），每秒點擊數
Hit 一般在性能測試中，都用來描述 HTTP Request
5、CPS/CPM（Calls Per Second/ Calls Per Minutes）：每秒 / 每分鍾調用次數
6、RT（Response Time）：響應時間
RT = T2-T1
響應時間的概念簡單至極，但定位就復雜了。性能測試工具都會記錄響應時間，但是，都不會給出后端鏈路到底哪里慢，因此我們需要進行時間拆分，比如：
先畫架構圖，看請求鏈路，然后再一層層找下去，在所有服務的進出口上都做記錄，然后計算結果就行了。也有鏈路監控工具和一些 Metrics 的使用，讓這個需求變得簡單了不少：
壓力工具中的線程數和用戶數與 TPS
並發線程數在沒有模擬真實用戶操作的情況下，和真實的用戶操作差別非常遠。從上圖中，可以知道壓力工具是 4 個並發線程，由於每個線程都可以在一秒內完成 4 個事務，所以總的TPS是16
那么用戶數怎么來定義呢？有些人認為一個系統如果有 1 萬個用戶在線，那就應該測試 1 萬的並發線程，這種邏輯實在是不技術。通常，我們會對在線的用戶做並發度的分析，在很多業務中，並發度都會低於 5%，甚至低於 1%。
拿 5% 來計算，就是 10000 用戶 x5%=500(TPS)，注意哦，這里是 TPS，而不是並發線程數。如果這時響應時間是 100ms，那顯然並發線程數是 500TPS/(1000ms/100ms)=50(並發線程)。
通過這樣簡單的計算邏輯，我們就可以看出來用戶數、線程數和 TPS 之間的關系了：
但是！響應時間肯定不會一直都是 100ms 的嘛。所以通常情況下，上面的這個比例都不會固定，而是隨着並發線程數的增加，會出現趨勢上的關系
————————————————
原文鏈接：https://blog.csdn.net/ZhangYongWei1955/article/details/106890788