通常我們都從兩個層面定義效能場景的需求指標：業務指標和技術指標。
技術指標不能脫離業務指標，所有的技術指標都是在有業務場景的前提下制定的，而技術指標和業務指標之間也要有詳細的換算過程。這樣一來，技術指標就不會是一塊飛地。同時，在回答了技術指標是否滿足的同時，也能回答是否可以滿足業務指標。
有了這樣的關聯關係，下面我們看一下效能測試行業常用的效能指標表示法。
為了區分這些概念，我們先說一下tps（transactions per second）。我們都知道tps是效能領域中乙個關鍵的效能指標概念，它用來描述每秒事務數。我們也知道tps在不同的行業、不同的業務中定義的粒度都是不同的。所以不管你在**用tps，一定要有乙個前提，就是所有相關的人都要知道你的t是如何定義的。
通常情況下，我們會根據場景的目的來定義tps的粒度。如果是介面層效能測試，t可以直接定義為介面級；如果業務級效能測試，t可以直接定義為每個業務步驟和完整的業務流。
執行緒數、使用者數與tps業務模型的28原則是個什麼鬼？
有些文章中寫效能測試要按28原則來計算併發使用者數。大概的意思就是，如果一天有1000萬的使用者在使用，系統如果開10個小時的話，在計算併發使用者數的時候，就用2小時來計算，即1000萬使用者在2小時內完成業務。
但是，這個邏輯在乙個特定的業務系統中是沒有任何價值的。因為每個系統的併發度都由業務來確定，而不是靠這樣的所謂的定律來支配著業務。
如果我們做了大量的樣本資料分析，最後確實得出了28的比例，我覺得那也是可以的。但是如果什麼資料都沒有分析，直接使用28比例來做評估和計算，那就跟耍流氓沒有區別。
業務模型應該如何得到呢？這裡有兩種方式是比較合理的：
直接在生產環境中做流量複製的方式或壓力工具直接對生產環境發起壓力的方式做壓力測試。這種方式被很多人稱為全鏈路壓測。其實在生產中做壓力測試的方式，最重要的工作不是技術，而是組織協調能力。相信參與過的人都能體會這句話的重量。
但併發使用者數不同，他們需要在系統中執行某個動作。我們要測試的重中之重，就是統計這些正在執行動作的併發使用者數。
這裡有乙個比較嚴重的理解誤區，那就是壓力工具中的執行緒或使用者數到底是不是用來描述效能表現的？我們通過乙個示意圖來說明：
通過這個圖，我們可以看到乙個簡單的計算邏輯：
如果每個執行緒的20tps，顯然只需要5個執行緒就夠了（請注意，這裡說的執行緒指的是壓力機的執行緒數）。
這時對server來說，它處理的就是100tps，平均響應時間是50ms。50ms就是根據1000ms/20tps得來的（請注意，這裡說的平均響應時間會在乙個區間內浮動，但只要tps不變，這個平均響應時間就不會變）。
如果我們有兩個server執行緒來處理，那麼乙個執行緒就是50tps，這個很直接吧。
請大家注意，這裡我有乙個轉換的細節，那就是併發使用者數到壓力機的併發執行緒數。這一步，我們通常怎麼做呢？就是基準測試的第一步。關於這一點，我們在後續的場景中交待。
而我們通常說的「併發」這個詞，依賴tps來承載的時候，指的都是server端的處理能力，並不是壓力工具上的併發執行緒數。在上面的例子中，我們說的併發就是指伺服器上100tps的處理能力，而不是指5個壓力機的併發執行緒數。
不要在意用的是什麼壓力工具，只要在意服務端的處理能力就可以了。
Jmeter 效能測試 效能指標
一 效能測試關注的重要指標，包括 1.系統資源指標 1 cpu佔用率 2 記憶體佔用率 3 io 4 頻寬 2.系統指標 1 併發使用者數 2 tps 每秒鐘處理的請求數 3 響應時間 4 事務成功率 5 超時錯誤率 二 效能測試需要注意的事項 1 測試環境要和線上的真實環境一樣，包括配置 集群方式...
效能測試 效能指標 1
一 效能測試的指標 相應時間 併發使用者數 吞吐量系統效能計數器 思考時間 總結 多快好省 多 併發量，快 響應時間，好 穩定性，長時間執行，省 資源使用率 思考時間 二 響應時間 對請求作出響應所需要的時間，是使用者感知的軟體效能的主要指標 響應時間包括 端到端 1 使用者客戶端呈現的時候 2 請...
web效能測試中效能指標
web效能測試的部分概念一般來說，乙個web請求的處理包括以下步驟 1 客戶傳送請求 2 web server接受到請求，進行處理 3 web server向db獲取資料 4 web server生成使用者請求的object 頁面 返回給使用者。從客戶傳送請求開始到客戶接收到最後乙個位元組的時間成為...