來源：51Testing軟件測試網(wǎng)
那么我們?nèi)绾蝸砉浪氵@個并發(fā)值呢？
在此我們需要作出說明，一般我們需要的數(shù)據(jù)應該來自于實際數(shù)據(jù)（比如系統(tǒng)日志的記錄），這樣更可靠，只有當系統(tǒng)新啟動且無任何數(shù)據(jù)參考的時候我們才需要進行估算。
比如我們測試地鐵大廳的性能情況，該如何去估算當乘客進入大廳時，地鐵大廳的性能呢？下面以筆者經(jīng)常乘坐的地鐵5號線立水橋南站為例進行估算，過程與數(shù)據(jù)僅供參考。
假定每天從該站乘坐地鐵的人數(shù)為5萬人次，每天的早高峰為7-9點，晚高峰為6-7點，根據(jù)8/2原則，80%的乘客（人次）會在高峰期乘坐該站的地鐵，則平均每秒到達地鐵檢票口的人數(shù)為（50000×80%）/（3×60×60） = 3.7～=4人，當然這個4人不能作為計算所用的并發(fā)值，因為對此時的受壓入口檢票口來說，4只是每秒到達的壓力（即請求）數(shù)量，考慮到安檢、入口關閉等因素，實際堆積在檢票口的人數(shù)可能要大于這個數(shù)目，假定每個人需要3秒左右才能入站，則實際并發(fā)應該為（4人/秒）×3秒=12。當然我們必須指出，這種方法得到的情況并非極端值，因為即使作為早晚高峰，人數(shù)的分布也不是平均的（具體情況需要根據(jù)實際數(shù)據(jù)進行分析），但對大部分系統(tǒng)的大部分場景，我們可以用（用戶總量/統(tǒng)計時間）×影響因子（一般為3，為經(jīng)驗系數(shù)）來進行估算。
實際上，還有一種估算方法，而這種估算方法為國內(nèi)眾多書籍、文章反復轉(zhuǎn)載，其來源與Eric Man Wong在2004年公布的一篇“論文”《Method for Estimating the Number of Concurrent Users》，其核心公式如下：
C=nL/T
其中，C代表在線用戶，n代表執(zhí)行事務的用戶總數(shù)，L代表每用戶的平均在線時間，T為待統(tǒng)計的總時間，依舊以地鐵入站的情況進行估算，依舊考慮8/2原則，即n為50000*80%人，T為3小時，L即我們在地鐵中停留的時間（從進站到上車），假定為5分鐘，因此得到的公式為：
C=（50000人×80%×5min）/3×60min = 1111
并發(fā)數(shù)是1111，比前面一種算法要高的多，這是為什么呢？
實際上，后面這種統(tǒng)計方法是由一定的局限性與適用范圍的，對其統(tǒng)計的每個并發(fā)用戶而言，每個用戶所在線的時間（如上面的5min），并不一定是我們所需要的場景耗時，該5分鐘應該是整個大場景（如從進站到離開），而我們通常所使用的場景往往包含了一連貫的子場景，如進站、等待、上車等，因此，如果我們測試的場景是某一個具體的動作，不建議采用這種公式（當然，如果單獨為每個動作估算時間也是可以的。）
從本質(zhì)上來說，兩種公式的統(tǒng)計，結(jié)果都是一樣的，關鍵取決與統(tǒng)計口徑。
極限的問題也是我們需要考慮的，數(shù)據(jù)的估算往往是一個大的工程，涉及到很多復雜的情況，比如用戶的進入與離開，人流異常等，因此我們考慮的多為常規(guī)的情況，在一些特殊的情況下，用戶的峰值往往要大很多，此時需要去對極限情況下進行估算。
此時的目的在于檢查系統(tǒng)的極限承載情況，如列車極限大承載2000人，站內(nèi)極限承載10000人是一樣的，超出這個極限，就需要采取一些緊急措施，比如限流（對應到普通的系統(tǒng)，就是設置特大連接數(shù)，超出的必須等待）之類。
這種值的計算，不可能給出準確值，可以根據(jù)實際情況，協(xié)商而定，比如把經(jīng)驗系數(shù)更改為5，這種情況下，如果有日志或者統(tǒng)計數(shù)據(jù)予以支撐，會更加精確。
● 回答客戶的疑惑
面對客戶，經(jīng)常需要去解答一些問題，常見的幾類疑惑如下：
1、客戶堅持要求并發(fā)2000，怎么辦？
這個問題非常關鍵，即上面所謂的闡述只是為了讓大家對并發(fā)等概念有個大體的理解，但我們的工作重心不是一來就跟客戶講理論，而是合理、有效、迅速地完成項目，因此，特別是一些項目的咨詢階段，如果客戶堅持提出達到某個并發(fā)要求，我們首先需要看下這個情況產(chǎn)品能否支持，如果不支持，用修改架構（比如增加服務器，公司的大部分產(chǎn)品都支持集群）來完成，如果還是沒法達到要求，我們再來跟客戶交流，從客戶能理解的方式，從客戶的角度去計算并發(fā)，然后得到認可就行了。當然，解決這些問題，需要我們對公司的產(chǎn)品性能基本比較了解（可以經(jīng)過產(chǎn)品的性能測試報告來了解，質(zhì)保將來會考慮出臺所有產(chǎn)品的性能指標集合供參考），如果難度還是很大，可以申請質(zhì)保的支持。大家一起去解決這個問題。
2、你們的系統(tǒng)能支持10000并發(fā)嗎？
一些客戶經(jīng)常提出非常高的并發(fā)要求，此類客戶通常對性能并不了解，或者之前有客戶對其做了錯誤的解釋，此時我們需要解釋我們測試并發(fā)的概念：同時向服務器發(fā)出請求的虛擬用戶數(shù)。（而我們通常會采用嚴格的方法進行場景測試：即采用集合點的方式進行操作。這種方式也即前面介紹的狹義并發(fā)的概念。）
另外，并發(fā)值需要考慮實際情況，需要根據(jù)實際的需求進行計算，與此同時，并發(fā)的影響因素并非僅僅是軟件本身，還有網(wǎng)絡、架構等等，TRS的產(chǎn)品性能測試往往給出單位機器的性能，用戶可以根據(jù)這個基礎值來構造實際架構。
3、你們的系統(tǒng)怎么才支持200并發(fā)？
并發(fā)的概念在于同時在處理某一件事情，而且系統(tǒng)一直保持這樣的一個強度，并不是說總共只有200人，另外，我們測試的一般是單機，也就是說，如果更好的性能要求，可以用集群的方式來獲得更優(yōu)的結(jié)果，目前TRS的產(chǎn)品基本都支持集群的部署架構。需要注意的是，并發(fā)的支持除了軟件本身，還受到網(wǎng)絡、服務器性能等多方面原因的影響。
4、是否可以使用每秒處理事務來衡量。
性能測試的衡量指標除了響應時間，還有吞吐量、每秒點擊數(shù)、每秒PV、每秒事務處理能力等，因此我們可以用多種方式進行衡量，在更大意義上，各個指標間也存在一定的內(nèi)涵聯(lián)系，結(jié)合起來考慮更能夠檢查系統(tǒng)的性能。但受制于一些客觀原因（如定制），在之前的報告中，指標衡量存在一定的限制。
5、響應時間與并發(fā)、壓力是什么關系？這么操作的響應怎么才6秒，太慢了，你們的產(chǎn)品性能不行??！
一般的，一定的并發(fā)下將對系統(tǒng)造成一定的壓力，而對每個并發(fā)（用戶）而言，所體現(xiàn)出來的性能多是直觀的響應時間，在環(huán)境一定的情況下，響應時間越快說明系統(tǒng)性能越好。但此處需要清除一個問題，假定一個用戶獲取的響應時間是5秒，這5秒都在對系統(tǒng)產(chǎn)生壓力嗎？
后面這個是一個有趣而有意義的問題，我們知道這個響應時間是從用戶發(fā)出請求到接收到響應的為止的總耗時，如果我們使用httpwatch之類的工具，可以很清晰的看到時間消耗的分布區(qū)間，我們可以把這個問題比作是向墻壁擊出一個球，從擊出到彈回來的時間即為響應時間。
大家打過壁球嗎？打壁球的過程其實就完美的詮釋了用戶發(fā)起請求到接受響應整個過程，可以我們可以把墻壁看作系統(tǒng)，打球者就是用戶，球是用戶發(fā)出的請求，擊打一次球包含有三個動作：擊出球、球接觸墻壁、收到彈回的球。三個過程加起來的總時間就是這個請求（打出一發(fā)球）所得到的響應，但很顯然，真正對系統(tǒng)產(chǎn)生壓力的動作在于接觸墻壁的時間，大部分的時間消耗在空中，即球在空中飛行時的時間，而這個飛行時間并不受系統(tǒng)控制，對應到常規(guī)系統(tǒng)，就很可能是網(wǎng)絡在傳輸過程中出現(xiàn)了問題。
這個壁球的例子實際上還可以解釋一些相關的概念，比如并發(fā)就是同時擊出多個球，系統(tǒng)（墻壁）所能承受的極限并發(fā)壓力就是墻壁的面積所能容納的壁球數(shù)量，假定墻壁面積可以容納1000個球，則墻壁瞬間可以接觸的球的數(shù)量就是1000個，這個就是狹義并發(fā)的概念了，考慮到空中飛行，即將觸碰墻壁的球，理論上的廣義并發(fā)值要高于1000。擊球時的力度可以理解為客戶端的性能，性能好發(fā)球就快，否則就慢，只要系統(tǒng)性能沒有達到瓶頸（比如墻壁沒有壞），系統(tǒng)的性能是跟客戶端呈正比的，即擊球速度越快，返回越快。
因此，當遇到客戶對響應時間有疑問時，我們需要解釋的重點在于，壓力在于球接觸墻壁的瞬間，但性能測試考核的響應時間確實包含了兩次飛行（發(fā)送與接受）的時間，而這個時間是受包含服務器性能、網(wǎng)絡性能、客戶端性能在內(nèi)的多因素影響的，相信客戶可以理解。
● 簡單的結(jié)論
如果您覺得上面說的東西過于繁瑣，以下基本概念可能更適合閱讀。
1、并發(fā)分為狹義并發(fā)與廣義并發(fā)兩種，狹義并發(fā)指同一時間點開始做某件事情，廣義并發(fā)指同一時間段正在做某件事情；
2、并發(fā)與被考察的場景是息息相關的，測試中所指的并發(fā)一般指同一時間段在做某件事情（被測事務）的用戶數(shù)，在嚴格測試的環(huán)境下，我們會要求所有用戶在同一時間點集合并執(zhí)行；
3、在線用戶與并發(fā)用戶不是一個概念，在線用戶包含了很多非測試事務用戶、空閑的客戶等，因此不能把在線的用戶全計作并發(fā)用戶，一般的并發(fā)用戶占在線用戶總量在10%～20%左右，當然，這個值僅供參考，實際問題需要實際分析。
4、理論上說并發(fā)越大性能越好，但其取決與很多因素，比如網(wǎng)絡、服務器數(shù)量、服務器性能、系統(tǒng)架構、軟硬件優(yōu)化等，另外，并發(fā)的計算需要在需求階段根據(jù)實際情況進行估算，這樣得到的結(jié)果才是合理的。
5、幾個概念的再次說明：
→ 并發(fā)用戶數(shù)：同時在操作被考察事務的用戶數(shù)
→ 在線用戶數(shù)：當前被測系統(tǒng)中的活動用戶數(shù)（包括考察事務與非考察事務）
→ 平均響應時間：每個用戶操作事務獲得的平均響應時間（算術平均值）
→ 90%響應時間：90%用戶平均響應時間在此值范圍內(nèi)（取除去10%極高值后的極限值）
→ 平均事務數(shù)：單位時間完成的事務數(shù)（如登錄、首頁讀取等）
→ 平均吞吐量：單位時間內(nèi)的數(shù)據(jù)傳輸量
→ 平均點擊數(shù)：單位時間完成的請求數(shù)量
→ PV：某時間段內(nèi)完成的頁面請求數(shù)量
詳詢：王萍老師18988787201
詳詢：小文老師18988787201
|
|
| 王萍老師 | 小文老師 |
《中華考試網(wǎng)軟件測試培訓》
《教育軟件測試培訓頻道》
《軟件測試培訓課程——深圳川石》
《深圳川石軟件性能測試培訓》
《深圳川石企業(yè)性能測試(PL&LR)提升班》
《持續(xù)集成自動化測試UFT Selenium提升班》
《深圳源昊寶安軟件測試培訓班》
《深圳凌岳軟件自動化測試培訓班》
《深圳博睿軟件安全測試培訓》
《深圳達內(nèi)軟件測試培訓學校》
