產品性能測試

　　項目的情況簡介：

　　項目屬于客戶端/服務端模式產品，要求每個服務端能支持連接500個客戶端

　　測試環境簡介：

　　服務端支持三級連接模式，每個服務端能支持連接500個客戶端，總要求支持大約5000個客戶端。

　　測試的過程描述：

　　在測試實驗室中，只能搭建10個客戶端的環境以及三級連接的環境。服務端初次連接客戶端后，客戶端會保留服務端的IP地址。下次客戶端機器啟動時，會自己連接服務端。每次連接屬于短連接。在產生事件時，客戶端會自己上報給服務端。

　　測試過程遇到的問題：

　　在實驗室中測試系統穩定可用，但在用戶那里遇到服務端異常退出。

　　問題分析：

　　客戶端同時大量上報事件時，服務端處理出問題，導致系統異常退出。

　　希望尋求的幫助：

　　如何模擬多客戶端問題?如何進行產品的性能測試?如何保證產品的穩定性?

　　相關分析

　　分析一：

　　分析內容：

　　很簡單，這種情況，用loadrunner最合適了，用loadrunner這種壓力測試工具，模擬多用戶環境，不知道你們是用什么語言開發，如果是 java的甚至可以利用loadrunner的Tunning組件，達到代碼級的調優。如果是C#.net,那很要等啦，Mercury同意支持 C#.net，但支持版本還沒有出來。我在給你個建議，找個系統整合專家，看看是不是他們的網絡有問題，或者是服務器沒有調試好。有時候，機子CPU多，沒有調試好，可能大量的CPU資源用于頻繁的調度，而造成系統異常。有時候，還要改進算法。這種系統調試最麻煩了!

　　分析二：

　　分析內容：

　　個人意見：對這個問題的分析應該考慮兩個層次：

　　1、解決現有問題的層次;

　　2、探討測試不充分問題產生的根源并從根源上避免此類問題的發生。

　　這個問題本身是比較好解決的，在現場出現問題后，我們要做的是利用實驗室的環境(或者現場的環境)確定問題產生的原因，從例子的描述來看，應該是在客戶端大量建立連接時服務端無法支持，產生異常退出。對該問題的定位可以用LR等性能測試工具(或是自己編寫的工具)模擬進行大并發量的突發連接測試，并據此給出改進的方法。

　　其次我們還應該探討測試不充分問題產生的根源。在這個例子中，由于設備不足夠，可能根本就沒有進行壓力和負載測試，這本身就留下了隱患。其次，作為測試負責人，對這種項目的經驗不足，一般來說，基于短連接方式的C/S結構應用最大的可能出問題的地方就是大量用戶同時進行連接操作，即使沒有環境在實驗室中進行測試，也必須把這個作為一個大的項目風險列出，要求在交付最終用戶使用前進行這類測試。

　　主要分析

　　本案中，作者的描述有些歧義：

　　1、“三級連接模式”，不知道是不是有服務器，有端站，有客戶端的模式，還是采用了服務器集群，多臺服務器分三級級連。

　　2、“每個服務端能支持連接500個客戶端，總要求支持大約5000個客戶端。”

　　3、“服務端初次連接客戶端，”這個不知道是不是應該是“客戶端初次連接服務端”，而書寫的當時，思維太快了，手沒跟上，請教開發工程師都說“一般都是客戶端去連接服務端的“拉”模式，而極少服務端向客戶端“推”的模式。”

　　4、“在產生事件時，客戶端會自己上報給服務端”，不知道是不是以發送日志文件的形式上報。

　　5、“在實驗室中測試系統穩定可用”，實驗室中測試是不是只有10個端站的情況下，而并沒有采用任何的測試工具來做模擬端站和用戶，已達到實際需要的量級。

　　6、“下次客戶端機器啟動時，會自己連接服務端。”這個連接，是指自動登錄還是會同步數據或者僅是網絡連接?

　　所以，對于本案編者只能按照性能測試的一般做法做一個介紹，不能詳細的分析本案為什么會出現了不穩定運行的狀況了，希望能對本案作者及遇到相同問題，或者準備做性能測試的同行們有所啟發。

　　首先，我們為什么做性能測試呢?

　　性能測試的目的：

　　一、評估系統的能力，測試中得到的負荷和響應時間數據可以被用于驗證所計劃的模型的數據處理能力，并幫助作出決策。

原文轉自：http://www.uml.org.cn/Test/200904306.asp