以下是我的回復(fù)，想法不一定正確，希望拋磚引玉：

我看完郵件的描述，發(fā)現(xiàn)這正好和我前不久做過的一個系統(tǒng)比較像，但我不敢保證我的做法就是對的，只能把他提出的問題，結(jié)合我的實際經(jīng)驗，提出來和大家討論一下。
1、關(guān)于在線用戶數(shù)和并發(fā)用戶數(shù)的之間的換算關(guān)系，其實很難有一個確定的說法，這個問題我一直在考慮，也很希望能夠有一個更好的方法來實現(xiàn)這個換算，但10%是一個普遍為大家所接受的比例，我個人覺得沒有什么問題。至于“背景用戶”，我覺得也是需要的，因為對于這樣的性能需求來說，很重要的一點就是要盡量地接近于真實的業(yè)務(wù)場景，只要你所模擬的是現(xiàn)實中的業(yè)務(wù)操作，那么測試出來的結(jié)果就是可信的。
2、對于第二個問題，我沒大看明白他的意思，如果他的場景是混合場景，那無疑應(yīng)該是按照模型中的比例去設(shè)置虛擬用戶，但我猜測他之所以會提出這個問題，可能是想對單個業(yè)務(wù)交易去做測試，不知道我猜的對不對。
3、所謂突發(fā)性的大并發(fā)加壓策略，模擬的是一種業(yè)務(wù)處于高峰期時的，以及一些突發(fā)的、意外的情況，要看各個系統(tǒng)的具體業(yè)務(wù)情況來定，如果業(yè)務(wù)上存在這樣一種高峰時段（比如到了月底，會有大量的報表生成、導(dǎo)出等工作），我個人認(rèn)為還是非常有必要考慮的，尤其是要關(guān)注一下當(dāng)這樣的壓力過去后，系統(tǒng)是否可以恢復(fù)正常。

另外這邊我也提幾個問題：
1、“網(wǎng)站的每日訪問量10萬人次”，不知應(yīng)如何去實現(xiàn)測試？
2、所謂的“頁面訪問量”是LR中好象是給不出來的，那么我們是否可以將其換算成點擊率的指標(biāo)，然后再去進(jìn)行測試？我在之前做的那個系統(tǒng)就是類似于網(wǎng)站性質(zhì)的，我對于網(wǎng)站的測試也沒有什么經(jīng)驗，僅僅做過那一次，因此也想聽聽兩位的意見。

以下是wufeiwufei的回復(fù)：

