1、精選優質文檔-傾情為你奉上網吧系統壓力測試方案文檔修改歷史日期版本作者修改內容審批人發布日期2014.10.13V1.0初稿2015.01.20V2.0專心-專注-專業目 錄1. 文檔介紹1.1.測試目的本次壓力測試的目的是檢測網吧系統的核心業務的性能情況。為了保證后期在業務量不斷增長的情況下系統后能夠穩定運行，需要對核心業務場景的壓力情況有充分了解。因此，希望在模擬生產環境的情況下，模擬用戶并發數，對系統核心業務進行壓力測試，收集相應的系統參數，并最終作為系統穩定運行的依據，同時為系統調優提供指導。編寫本方案的目的是指導本次性能測試有序的進行，相關人員了解本次壓力測試。1.2.讀者對象 本方

2、案的預期讀者是：項目負責人、測試人員和其他相關人員。1.3.參考資料名稱是否可用備注1.4.術語與解釋 系統用戶數：使用該系統的總用戶數； 同時在線用戶數：在一定的時間范圍內，最大的同時在線用戶數；2. 測試環境模擬客戶使用環境（最好模擬客戶實際使用的配置環境）。具體如下：2.1. 測試環境 被測系統環境需要和線上環境一致網絡環境：Lan（100M）硬件環境： 應用服務器數量：1臺配置：型號、CPU、內存等 數據庫服務器數量：1臺配置：型號、CPU、內存等 測試客戶端數量：3臺配置：型號、CPU、內存等軟件環境： 操作系統：Ubuntu 12，Windows 7，Windows XP 應用服務

3、軟件：Tomcat 6.037 數據庫：MySQL 5.52.2. 測試工具LoadRunner 11使用HTTP/HTTPS協議。主要思想是使用虛擬用戶（Virtual users）來模擬實際用戶對系統施加壓力。模擬圖如下：3. 測試需求3.1. 測試功能點本次測試涉及到的模塊為： 登錄功能 在線商品充值 訂單查詢3.2. 性能需求1) 登錄系統平均響應時間小于等于5秒鐘；2) 在線商品充值處理時間要小于等于2秒；3) 訂單查詢系統響應時間在3個月內在3s之內，超出3個月，可在2-10s之內。4. 準備工作4.1 并發用戶數計算 根據提供的數據，系統用戶數為1600；2014年12月份總訂單

4、數量為筆訂單，12月份高峰日訂單數量為9205筆訂單，另外根據網吧提交次數，一天內一家網吧平均提交28.8筆訂單，那么，在高峰日內：平均每天訪問用戶數量=高峰日內訂單總數量/單個用戶日平均提交的訂單數量 =9205/28.8 320即平均每天訪問用戶數量320個； 平均并發用戶數計算公式C=nL /T其中C是平均并發用戶數，n是平均每天訪問用戶數，L是一天內用戶從登陸到退出的平均時間，T是考察時間長度（一天內多長時間有用戶在使用系統）；對于一個典型用戶來說，一天之內用戶從登陸到退出系統的平均時間為4小時，在一天內，用戶在8小時內使用該系統；那么平均并發用戶數C= nL /T=320*4 /8=

5、160 并發用戶數峰值：C1C+3*根號C=160+3*根號160=200（注：公式遵循泊松分布理論） 由此可以計算出當網吧用戶數量達到16000家時對應的平均并發用戶數和并發用戶數峰值，如下圖所示： 系統名稱系統用戶數平均并發用戶數并發用戶數峰值系統a1600個160個200個系統b16000個1600個2000個 （注：根據2012年淘寶報告顯示，淘寶注冊用戶數為3.7億，最高峰時同時在線用戶數為6000萬，按照這個規律計算，網吧系統達到16000個用戶時，最高峰同時在線用戶數為2500+） 4.2 業務分配在線用戶登錄后，網吧業務包括：游戲充值、查詢記錄、賬戶管理、資金管理，根據業務分配

6、，游戲充值業務占總業務的60%，查詢記錄占30%，賬戶管理占用5%，資金管理占用5%，詳見下圖： 業務名稱游戲充值查詢記錄賬戶管理資金管理業務占比60%30%5%5%并發用戶數峰值1200個600個100個100個4.3 腳本和環境1) 對登錄功能、充值、查詢功能進行功能測試，且功能測試全部通過；2) 測試環境服務器：開發搭建并保持和線上環境一致；3) 測試客戶機：既定的三臺客戶機，內網IP為23 和84，35，超出三臺機器的需要，會另增測試客戶機；4) 對于登錄功能、充值和查詢功能，事先錄制好相應的測試腳本，包括參數化、關聯等

