項目的情況簡介：
項目屬于客戶端/服務端模式產品，要求每個服務端能支持連接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、“下次客戶端機器啟動時，會自己連接服務端。”這個連接，是指自動登錄還是會同步數據或者僅是網絡連接？
所以，對于本案編者只能按照性能測試的一般做法做一個介紹，不能詳細的分析本案為什么會出現了不穩定運行的狀況了，希望能對本案作者及遇到相同問題，或者準備做性能測試的同行們有所啟發。
首先，我們為什么做性能測試呢？
性能測試的目的：
一、評估系統的能力，測試中得到的負荷和響應時間數據可以被用于驗證所計劃的模型的數據處理能力，并幫助作出決策。
二、識別體系中的弱點：受控的負荷可以被增加到一個極端的水平，并突破它，從而修復體系的瓶頸或薄弱的地方。
三、系統調優：重復運行測試，驗證調整系統的活動得到了預期的結果，從而改進性能。檢測軟件中的問題：長時間的測試執行可導致程序發生由于內存泄露引起的失敗，揭示程序中的隱含的問題或沖突。
四、驗證穩定性（resilience）可靠性（reliability）：在一個生產負荷下執行測試一定的時間是評估系統穩定性和可靠性是否滿足要求的唯一方法。
性能測試類型包括：
負載測試：負載測試是一種性能測試指數據在超負荷環境中運行，程序是否能夠承擔。
強度測試： 強度測試是一種性能測試，他在系統資源特別低的情況下軟件系統運行情況。
容量測試：確定系統可處理同時在線的最大用戶數
性能測試觀察指標：
性能測試主要是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬于性能測試，兩者可以結合進行。通過負載測試，確定在各種工作負載下系統的性能，目標是測試當負載逐漸增加時，系統各項性能指標的變化情況。壓力測試是通過確定一個系統的瓶頸或者不能接收的性能點，來獲得系統能提供的最大服務級別的測試。
在實際中作中我們經常會對兩種類型軟件進行測試：bs和cs，這兩方面的性能指標一般需要哪些內容呢？Bs結構程序一般會關注的通用指標如下（簡）：
Web服務器指標指標：
1、Avg Rps： 平均每秒鐘響應次數＝總請求時間 / 秒數；
2、Avg time to last byte per terstion （mstes）：平均每秒業務角本的迭代次數 ，有人會把這兩者混淆；
3、Successful Rounds：成功的請求；
4、Failed Rounds：失敗的請求；
5、Successful Hits：成功的點擊次數；
6、Failed Hits：失敗的點擊次數；
7、Hits Per Second：每秒點擊次數；
8、Successful Hits Per Second：每秒成功的點擊次數；
9、Failed Hits Per Second：每秒失敗的點擊次數；
10、Attempted Connections：嘗試鏈接數；
11、CS結構程序，由于一般軟件后臺通常為數據庫，所以我們更注重數據庫的測試指標：
12、User 0 Connections：用戶連接數，也就是數據庫的連接數量；
13、Number of deadlocks：數據庫死鎖；
14、Butter Cache hit：數據庫Cache的命中情況
當然，在實際中我們還會察看多用戶測試情況下的內存，CPU，系統資源調用情況。這些指標其實是引申出來性能測試中的一種：競爭測試。什么是競爭測試，軟件競爭使用各種資源（數據紀錄，內存等），看他與其他相關系統對資源的爭奪能力。性能測試的流程步驟和做其他的測試沒有什么區別，做性能測試也要如下步驟來做：
1、測試需求分析
2、測試設計
3、測試腳本開發
4、測試實施
5、測試結果分析
測試需求分析，性能測試（或者其他的測試）做的好與壞完全取決于測試分析做得好不好。軟件最終始要被應用的，要在應用的實踐中考驗，所以，任何類型的測試分析都要以實際業務的要求為依據。那么，性能測試的測試需求分析都需要分析哪些內容呢？
1、性能測試的需求來源。客戶需求和期望，實際業務需求，系統需求。
2、業務數據量級，要根據實際業務分析可能出現數據吞吐瓶頸的地方，比如本案中作者提到的要求每個服務端連接500個客戶端，總要求連接5000個客戶端。分析到這個程度還不夠，還要進一步分析業務操作集中的點，時間段和量。如，本案中客戶端開啟會自動連接服務端，那么在每天開始上班的時候客戶端的開啟就會出現峰值，可能會持續20分鐘，服務端需要響應客戶端的連接請求，請求還可能并發至少 5000/120次每秒，同時短時間內集中請求的頻率也是有閾值限制的。
3、系統架構，在每種不同的系統架構的實施中，開發人員可能選擇不同的實現方式，造成實際情況紛繁復雜。我們不可能對每種技術都詳細解說，這里只是介紹一種方法提供給你如何選擇測試策略，從而幫助分析軟件不同部分的性能指標，進而分析出整體架構的性能指標和性能瓶頸。
4、測試策略和評估標準，任何測試的目的都是確保軟件符合預先規定的目標和要求。性能測試也不例外。所以必須制定一套標準。通常性能測試有四種模型技術可用于評估：
* 線性投射：用大量的過去的，擴展的或者將來可能發生的數據組成散布圖，利用這個圖表不斷和系統的當前狀況對比。
* 分析模型：用排隊論公式和算法預測響應時間，利用描述工作量的數據和系統本質關聯起來
* 模仿：模仿實際用戶的使用方法測試你的系統
* 基準：定義測試和你最初的測試作為標準，利用它和所有后來進行的測試結果進行對比
測試設計，測試設計是在了解軟件業務流程的基礎上。設計測試用例的原則是受最小的影響提供最多的測試信息，設計測試用例的目標是一次盡可能的包含多個測試要素。這些測試用例必須是測試工具可以實現的，不同的測試場景將測試不同的功能。因為性能測試不同于平時的測試用例，盡可能把性能測試用例設計的復雜，才有可能發現軟件的性能瓶頸。
測試腳本開發，性能測試是通過工具，模擬大量用戶操作，對系統增加負載。所以需要掌握一定的工具知識才能進行性能測試。大家都知道性能測試工具一般通過winsock，http等協議紀錄用戶操作。而協議選擇是基于軟件的系統架構實現（web一般選擇http協議，cs選擇winsock協議），不同的性能測試工具，腳本語言也不同，比如rational robot中vu腳本用類c語言實現。
開展性能測試需要對各種性能測試工具進行評估，因為每一種性能測試工具都有自身的特點，只有經過工具評估，才能選擇符合現有軟件架構的性能測試工具。
測試結果分析，運行測試用例后，收集相關信息，進行數據統計分析，找到性能瓶頸。通過排除誤差和其他因素，讓測試結果體現接近真實情況。不同的體系結構分析測試結果的方法也不同，bs結構我們會分析網絡帶寬，流量對用戶操作響應的影響，而cs結構我們可能更關心會系統整體配置對用戶操作的影響。