您好！
看了那位同行的問題，說實話，如果項目組給我這樣的一個業(yè)務(wù)調(diào)研結(jié)果，我在需求評審中是不會通過，因為對于一個門戶網(wǎng)站，如果你不能估計峰值，不能估計數(shù)據(jù)量，你是如何確定硬件的？如何選擇中間件，如何選擇數(shù)據(jù)庫的？如果需求開發(fā)都做不好，怎么能保證后期的設(shè)計和測試階段能好？這時我會要求項目組按照我說的幾點重新調(diào)研，如果實在做不到，我只會根據(jù)初步的估計，然后算出最佳的并發(fā)數(shù)，最大的并發(fā)數(shù)，及在這些并發(fā)數(shù)下的各個業(yè)務(wù)的響應(yīng)時間，并作成圖表，然后作為測試結(jié)果提交。
為了更好的回答，將問題整理下：
1、根據(jù)每日訪問量10萬人次、目前在網(wǎng)系統(tǒng)每天的頁面訪問量、能滿足同時在線人數(shù)2000人的訪問三個條件，確定測試模型。
2、為什么查詢類對系統(tǒng)瓶頸最大？
需要再次說明的是：這種情況我遇到過，但是都被我擋回去了，或者我是先算出最佳后，反向推導(dǎo)出業(yè)務(wù)數(shù)據(jù)，然后說服了客戶，并沒有根據(jù)這些值確立目標(biāo)，以下是我的粗淺的見解，可能并不正確，還望jackei兄指導(dǎo)。
第一個問題: 按照現(xiàn)在的業(yè)務(wù)調(diào)研數(shù)據(jù)，想要精確的算出是不可能的，只能算出最低值，所以測試方案僅供參考，請根據(jù)實際情況進(jìn)行調(diào)整。
模型如下：
1、收集系統(tǒng)每天頁面訪問量和對應(yīng)數(shù)據(jù)庫中的數(shù)據(jù)量（日志，業(yè)務(wù)表插入記錄數(shù)，表空間等等），如果設(shè)計的時候有準(zhǔn)備最好以年為統(tǒng)計時段，實在不行就用估計的業(yè)務(wù)量最大的一個月，再不行只有用1個星期了。得出平均的每日訪問量與數(shù)據(jù)庫數(shù)據(jù)量之間的比例，例如：平均日訪問量10000，數(shù)據(jù)庫業(yè)務(wù)表插入1000條數(shù)據(jù)。根據(jù)這個比例算出日訪問量10萬次時，數(shù)據(jù)庫數(shù)據(jù)量的膨脹值。最好還能根據(jù)這些得出那些表的訪問量大，查詢動作多還是update動作多，為第二問題做些準(zhǔn)備。
2、以幾個星期或者幾天為時間，在數(shù)據(jù)庫中做個定時器，將每小時的訪問量讀出存入一個特定表中（24個小時24個字段），形成圖表，算出每小時訪問量所占最大比值，80％的平均比值，然后乘以100000，得到每小時訪問量最大值，80％平均值。假設(shè)得到的最大值是20000人/次，80％平均值是5000人/次。
3、對于在線人數(shù)2000人，有兩種理解，分別是平均在線人數(shù)2000人和最大在線人數(shù)2000人。按照你的描述，我就把它當(dāng)成是指最大在線人數(shù)2000人。如果你是為了推算session過期時間，那么根據(jù)每小時訪問量最大值是20000人/次，我覺得session設(shè)置成6分鐘就足夠了，如果你已經(jīng)設(shè)置了1小時的session過期時間，那么根據(jù)每小時訪問量最大值是20000人/次，你必須考慮到此時最大在線人數(shù)已經(jīng)是20000次了，你必須根據(jù)這個值（而不是原來的2000）算出內(nèi)存大小，至于每個session的大小，為了嚴(yán)謹(jǐn)，請根據(jù)實際情況進(jìn)行查看。其實我覺得在線人數(shù)2000人，除了算session過期時間，衡量內(nèi)存（你要全部都用cookie，那也沒必要算），沒什么大用。如果實在要測，可以采用不錄制退出（當(dāng)然程序設(shè)計里要去掉重復(fù)登陸的判斷，或是找到足夠多的ip地址），準(zhǔn)備大量數(shù)據(jù)多次迭代，持續(xù)測試來達(dá)到驗證這個值的目的。
4、根據(jù)你session設(shè)置的時間，參考在線人數(shù)和最大每小時訪問人數(shù)，算出平均每秒并發(fā)數(shù)，按照假設(shè)，算出每秒只需6個并發(fā)數(shù)。以這個做為最佳并發(fā)數(shù)的最低標(biāo)準(zhǔn)。最大并發(fā)數(shù)以測試數(shù)據(jù)為準(zhǔn)。一般這種情況下，最佳并發(fā)值一定比這個標(biāo)準(zhǔn)大10到20倍。進(jìn)而反向推算內(nèi)存大小，業(yè)務(wù)數(shù)量等。
5、如果你按照每秒6個并發(fā)數(shù)，請不要在腳本中設(shè)置thinktime和pacing，同時必須至少測試24個小時，因為數(shù)據(jù)是從一天推斷而來。

第二個問題：
1、根據(jù)那位同行的描述，我看不明白他的腳本如何設(shè)置的，并不清楚并發(fā)用戶數(shù)多少，以及trancation中包含什么，而導(dǎo)致查詢速度較慢。
2、如果我來分析，首先寫個簡單的接口調(diào)用頁面（傳入?yún)?shù)，判斷返回值，不顯示返回數(shù)據(jù)），然后跳過系統(tǒng)，直接測試接口，如果速度不慢，將展現(xiàn)返回數(shù)據(jù)的頁面加上，再次測試；如果還是慢，那么跳過接口，直接測試存儲過程或是sql語句。

