關于系統使用者數，并發使用者數，線上使用者數，吞吐量(摘)
by:授客 QQ：1033553122
1、 關于系統使用者數，并發使用者數和線上使用者數
系統使用者數
俠義上來說，可以了解為系統注冊使用者數；廣義上來說，可以了解為所有通路過系統的使用者數
線上使用者數
俠義上來說，可以了解為已登入系統的使用者數；廣義來說，可以了解為目前時間通路系統的使用者數。
并發使用者數
可以分兩種：
1）同一時間點，執行同一（業務）操作的使用者數
2）同一時間點，執行不同（業務）操作的使用者數
注意：伺服器實際承受的壓力并不完全取決于并發使用者數，詳情見下面的例子。
例子（以51測試論壇為例）：
作為專業軟體測試論壇，會有很多測試者去論壇注冊帳号。
假設到現在已有75萬在該論壇注冊會員，那我們可以說，該論壇擁有75萬的系統使用者；
假設在某日早上9點，已有10萬會員登陸了論壇，那麼我們可以說，該論壇在某日9點時擁有10萬的線上使用者；
假設在這10萬已登陸會員中，某個時間點，有2萬會員正在送出新文章，有3萬會員正在編寫文章(假設編寫文章不會産生伺服器請求操作)；有1萬會員在文章頁面浏覽某文章内容；有1萬會員正在發呆，啥也不做；還有3萬會員正在點選某個文章，那麼我們可以說，某時間點，有2萬個并發使用者在送出新文章，有3萬個并發使用者在編寫文章，有1萬個并發使用者浏覽文章内容，有3萬個并發使用者在點選某個文章，，系統有9萬的并發使用者。
值得注意的是，這9萬并發使用者中，真正對系統産生壓力的隻有5萬使用者，即送出新帖和點選文章的使用者。換句話說，僅對系統發起了請求的并發使用者才會對系統施加壓力。
這也告訴我們，要好好測試一個系統的性能，必須先對使用者的(業務)操作進行分析，分離出使用者最常使用、最關心的（業務）操作，因為使用這些操作的人多，是以容易産生并發的情況。
計算公式：
(1)
其中，C 是平均并發使用者數；n是 login session的數量；L是login session的平均時長。T是考查的時間段長度。
注：login session指使用者從登陸系統到退出系統之間的時間段。
Cmax ≈ C + 3 （2）
其中，Cmax 是并發使用者數的峰值；C為公式（1）中的并發使用者數。
注意：
1.公式的得出是假設使用者login session産生符合泊松分布而估算得到的。
2.因為要精确估算平均使用者數和login session的長度并不容易，同時使用者的業務操作存在一定的時間分布，是以上述公式可能并不是很精确
3.基于第2點的建議：1)基于更細粒度的時間進行考察；2）考慮業務操作時間分布
2、吞吐量
性能測試中，可以俠義的了解為“機關時間内系統處理的使用者請求的數量”。一般情況，吞吐量用請求數/秒、頁面數/秒來衡量，從業務的角度，吞吐量也可用機關時間内的通路人數、處理的業務數等進行衡量。從網絡角度來，也可以機關時間内的處理的資料量等進行衡量。
例如，
對于一個Web應用系統來說，從系統的處理能力考慮，可以以頁面數/秒作為吞吐量的标準；對一個銀行的前台業務來說，可以以其機關時間内處理的業務數作為吞吐量的标準。
通常，對于互動式應用，使用者直接的體驗是“響應時間”，通過“并發使用者數”和“響應時間”可以确定系統的性能規劃；但對于非互動式應用，用“吞吐量”來描述我們對系統性能的期望可能更加合理。
作為性能測試的主要關注名額，吞吐量和并發使用者數之間存在一定的聯系，在沒有遇到性能瓶頸的時候，吞吐量可以采用如下公式計算：
其中，F表示吞吐量，
Nvu表示虛拟使用者數，R表示每個虛拟使用者數發起的請求數，T表示性能測試所用的時間。
注意：雖然吞吐量名額可被看作是系統承受壓力的展現，但是不同并發使用者數量的情況下，對同一個系統施加相同的吞吐量壓力，很可能會得到不同的測試結果。
作者：授客
QQ：1033553122
全國軟體測試QQ交流群：7156436
Git位址：https://gitee.com/ishouke
友情提示：限于時間倉促，文中可能存在錯誤，歡迎指正、評論！
作者五行缺錢，如果覺得文章對您有幫助，請掃描下邊的二維碼打賞作者，金額随意，您的支援将是我繼續創作的源動力，打賞後如有任何疑問，請聯系我!!!
微信打賞
支付寶打賞 全國軟體測試交流QQ群
