這是一個經常被測試人員忽略的環節，在接到測壓任務后，基于種種其它因素的考慮，測試人員往往急于進度，立即投入到具體的測試工作去了，測試、記錄、分析，忙的不亦樂乎，工作進行了一半才發現，或是硬件配置不符合要求，或是網絡環境不理想，甚至軟件版本不對，一時弄得騎虎難下，這都是沒有做好測試準備惹的禍。那么我們應該如何做好性能測試的準備工作呢？ 做軟件項目有需求調查、需要分析，做測試也一樣。在拿到測試任務后，首要的任務就是分析測試任務，在開始測試前，我們至少要弄清以下幾個問題： a) 要測試什么或測試的對象是誰？ b) 要測試什么問題或我們想要弄清楚或是論證的問題？ c) 哪些因素會影響測試結果？ d) 需要怎樣的測試環境？ e) 應該怎樣測試？ 只有在認真調查測試需求和仔細分析測試任務后，才有可能弄清以上一系例的問題，只有對測試任務非常清楚，測試目標極其明確的前提下，才可能制定出切實可行的測試計劃。
調研需求 了解客戶的標準 例如我們做的是一個公司內部的CRM系統 基本上只有銷售和一些上司在用 大概使用人數在120人左右，基本的使用時間在上班時間，并且集中在早上十點左右，通過調研50人集中在10點--11點間訪問crm系統了解客戶信息，并且每個人期間向服務器發送請求數不超過50 這樣我們就可以估算出一些有用的信息 比如登陸并發用戶數 假設他們都在10點2分前登陸了 系統 ， 那么120秒內120人 每秒1個人 哇哇 這還不夠并發，我們再來狠點 讓120個 30秒登陸 那么并發數就4人/秒，具體是并發數多少這就要設計到具體的業務場景了和客戶需求了，客戶說我要做一個購物網站，你給我分析下，好，假設網站有500萬的會員，按照性能測試慣例 并發用戶一般占到該功能使用人數的20%左右 500萬很多嗎 其實不多 有些會員可能只是在瀏覽網頁 并不需要去登陸，我們網購過的人 都有經驗 只有在付錢的時候才想起來登陸 假設500萬會員中 一天從早上9點到晚上12點 是會員的活躍期，其中有20%r的人 會登陸購物，100萬會員 在15個小時內登陸 那么平均下來每秒才18個用戶 ，肯定會有人說不對 這只是估計 況且 大部分都是下午買東西，這就要去調研 我們只能把并發數控制在一個范圍內 并且要給適當的場景，去模擬才能達到真正的效果，例如100萬中 有50萬人都會在下午2點--4點去購物，這時候我們的并發數4166個/秒 。 哇 怎么這么多 服務器會不會崩潰啊 別擔心 大型門戶網站和購物網站的架構都才要集群設計，里面有幾十臺甚至上百臺服務器去負載這些壓力 假設我們有20臺Web服務器 去均分這4166個請求 下來每天服務器才208并發 對于高性能服務器 這點并發請求數 還不夠撒牙縫。
所以我做性能測試前一定要了解被測系統的情況和客戶的需求，定下一個大概范圍去做。
一個實際的例子
為了便于大家的理解，我們先來看一個性能需求的例子，讓大家有一個感性的認識，本文后面的討論也會再次提到這個例子。
這是一個證券行業系統中某個業務的“實際需求”——實際上是我根據通過網絡搜集到的數據杜撰出來的，不過看起來像是真實的 ^_^
l 系統總容量達到日委托6000萬筆，成交9000萬筆
l 系統處理速度每秒7300筆，峰值處理能力達到每秒10000筆
l 實際股東帳號數3000萬
這個例子中已經包括幾個明確的需求：
l 最佳并發用戶數需求：每秒7300筆
l 最大并發用戶數需求：峰值處理能力達到每秒10000筆
l 基礎數據容量：實際股東帳號數3000萬
l 業務數據容量：日委托6000萬筆，成交9000萬筆——可以根據這個推算出每周、每月、每年系統容量的增長模型
如何獲得有效的性能需求
上面提到了“有效的”性能需求的一個例子和三個條件，下面來我們將看到有哪些途徑可以幫助我們獲得相關的數據——這些方法我在實際的工作中都用過，并且已經被證實是可行的。這幾種方法由易到難排列如下：
1. 客戶方提出
這是最理想的一種方式，通常電信、金融、保險、證券以及一些其他運營商級系統的客戶——特別是國外的客戶都會提出比較明確的性能需求。
2. 根據歷史數據來分析
根據客戶以往的業務情況來分析客戶的業務量以及每年、每月、每周、每天的峰值業務量。如果客戶有舊的系統，可以根據已有系統的訪問日志，數據庫記錄，業務報表來分析。要特別注意的是，不同行業、不同應用、不同的業務是有各自的特點的。例如，購物網站在平時的負載主要集中在晚上，但是節假日時訪問量和交易量會是平時的數倍；而地鐵的售票系統面臨的高峰除了周末，還有周一到周五的一早一晚上下班時間。
3. 參考歷史項目的數據
如果該產品已有其他客戶使用，并且規模類似的，可以參考其他客戶的需求。例如在線購物網站，或者超市管理系統，各行業的進銷存系統。
4. 參考其他同行類似項目的數據
如果本企業沒有做過類似的項目，那么可以參考其他同行企業的公布出來的數據——通常在企業公布的新聞或者成功解決方案中會提到，包括系統容量，系統所能承受的負載以及系統響應能力等。
5. 參考其他類似行業應用的數據
如果無法找打其他同行的數據，也可以參考類似的應用的需求。例如做IPTV或者DVB計費系統的測試，可以參考電信計費系統的需求——雖然不能完全照搬數據，但是可以通過其他行業成熟的需求來了解需要測試的項目有哪些，應該考慮到的情況有哪些種。
6. 參考新聞或其他資料中的數據
最后的一招，特別是對于一些當前比較引人關注的行業，涉及到所謂的“政績”的行業，通?？梢酝ㄟ^各種新聞媒體找到一些可供參考的數據，但是需要耐心的尋找。例如我們在IPTV和DVB系統的測試中，可以根據新聞中公布的各省、各市，以及國外各大運營商的用戶發展情況和用戶使用習慣來估算系統容量和系統各個模塊的并發量。
二 要測試什么問題或我們想要弄清楚或是論證的問題？對系統以及需求有了大致了解后 我們接下來我去分析問題，比如客戶說了 我希望我提交訂單后在10秒內能夠得到響應，那么客戶的需求就是從頁面向系統發送請求再到系統向數據庫發送查詢請求到數據庫返回信息系統把返回數據展現頁面總共的時間是10秒內 這樣具體分析后我們就可以對這個點做相應的用例去測試了，這里敘述的并不完全請見諒 例如多少個用戶在線，或者多少二哥用戶并發提交訂單，在什么樣的環境下 比如帶寬 服務器的性能數量等等 都制約著整個系統的性能，這就要我們去具體的設計不同場景。在這里我們只是討論如何分析客戶給的需求。
三
c) 哪些因素會影響測試結果？
就這是我剛才討論的內容，客戶的帶寬，服務器的性能和數量 ，服務器的帶寬，用戶并發數的多少 等等 都會影響到測試結果~
四 需要怎樣的測試環境
比如我們只是軟件開發公司，我們的客戶是財大氣粗有很大好設備，但是我們小軟件公司，每個人就一臺爛筆記本和公司那幾臺破的不能再破的服務器，我們怎么做性能測試呢，怎么設計測試呢，在有限的條件下我們怎么樣才能最出一個合理的評估呢
如果是用IIS做應用服務器的話，單臺可承受的最大并發數不可能達到10萬級，那就必須要使用集群，通過多臺機器做負載均衡來實現；
如果是用websphere之類的應用服務器的話，單臺可承受的最大并發數可以達到10萬級，但為性能考慮還是必須要使用集群，通過多臺機器做負載均衡來實現；那么，你只要集群的服務器足夠多，10萬并發數當然可以達到了。通常有1個簡單的計算方式，1個連接產生1個session，每個session在服務器上有個內存空間大小的設置，在NT上是3M，那么10萬并發就需要300G內存，當然實際使用中考慮其他程序也占用內存，所以準備的內存數量要求比這個還要多一些。還有10萬個用戶同時在線，跟10萬個并發數是完全不同的2個概念。這個樓上已經說了。但如何做這個轉換將10萬個同時在線用戶轉換成多少個并發數呢？這就必須要有大量的歷史日志信息來支撐了。系統日志需要有同時在線用戶數量的日志信息，還需要有用戶操作次數的日志信息，這2個數據的比例就是你同時在線用戶轉換到并發數的比例。另外根據經驗統計，對于1個JAVA開發的WEB系統（別的我沒統計過，給不出數據），一般1臺雙CPU、2G內存的服務器上可支持的最大并發數不超過500個（這個狀態下大部分操作都是超時報錯而且服務器很容易宕機，其實沒什么實際意義），可正常使用（單步非大數據量操作等待時間不超過20秒）的最大并發數不超過300個。假設你的10萬同時在線用戶轉換的并發數是9000個，那么你最少需要這樣的機器18臺，建議不少于30臺。當然，你要是買個大型服務器，里面裝有200個CPU、256G的內存，千兆光纖帶寬，就算是10萬個并發用戶，那速度，也絕對是嗖嗖的。
謝謝 http://www.cnblogs.com/jackei/archive/2006/11/16/561846.html 文章很精彩。
我總結下 假如我們只有1臺服務器，假設我們的項目需要5000個并發，但是我們手頭沒那么牛的機器，沒關系
1臺雙CPU、2G內存的服務器上可支持的最大并發數不超過500個 如果系統能滿足1臺機器500個并發的請求 那么正式環境下那么多集群的服務器肯定能抗的過去，這是一個數學分析問題 學過概率論的同學一定會明白其中的奧秘，我就不詳說了 今天性能測試第一節課 到此為止 歡迎各位批評~~~~