發(fā)送了幾次郵件，總是發(fā)不出去，最后一次貌似發(fā)送成功了，也不知道是否可以收到 ^_^

以下是jackei的回復(fù)：

兩位仁兄好。實在不好意思，今天才給大家回復(fù)郵件，下面是我的一些看法。

首先，性能測試的主要目的還是去了解和驗證系統(tǒng)的響應(yīng)能力，并盡可能避免系統(tǒng)在上線運(yùn)行后出現(xiàn)性能缺陷。而為了達(dá)到這個目的，一方面要了解客戶的性能需求，另一方面要盡可能的去模擬上線后的情況——這兩個方面看似相同，但實際上還是存在少少的差別的。例如，有的時候客戶提出的需求未必合理，或者未必是準(zhǔn)確的、可度量的，那我們就更需要根據(jù)對客戶以往的業(yè)務(wù)情況來進(jìn)行分析和整理。

我們再來看一下在這封郵件中，所提供的信息包括如下幾條：

1. 每日訪問量10萬人次；

2. 目前在網(wǎng)系統(tǒng)每天的頁面訪問量

3. 能滿足同時在線人數(shù)2000人的訪問

正如原文中提到的，這是一個比較復(fù)雜的門戶網(wǎng)站，提供了多種可供訪問的服務(wù)，如果我們不能進(jìn)一步獲取有關(guān)系統(tǒng)負(fù)載更準(zhǔn)確的數(shù)據(jù)，而僅僅是依靠上面的幾條信息，恐怕是很難模擬出一個盡可能有效的場景的。不過我們也知道，要模擬一個完全真實的場景是不可能的，我們只能是盡可能的無限接近真實的場景。下面是我的思路：

1. 在進(jìn)行多個業(yè)務(wù)的組合場景的測試前，先對每個單一的業(yè)務(wù)模塊本身的性能進(jìn)行驗證。如果單一模塊的性能都無法達(dá)到要求，或者單一模塊已經(jīng)在滿足性能需求的同時消耗了大量的系統(tǒng)資源，那么它將成為制約系統(tǒng)性能的一塊“短板”；

2. 為了對單一模塊的性能進(jìn)行驗證，需要明確每個業(yè)務(wù)模塊所要承受的負(fù)載有多大。可以考慮獲取系統(tǒng)在上一年度中，每個月的月初、月中、月末每個業(yè)務(wù)的日均訪問量，例如，查詢模塊1，一月上旬的日均訪問量，一月中旬的日均訪問量……并進(jìn)一步根據(jù) 80/20 的原則（80％的業(yè)務(wù)發(fā)生在20％的時間內(nèi)）來估算系統(tǒng)最終需要面對的負(fù)載；

3. 根據(jù)上面的數(shù)據(jù)，同客戶方確定該模塊應(yīng)該要滿足的性能需求——包括負(fù)載和響應(yīng)時間要求（在原文中一直沒有看到響應(yīng)時間的要求）。另外，還需要明確數(shù)據(jù)環(huán)境，例如，系統(tǒng)中只有10萬業(yè)務(wù)數(shù)據(jù)，和有1000萬業(yè)務(wù)數(shù)據(jù)，在進(jìn)行查詢和業(yè)務(wù)辦理時會導(dǎo)致性能表現(xiàn)的不同；

4. 對單一模塊的性能進(jìn)行驗證，如果單一模塊的性能無法滿足需求，則先解決這個模塊的問題——如果認(rèn)為查詢類業(yè)務(wù)性能較差，應(yīng)該在這個時候進(jìn)行分析，并識別性能瓶頸，進(jìn)行優(yōu)化；

