1、分析系統並發數的列子
假定每天從該站乘坐地鐵的人數為5萬人次，每天的早高峰為7-9點，晚高峰為6-7點，根據8/2原則，80%的乘客（人次）會在高峰期乘坐該站的地鐵，則平均每秒到達地鐵檢票口的人數為（50000×80%）/（3×60×60） = 3.7～=4人，當然這個4人不能作為計算所用的並發值，因為對此時的受壓入口檢票口來說，4只是每秒到達的壓力（即請求）數量，考慮到安檢、入口關閉等因素，實際堆積在檢票口的人數可能要大於這個數目，假定每個人需要3秒左右才能入站，則實際並發應該為（4人/秒）×3秒=12。當然我們必須指出，這種方法得到的情況並非極端值，因為即使作為早晚高峰，人數的分布也不是平均的（具體情況需要根據實際數據進行分析），但對大部分系統的大部分場景，我們可以用（用戶總量/統計時間）×影響因子（一般為3，為經驗系數）來進行估算。
2、注意：1、為了上傳文件，必須設置Use multipart/form-data for POST，否則request將不包含上傳的文件。
3、另外，必選添加文件的參數名稱，否則在Server段用Servlet進行解析時，無法獲得文件。
如：
將待上傳文件路徑參數化，即將待上傳文件路徑保存到一個.csv文件或.dat文件里面
在“同請求一起發送文件”參數化待上傳文件。參數名稱寫當前頁面請求的實際參數名稱，不清楚可以到Badboy錄制腳本時查看。MIME類型寫實際錄制腳本上傳文件的類型,這里是application/vnd.ms-excel，更多參考百度。注意：參數化的文件路徑和文件名稱不用中文用英文，以防出現亂碼，讀取不到文件。
4、錯誤：圖上的方式，每次運行只能調用到一次文件，錄制腳本也是一個參數fileField，所以圖上參數方式是錯誤的，所以要將上傳文件參數化，即將待上傳文件進行路徑參數化。
正確：上傳文件實例：路徑參數化，把你要上傳的文件的路徑寫在這個csv文件里面或.dat文件，像數據參數化一樣，只是這里的文件內容是待上傳文件路徑參數，而其他地方寫的是要上傳數據的字段，如DDS中創建賬戶的參數化方式。
5、然后如果你是一個thread，上傳的request是放在loop controller下的，你把loop count寫成你要上傳的次數，那么結果是它會多次上傳，但是每次都只上傳第一個文件。
如果改成這樣就可以：
要上傳3個文件，那就把thread，改成並發為3，那第一個thread會上傳第一個，第二個thread上傳第二個文件，第三個thread會上傳第三個
6、把你要上傳的文件的路徑寫在這個csv文件里面或dat文件都可以
7、如果感覺發現腳本設置無錯，錄制無錯，但是就是沒成功，嘗試檢查是否哪里寫錯參數文件名或少寫了什么括號}，是否參數名稱錯誤等，檢查腳本正確的參數名稱可以通過Badboy檢查
那個參數名稱就寫實際的從參數名稱，這里叫filename
Get方法對服務器沒什么壓力，不用測試並發
系統用戶數與同時在線人數
在實際的性能測試中，經常接觸到與並發用戶相關的概念還有“系統用戶數”與“同時在線人數”下面通過一個實例來描述他們之間的差別。
假設有一個網站，注冊用戶才能登錄使用各種功能，如上傳頭像，閱讀專家文章等。該系統有20萬注冊用戶，這就是說有20萬用戶可以使用這個網站的所有功能，20萬就是這個網站的“系統用戶數”，網站有一個在線統計功能，從統計數據中可以看到，同時登錄網站的人數的最高記錄是2萬，就是有2萬人同時用瀏覽器打開着這個網站。2萬就是“同時在線人數”。
那么系統的並發用戶數是多少呢?2萬么？NO!這2萬只表示在系統最高峰時有這么多用戶登錄了網站，並不表示實際服務器的承受壓力。因為服務器承受壓力還與具體的用戶訪問模式相關，在這2萬用戶中考察某一個時間點對用戶發出請求數，可以會大大縮水。那么，該系統的服務端承受的最大並發訪問數是多少呢？這個取決於業務並發用戶數和業務場景，一般可以通過服務器日志的分析得到。
求並發用戶數公式
在實際的性能測試工作中，測試人員一般比較關心的是業務並發用戶數，也就是從業務的角度關注應該設置多少個並發數比較合理。
下面找一個典型的上班簽到系統，早上8點上班，7點半到8點的30分鍾的時間里用戶會登錄簽到系統進行簽到。公司員工為1000人，平均每個員上登錄簽到系統的時長為5分鍾。可以用下面的方法計算。
C=1000/30*5=166.7
C表示平均並發用戶數，那么對這個簽到系統每分鍾的平均在線用戶數為166
當然，在性能測試上，任何公式都不是嚴謹的，最重要的是對系統做出有效正確的分析。