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

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

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

以下是wufeiwufei的回復：

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

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

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

以下是jackei的回復：

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

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

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

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

2. 目前在網系統每天的頁面訪問量

3. 能滿足同時在線人數2000人的訪問

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

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

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

3. 根據上面的數據，同客戶方確定該模塊應該要滿足的性能需求——包括負載和響應時間要求（在原文中一直沒有看到響應時間的要求）。另外，還需要明確數據環境，例如，系統中只有10萬業務數據，和有1000萬業務數據，在進行查詢和業務辦理時會導致性能表現的不同；

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

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

Part 2: Modeling Individual User Delays

Part 3: Modeling Individual User Patterns

Part 4: Modeling Groups of Users

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

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

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

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

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

首先，我想先說說我不認同jackei和xingxin兄的兩個推斷性能標準的行業原則。根據我對門戶網站的測試經驗，發現有如下幾種規律：

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

2、大多數操作集中在查詢和操作結果的顯示上。

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

4、根據門戶網站的類型和業務的不同，大多數門戶網站的常規忙時是可以預測的。（突發情況除外）

如果兩位認同這幾種規律，那我們再來看看這3個需求點。

1、每日訪問量10萬。

2、目前在網系統每日訪問量

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

根據規律我們可以得出推斷如下：

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

2、根據規律4，我不太清楚，80％和20％的意義會有大（大概只有在測出真實性能指標反向推導業務量時候有作用）。

3、根據業務調研（這個調研是肯定可以得出的，因為常規的門戶網站會有相應的業務量報表）以及每日訪問量，我們可以推斷出這個門戶網站的忙時所占的業務量比值。

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

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

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

1、性能測試工程師更應該關注系統的性能還是對真實環境的模擬。

2、性能測試工程師的最重要守則是不是應該是誠實和準確。

3、性能測試工程師是為了檢測系統性能還是為了保證系統的運行。

我給出我的見解：

1、性能測試工程師更應該關注系統的性能，真實環境的模擬只是關注性能的一種手段，如果手段與目的沖突，那就應該將舍棄真實環境而用更干凈的環境。

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

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

以下是我的回復：

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

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

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

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

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

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

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

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