5. 對于組合場景的模擬，一直是一個存在爭議的問題。常用的方法是根據(jù)對系統(tǒng)某個時間的“剖面”，來獲取系統(tǒng)負(fù)載在不同模塊上的分配比例——例如上面我們分別取到了“系統(tǒng)在上一年度中，每個月的月初、月中、月末每個業(yè)務(wù)的日均訪問量以及峰值”——再使用不同的腳本模擬不同的業(yè)務(wù)，并對每個業(yè)務(wù)分配相應(yīng)的負(fù)載。根據(jù)原始郵件中的描述，會存在三種不同的組合場景，即：月初的偏查詢型，月中的平衡型，和月末的偏業(yè)務(wù)型。在實際執(zhí)行測試時，根據(jù)不同的模型為不同的腳本分配不同的用戶數(shù)，并運(yùn)行腳本足夠長的時間，或足夠多的迭代次數(shù)。關(guān)于這方面的，可以參考國外同行的一些資料，如下：

Part 2: Modeling Individual User Delays

Part 3: Modeling Individual User Patterns

Part 4: Modeling Groups of Users

6. 對于在線用戶和并發(fā)用戶的問題，我想我們是否可以進(jìn)一步討論一下：對于系統(tǒng)來說，所謂的在線用戶并不是靜止不動的，他們應(yīng)該是來自于上一個操作，而且也一定會發(fā)起下一個操作——即便是直接離開網(wǎng)站。所以，如果想更準(zhǔn)確的模擬用戶場景，則還需要進(jìn)一步對用戶的行為進(jìn)行分析。所以我不是很贊成簡單的模擬一些用戶占用一些資源的方法；

7. 可以不使用集合點，也可以不使用 think time，使用 Ramp up 的方式增加并發(fā)用戶數(shù)更多的是用于了解隨并發(fā)用戶數(shù)增多，系統(tǒng)的性能表現(xiàn)會如何改變，所以“每10秒增2個用戶”似乎意義不大，建議在組合場景中等比例的增加各個腳本的并發(fā)用戶數(shù)量，并觀察系統(tǒng)的性能表現(xiàn)；

8. 超過預(yù)期負(fù)載的測試也是必須的，特別是對于每天都處理大量業(yè)務(wù)的門戶，需要考慮系統(tǒng)在任意時刻的可用性和面對超負(fù)荷運(yùn)行時的可恢復(fù)性。這方面可以參考我在下面一篇文章提到的“可恢復(fù)性測試（Recoverability Testing）”。http://www.cnblogs.com/jackei/archive/2006/12/04/580966.html。

評論在繼續(xù)，而且越來越精彩！以下是wufeiwufei的回復(fù)：

兩位仁兄好，昨天有事未能及時回復(fù)，十分抱歉。

首先，我想先說說我不認(rèn)同jackei和xingxin兄的兩個推斷性能標(biāo)準(zhǔn)的行業(yè)原則。根據(jù)我對門戶網(wǎng)站的測試經(jīng)驗，發(fā)現(xiàn)有如下幾種規(guī)律：

1、大部分人大多數(shù)時間是在看而非在操作。

2、大多數(shù)操作集中在查詢和操作結(jié)果的顯示上。

3、大多數(shù)人的操作所涉及的事務(wù)數(shù)僅僅只有幾個。

4、根據(jù)門戶網(wǎng)站的類型和業(yè)務(wù)的不同，大多數(shù)門戶網(wǎng)站的常規(guī)忙時是可以預(yù)測的。（突發(fā)情況除外）

如果兩位認(rèn)同這幾種規(guī)律，那我們再來看看這3個需求點。

1、每日訪問量10萬。

2、目前在網(wǎng)系統(tǒng)每日訪問量

3、能滿足同時在線2000人的訪問量。

根據(jù)規(guī)律我們可以得出推斷如下：

1、我們可以知道10萬人和在線2000人都不能作為推斷并發(fā)數(shù)的絕對依據(jù)。

2、根據(jù)規(guī)律4，我不太清楚，80％和20％的意義會有大（大概只有在測出真實性能指標(biāo)反向推導(dǎo)業(yè)務(wù)量時候有作用）。

3、根據(jù)業(yè)務(wù)調(diào)研（這個調(diào)研是肯定可以得出的，因為常規(guī)的門戶網(wǎng)站會有相應(yīng)的業(yè)務(wù)量報表）以及每日訪問量，我們可以推斷出這個門戶網(wǎng)站的忙時所占的業(yè)務(wù)量比值。

