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