7、，準備好測試數據，并且調試好，腳本能夠成功的回放，保證在測試的時候能夠順利的運行；5) 創建測試場景，并配置好每個場景的設置；6) 測試過程中保存好腳本和分析結果，并規范的對腳本和分析結果等進行命名。5. 測試完成準則系統響應時間判斷原則如下：1) 系統業務響應時間小于2秒，判為優秀，用戶對系統感覺很好；2) 系統業務響應時間在2-5秒之間，判為良好，用戶對系統感覺一般；3) 系統業務響應時間超過10秒，判斷為一般，用戶體驗不佳。4) 在長時間運行后，系統不崩潰，各功能正常；服務器CPU，內存，響應時間等參數保持穩定；場景運行停止后，一段時間內占用的資源可以正常釋放。6. 測試風險1) 選擇的

8、業務流不具有代表性。即選擇的測試功能點經過負荷測試和長時間測試后不能重現系統問題，如內存溢出，速度慢等問題；選擇測試功能點的原則：客戶使用系統時經常操作的業務流，以及覺得反應比較慢的幾個功能模塊；2) 不是在實際環境中的測試（即模擬的測試環境和客戶實際使用環境配置差別較大），由于測試環境的不同，測試結果和實際使用環境中的結果有一定的出入；3) 測試環境中的數據量比實際環境中使用一段時間后的數據量要少的多，系統目前的性能不能代表數據量增長后的性能。7. 測試設計策略7.1. 組合測試用例策略先按照單個場景進行并發測試，在組合多個場景進行長時間測試，即：先單獨執行登錄功能測試，再組合登錄、充值、查

9、詢，同時并發執行4個小時。7.2. 測試執行策略在正常的生產數據下，采用階梯式的方式，分別使用并發用戶1、10、50、100、200等進行測試。每次增加虛擬用戶數時，查看系統的性能參數變化，如果變化很大，可以加大虛擬用戶的數量；另外，如果在某一個并發用戶數，如100個并發用戶測試時，發現性能下降，那么則逐步減少并發數，以找出并發用戶達到什么數目時，系統性能開始急劇下降。8. 業務模型8.1 場景啟用模式1） 首頁登錄功能：逐步加壓模式2） 在線游戲充值功能：逐步加壓模式3） 訂單查詢功能：逐步加壓模式8.2 測試目標 測試功能最大并發數響應時間事務通過率CPU使用率內存使用率錯誤率登錄2000

10、95%70%70%5%訂單查詢600（3個月以下）95%70%70%95%70%70%5%游戲充值120095%70%70%5%8.3 場景設計1）登錄功能測試目的：驗證網吧系統用戶登錄在逐漸增加虛擬用戶數量的情況下，系統響應時間如何變化以及系統響應時間分別是多少前置條件：注冊并激活網吧系統用戶賬號；方法：逐漸增加用戶個數進行登錄，獲取平均響應時間和吞吐量序號功能并發用戶數迭代次數操作間隔1登錄功能5132登錄功能10133登錄功能50134登錄功能100135登錄功能150136登錄功能200137登錄功能500138登錄功能.132）游戲充值測試目的：逐漸增加虛擬用戶數量，獲取游戲充值的平

11、均響應時間以及逐漸增加負載的過程系統響應時間的變化，在用戶數量達到峰值為多少時，系統的性能開始下降；前置條件：已注冊好的網吧系統賬號，已選擇好的游戲充值商品；方法：逐漸增加用戶數量進行游戲充值，獲取游戲充值的平均響應時間； 序號功能并發用戶數迭代次數操作間隔1在線游戲充值1132在線游戲充值10133在線游戲充值50134在線游戲充值100135在線游戲充值150136在線游戲充值200137在線游戲充值500138在線游戲充值.139在線游戲充值1200133）訂單查詢測試目的：逐漸增加負載過程中，錢包支付充值的響應時間，在用戶數量達到多少時，系統的性能開始下降； 前置條件：已注冊的網吧系統賬號、賬號中有足夠的金額進行充值，已準備好的充值商品；方法：逐漸增加用戶個數，獲取錢包充值的平均響應時間；序號功能并發用戶數時間跨度迭代次數操作間隔1訂單查詢51個月 /3個月 /1年132訂單查詢101個月 /3個月 /1年133訂單查詢501個月 /3個月 /1年134訂單查詢1001個月 /3個月 /1年13