4、根據(jù)規(guī)律1，2，3，我不是很理解為什么要逐漸增加并發(fā)用戶數(shù)（按照我的理解這樣做的目的并不是為了得到最佳和最大，而逐漸增加并發(fā)用戶數(shù)只是為了獲得系統(tǒng)曲線，這個曲線對用戶的意義不大，更多的是幫助我們分析），因為大多數(shù)的用戶在大多數(shù)時間并沒有發(fā)出請求。如果我們是要測試服務(wù)器極端情況，那也應(yīng)該直接用最大的并發(fā)數(shù)進(jìn)行測試或是用大于等于最佳并發(fā)數(shù)進(jìn)行長時間負(fù)載測試。性能測試的最主要目的是找出系統(tǒng)的瓶頸所在，為了這個目的而使得腳本盡量接近真實的環(huán)境，但是一味的追求真實而忽略了根本目的，也就失去的性能測試的意義，想這種逐漸增加并發(fā)用戶數(shù)，你得出的響應(yīng)時間有多大意義了，這個時間既不能說服用戶是真實的情況，又不如最佳時間那么有說服力，還不如最大并發(fā)數(shù)下的響應(yīng)時間有警示作用。

5、我們根據(jù)這3個需求點是無法得出具體的性能指標(biāo)的，這只能作為參考，做為我們得出實際的性能指標(biāo)后，推導(dǎo)出業(yè)務(wù)量，并用來說服客戶的一個依據(jù)。

先放下這個問題，我覺得我們有必要來探討下性能測試工程師到底應(yīng)該做些什么，我提出幾個問題，希望jackie和xingxing兄能抽空思考下：

1、性能測試工程師更應(yīng)該關(guān)注系統(tǒng)的性能還是對真實環(huán)境的模擬。

2、性能測試工程師的最重要守則是不是應(yīng)該是誠實和準(zhǔn)確。

3、性能測試工程師是為了檢測系統(tǒng)性能還是為了保證系統(tǒng)的運(yùn)行。

我給出我的見解：

1、性能測試工程師更應(yīng)該關(guān)注系統(tǒng)的性能，真實環(huán)境的模擬只是關(guān)注性能的一種手段，如果手段與目的沖突，那就應(yīng)該將舍棄真實環(huán)境而用更干凈的環(huán)境。

2、性能測試工程師應(yīng)該以誠實和準(zhǔn)確作為自己的守則，也就是對于不準(zhǔn)確不合理的需求應(yīng)該有勇氣去引導(dǎo)客戶而不是讓苦戶引導(dǎo)你。比如上一種需求，如果在需求確認(rèn)前，你應(yīng)該引導(dǎo)客戶，去取得需求，如果是在驗收階段，你應(yīng)該是根據(jù)實際得性能指標(biāo)去說服客戶放棄前一個需求，接受后一個標(biāo)準(zhǔn)。

3、性能測試工程師是為了檢測系統(tǒng)得最佳和最大性能，而不是為了保證系統(tǒng)在實際中得運(yùn)行，這點是要強(qiáng)調(diào)的，因為我們測試所用的方法都是一種對請求和響應(yīng)的模擬，這點本身就已經(jīng)不真實了，所以得出的指標(biāo)只能作為一種參考，因為實際中系統(tǒng)遇到的情況千奇百怪，你是無法預(yù)測的，而對這種情況的保證只有交給監(jiān)控。比如：上述這個門戶網(wǎng)站是有可能出現(xiàn)2000在線人數(shù)變成2000并發(fā)數(shù)的，你無法為了這個突發(fā)的情況去擴(kuò)大成本，滿足這種極端情況，所以你所能做的是讓監(jiān)控部門監(jiān)控系統(tǒng)，遇到這種情況后，去主動拒絕掉其中部分人的請求，而保證系統(tǒng)的正常運(yùn)行。

以下是我的回復(fù)：

認(rèn)真拜讀了suliang兄的郵件，只覺得說得真是精彩！真的學(xué)到了很多東西，非常感謝！

