一、背景原因
我們在性能測試工作中，有時需要對業務系統所能支持的最大在線用戶數目進行評估。
和平時的性能測試有區別的是，用戶在線時只是與服務器保持連接，並不一定對服務器有業務請求，從而對服務器不一定會產生壓力。
但是因為在線用戶數目並非可以無限增長，當在線用戶數目達到應用服務器（或者WebLogic等中間件，或者數據庫連接池等）的連接數設置的極限時，業務系統同樣可能會發生異常，出現新用戶無法登錄，或者老用戶被擠出系統，甚至業務系統宕機的情況。
因此，對業務系統的最大在線用戶數指標進行測試是極其必要的。
現有一OA系統，需要測試其支持的最大在線用戶數目。已知當使用瀏覽器登錄該系統后，登錄用戶可持續地保持登錄狀態，即使長時間不做任何操作也不會自動退出系統；通過該OA系統的在線用戶數統計模塊可以詳細地查看到當前在線的用戶。
二、測試思路
測試被測系統所能支持的最大在線用戶數，需要不斷地使用新用戶帳號進行登錄操作，在此同時查看被測系統的在線用戶數目以及系統的響應情況。
在新增登錄用戶時需要注意，由於考察的是系統在正常情況下所能支持的在線用戶數目，而不是系統在並發壓力下的性能響應情況，因此登錄用戶時最好采用單個用戶或少量並發用戶（如兩個或三個）逐步登錄的形式，不同登錄批次之間最好能有一定時間間隔，務必使新增登錄用戶的操作對服務器產生盡可能小的業務壓力。
在新增登錄用戶的過程中，需要對被測系統的在線用戶數目進行查看，並着重關注以下幾個方面：
- 持續新增登錄用戶的同時，業務系統中的在線用戶數目是否相應地進行增長
- 持續新增登錄用戶的過程中，系統登錄操作是否產生連接超時的情況，事務的響應時間是否出現大幅度上升的情況，系統登錄事務是否出現失敗的情況（這需要在腳本中對登錄事務做檢查點設置）
- 持續新增登錄用戶的過程中，定期地在瀏覽器中手動刷新業務系統界面，查看業務系統是否出現不可訪問的情況（如內部服務器錯誤、宕機等）
需要注意的是：使用測試工具測試時，並不能像瀏覽器一樣定期地與服務器進行通訊交互。我們需要用腳本模擬瀏覽器的定期交互行為。
三、測試結果分析
通過以上方法可以測試得到業務系統所能承受的“初略的”最大在線用戶數目。為什么說是“初略的”呢？因為該方法仍存在缺陷，主要體現在如下兩個方面：
- 該方法只適用於測試期間無他人使用系統的情況。如果測試期間同時有其他用戶登錄系統，或者系統中本身已存在在線用戶，則會造成測試得到的結果不准確。
- 該方法忽略了系統穩定性對在線用戶數的影響。舉例來說，也許逐步增加在線用戶數至500時，系統並沒有發生異常，但這並不意味着500個用戶長時間處於在線狀態時系統不會出現異常。
針對以上兩方面缺陷，可以做出如下改進：
- 在逐步增加在線用戶數的時候，定期（比如間隔3秒）查看業務系統自身統計的在線用戶數目，並以該數據為測試結果。
- 利用之前的方法測試得到業務系統“初略的”最大在線用戶數后，使系統長時間保持該數量的在線用戶數目，觀察系統在長時間運行期間是否會出現異常；若出現異常后，適當減少在線用戶數目后重復地進行測試，直到系統可以保持長時間地穩定運行為止，此時對應的在線用戶數目即為業務系統所能承受的最大在線用戶數目。
轉載自：http://8rr.co/Mz4c