多使用者，同時——二個因素缺一不可
併發的兩種情況
一種是嚴格意義上的併發，即所有的使用者在同一時刻做同一件事或操作，這種操作一般指做同一型別的業務。比如，所有使用者同一時刻做併發登陸，同一時刻做表單提交。
另外一種併發是廣義範圍的併發，這種併發與前一種併發的區別是，儘管多個使用者對系統發出了請求或者進行了操作，但是這些請求或都操作可以是相同的，也可以是不同的。比如，在同一時刻有使用者在登入，有使用者在提交表單。
上面試談了這麼多併發，現在又說真正意義上的併發不存在。何解？學作業系統原理的同學都知道，cpu在乙個時間點上只能幹一件事兒。為什麼我們可以邊看電影，邊打字，邊語音。因為cpu很快很快，他可以處理一下電影，再處理一下打字，再處理一下語音。因為它很快，所以，它可以在多個程式之間快速瞬間的切換，給你造成的假象就是它在同時做這些事情。（現在的雙核、四核的cpu另說）
那麼我們的系統在接到使用者的請求後也要呼叫cpu來完成某些處理，然後返回給使用者。那麼我們對系統有做併發測試是測什麼呢？舉個簡單的例子。假如有一位神醫，他的看病速度非常快，假設他的看病速度是不變的；然後有一群接待人員來接待看病的客人，有成千上萬的病人來看病，接待人員要想各種辦法來做好接待工作，使病人更快的看到病。比如，可以事先諮詢病人得的什麼病，然後將病人進行分類，比如可以擴大接待室，讓更多的病人可以進到醫院來看病等。
神醫就是我們的cpu，接待人員就是我們的系統，病人就使用者，我們做效能測試的目的就是了解接待人員哪個地方給醫院看病造成了瓶頸。只來乙個病人，醫院的看病速度與服務很好。一下子來十萬個病人各種問題就出來了。接待人員的服務態度下降，多餘的人員跟本進不到醫院去，醫院的洗手間不夠用，造成病人無法上則所而離開，這些都屬於系統問題。所以，我們一般測試的目的是看醫院的接待能力。
併發使用者數不應該從業務角度出發，應該是從服務端承受的壓力出發。
那麼系統的併發使用者數是多少呢?2萬麼？no!這2萬只表示在系統最高峰時有這麼多使用者登入了**，並不表示實際伺服器的承受壓力。因為伺服器承受壓力還與具體的使用者訪問模式相關，在這2萬使用者中考察某乙個時間點對使用者發出請求數，可以會大大縮水。那麼，該系統的服務端承受的最大併發訪問數是多少呢？這個取決於業務併發使用者數和業務場景，一般可以通過伺服器日誌的分析得到。
效能測試 測試方案 併發使用者數
併發使用者數 同時向伺服器端傳送請求的客戶數。一般根據系統場景和客戶要求來制定具體值。虛擬使用者數和併發使用者數的聯絡 oa系統使用使用者是100個，這個就是系統使用者數。估算併發數的公示 1 計算平均的併發使用者數 c nl t 2 併發使用者數峰值 c c 3根號c 公式 1 中，c是平均的併發...
效能測試如何計算併發使用者數
在實際的 效能測試 工作 中，測試人員常常會關心到併發使用者數，也就是從業務角度關注究竟應該設定多少個併發數比較合理，以下是乙個估算併發使用者數的方法 1 計算平均的併發使用者數 c nl t 2 併發使用者數峰值 c c 3根號c 公式 1 中，c是平均的併發使用者數 n是login sessio...
效能測試中TPS和併發使用者數
在做效能測試的時候，很多人都用併發使用者數來衡量系統的效能，覺得系統能支撐的併發使用者數越多，系統的效能就越好 對tps不是非常理解，也根本不知道它們之間的關係，因此非常有必要進行解釋。tps transaction per second,每秒事務數,是衡量系統效能的乙個非常重要的指標，簡單例子 在...