很巧合的是，suliang兄提出的問題“1、性能測試工程師更應(yīng)該關(guān)注系統(tǒng)的性能還是對真實環(huán)境的模擬。”正好是我最近一直在思考的問題。而就在一個小時前，我在給關(guān)河老師的回復(fù)的貼子里面也提到了這個問題，正有意和各位同行討論（見該鏈接：http://www.aygfsteel.com/xingcyx/archive/2007/01/09/90498.html#92514）

正如我在回復(fù)里面說的，我在實際的性能測試工作中，通常都會要求將后臺服務(wù)器的一些無關(guān)進(jìn)程、服務(wù)停掉，并且盡量使網(wǎng)絡(luò)獨立、或者保證帶寬足夠等，這樣的做法，本質(zhì)上也是在確保使測試出來的性能結(jié)果盡量接近“實際的代碼執(zhí)行時間”。也就是說實際上，對于這第一個問題，我和suliang兄的意見是一致的。因為在項目組提出性能測試的申請時，他們通常是要求我們能夠幫助他們指出他所開發(fā)的“應(yīng)用系統(tǒng)”的性能問題（或者更嚴(yán)格地說，是“代碼執(zhí)行”的效率）。然而，同時我可能會有另外一個身份，是作為公司的性能測試組成員，接受客戶的委托，來對開發(fā)組開發(fā)的軟件進(jìn)行一個性能測試，因此也必然會出現(xiàn)兩種不同角度的沖突。所以這個問題的提出非常好，真是提到我的心里去了，我也很希望聽聽jackei和其它專家的看法！

對于問題“2、性能測試工程師的最重要守則是不是應(yīng)該是誠實和準(zhǔn)確。”，我想答案是肯定的，我十分希望自己能夠達(dá)到這樣一個標(biāo)準(zhǔn)。不過實際的情況往往是不以我的意志為轉(zhuǎn)移的，個人感覺在國內(nèi)的軟件業(yè)，要做到這一點是很困難的，個中原因我想我不用多說各位也都很清楚，也想聽聽suliang兄的成功經(jīng)驗。^_^

至于問題“3、性能測試工程師是為了檢測系統(tǒng)性能還是為了保證系統(tǒng)的運(yùn)行。”，提得更是非常之好！因為說實話，如果不是suliang兄提出，我一直到現(xiàn)在都沒有意識到這個問題。我說說自己的看法吧：我覺得應(yīng)該是前者。在我看來，性能測試的主要目的有兩種：一是檢驗系統(tǒng)的性能是否符合要求（假如這個要求已經(jīng)被提出的話），二是找到系統(tǒng)的性能瓶頸，為優(yōu)化提供依據(jù)，簡單概括就是“一評測、二調(diào)優(yōu)”。每進(jìn)行一次性能測試，目的總會是其中之一，或者兼而有之。我自己的實際工作中常常是兼而有之的，不知道兩位的情況是怎樣。而至于“保證系統(tǒng)的運(yùn)行”，我認(rèn)為應(yīng)該是項目經(jīng)理/產(chǎn)品經(jīng)理/市場經(jīng)理/銷售經(jīng)理等根據(jù)我們的測試結(jié)果去相應(yīng)調(diào)整系統(tǒng)的運(yùn)行配置或者銷售策略等。當(dāng)然這樣做的前提是我們的測試結(jié)果要十分嚴(yán)謹(jǐn)、準(zhǔn)確，能夠真正有參考依據(jù)價值，這也是我們性能測試工程師的責(zé)任重大之所在。

這樣的討論越來越有趣和有意義了，我非常希望能夠繼續(xù)下去！再次感謝兩位在百忙之中抽出時間對我的指教！

在第二段評論即wufeiwufei的回復(fù)中模型的第2點有如下的句子：
算出每小時訪問量所占最大比值，80％的平均比值，然后乘以100000，得到每小時訪問量最大值，80％平均值。假設(shè)得到的最大值是20000人/次，80％平均值是5000人/次。
我對“80％的平均比值”的意思不太明白。我是一個測試新手，能否給解釋一下？

取最大的訪問量的80%（根據(jù)“二八原則”）。