最近群裡來了很多新朋友，大都是新做測試或準備做測試工作的，見好多新來上來就問關於LoadRunner的使用上的問題。對效能測試的理解也不是太清楚。公司說讓他們對系統做個性能測試，他們聽說LoadRunner是做效能測試的，在網上找了點了LoadRunner的使用說明就開始對系統下刀了。對於一些大公司的專業效能測試人員來說，這個很可笑，但這是種情況是存在的，我當初也到公司時也這麼幹的。
那時還真把效能測報告給整出來了，現在看來那報告沒有任何意義。雖然，雖然對現在的我來說效能測試也只是只懂皮毛。但還是希望通過我這篇文章能讓那些新手們對於效能測試有個入門的瞭解。

理髮店模式

關於理解效能，記得我那時是看了“《LoadRunner沒有告訴你的》之三—理髮店模式”不管你有沒有看過，我這重提一下理髮店模式。

前提：

1. 一個理髮店有三位理髮師傅
2. 每位理髮師傅理一個髮需要一小時

3. 顧客都很忙，從進理髮店起最多隻等三小時（等待時間+理髮時間），如果三小時後還沒輪到自己理髮，立馬走人。

   思考：
   這裡我們來理解“最佳使用者數”和“最大使用者數”。

最佳使用者數：

理髮店的最佳狀態，理髮店收入最多（理髮師傅沒有休息時間，一直在理髮），顧客滿意度最高（顧客隨時到隨時理，無需要等待）。在一個時間點來說，三個理髮師傅服務於三位顧客，那麼這個最佳使用者數是三。

最大使用者數：

1、理髮店的最大承受狀態，理髮店收入最多（理髮師傅沒有休息時間，一直在理髮），顧客的最大忍耐度（來的顧客等待+理髮需要等上三個小時）。

2、假如理髮店生意非常好，早上一開門一下子來了一群顧客（很多），A、B、C三位顧客先理，D、E、F顧客需要等待一小時才能得到理髮師傅的服務，G、H、I三位顧客等待了兩小時才得到服務，後面排隊的J、K、L…..等顧客，已經等了三小時還沒得到服務，因為這已經得達到了他們等待的極限，所以後他們氣憤和無奈離開。

3、當然，理髮店還會不斷的來新的顧客，不斷有等了三小時而沒有得到服務的顧客離開，但對於理髮店而言，他們在一個時間點上，能服務的最大使用者數是九（三位正在接受服務、三位已經等待一小時，三們已經等待兩小時）。

對於最大使用者數，需要注意的兩點：

1. 在理髮店裡很大，可以容納很多位顧客（大於9），總有一部分在這裡等待了三小時而沒有得到服務離開，不要把等待了三小而沒有得到服務的顧客納入最大使用者數裡。
2.

不知道通過上面對理髮店的分析，你對效能有了一些眉目。假如理髮店相當於我們的系統的話，顧客就我們向伺服器所傳送的請求，最佳使用者數和最大使用者數是我們衡量一個系統的處理能力的一種方法。

要帳的模式

這個是我在給一朋友說瀏覽器與伺服器之間交流時用到的例子，感覺比容易理解，所以拿來分享一下。
假設：

1.  A、B、C三個人。
2.  C欠A錢（這裡不考慮多少）
3.  B是專門要賬

思考：
1、瀏覽器與伺服器的資訊傳遞次數：

   A對B說，C欠我錢，你幫我去要。B接到指令後就去找C要錢。
   B對C說，給我20塊錢。
   C說，沒有。
   B對C說，給我10塊錢。
   C說，沒有。
   B對C說，給我5塊錢。
   .........

最後，B回來對A說，哎呀媽呀，C那丫的忒摳門了，一分錢沒有。
對於A來講，只是來說，它只是讓B問C要錢，具體的B與C之間互動了幾次，A是不知道的，它所知道的就是B返回給它的結果，C一分錢沒有。

2、 瀏覽器與伺服器傳遞資料的大小：

還是上面的過程，A對B說，C欠我錢，你幫我去要。B接到指令後就去找C要錢。

B對C說，給我20萬塊錢。
C說，沒問題，沒支票，只有1元硬幣。
..........

B終於把錢拿回來給A。A很納悶，怎麼去了那麼久，B委屈的說，丫的，C給我整了一堆硬幣，太重了，路上走的慢，都快累死我了。
對於A來講，只是來說，它只是讓B問C要錢，誰知道C給的是支票還是硬幣。所以，B去要錢消耗的時間就很長。

所以，要想提高瀏覽器對伺服器的訪問速度，應該減少資料傳遞次數與資料傳遞的大小。

這樣就很自然的引出了瀏覽器的cookie

A在C哪裡存了5毛錢。
A對B說，我在C哪裡存了5毛錢，你去拿來我看看。B跑去問C要了5毛錢回來給A看。
過了一會，A又對B說，我在C哪裡存了5毛錢，你去拿來我看看。B跑去問C要了5毛錢回來給A看。
過了一會，A又對B說，我在C哪裡存了5毛錢，你去拿來我看看。這次C煩了，對B說，你把錢放自己口袋裡吧，等A要的時候，你來問我5毛的人民幣有沒有改版，沒有改版的話，你就直接把口袋裡的5毛錢給A看就行了。

 在這裡A就相當於我們使用者，B相當於瀏覽器，C是伺服器。而cookie就是B的口袋，當然了cookie的用處還很多。比如我們登陸一個系統，提示我們是否儲存密碼（有的還有期限比如，一個星期或一個月），如果我們儲存了，下次再訪問登陸時，瀏覽器就已經幫我們填寫好了賬戶密碼或直接幫我們登陸。那這個賬戶密碼就放在我們瀏覽器的cookie中。

為什麼要說上面的例子呢？因為我們大部分的一部分效能測試是基於B/S架構系統的，理解了瀏覽器與伺服器之間的資料傳遞，有助於我們理解效能測試。

在開始效能測試之前，我們需要知道什麼?

當客戶或老闆把你叫來，對你說，去給我們系統做個性能測試，千萬別傻傻的說“好！”然後，就走了，我以前這麼幹過（那時不懂，打腫了臉充胖子），回到座位後，不知從何下手了。
那麼，我們需要知道什麼呢？

1. 效能測試的目的

首先要知道客戶的要求。
我把效能測試按目的分以下幾種

1）客戶有明確要求

這是一個好的結果，這說明客戶對效能測試有一定的瞭解，知道他們需要的系統要達到一個什麼樣的標準。如：系統要求同時滿足100使用者登陸，平均每個使用者登陸時間不能超過5秒。這個需求很明確，當然也不排除一些不懂裝懂的使用者，提一些不現實的要求。

2）只是想知道目前系統性能（容量測試）

可以把我們的目的就是求得最大使用者數和最佳使用者數。但是，這仍然是比較含糊的一個需求，我們需要對系統做出分析，找出系統的壓力點。

3）找出系統性能瓶頸

這個同樣需要分析可能對系統造成瓶頸的邏輯業務，然後才能進行效能測試。

4）了系統在長時間的壓力下效能狀況（強度測試）

這個一般驗證系統的穩定性，因為系統一旦上線，就有可能會長期處在大使用者的訪問狀態，可能以前沒發現的一些問題就會暴漏出來。比較典型的就是記憶體溢位。

2. 效能測試的環境

確定了我們的測試目的，當然需要測試環境。這裡的環境，我們需要考慮一下幾點

1）硬體環境
我們需要了解被測伺服器硬體配置，用於加壓客戶端的機子配置，CPU 記憶體 等

2）軟體環境

我們需要了解被測系統的架構，前端、中介軟體、伺服器（這裡指執行系統軟體伺服器，如tomcat）、資料庫，以及他們的部署位置。
用於加壓的客戶端採用什麼效能測試工具進行加壓。

3）網路環境

網路環境很重要。在上面的幾個目的中，除了找出系統性能瓶頸可以在廣域網進行，因為這個目的可以不用設定太多的虛擬使用者，只要找出系統哪個地方影響了整個系統的效能就行。
其他目的的測試都需要在，區域網進行，不然你壓力工具所傳送的請求都會卡死在網路的傳輸過程中。

3. 尋找系統的壓力點

我們需要對系統的哪個頁面或業務進行加壓。這個不是自己想出來的，需要與開發人員的溝通。系統的首頁？系統的登入？還是系統的交易過程？各個業務的使用者比例是多少？
只有獲得有效的效能需求，才容易尋找和定位壓力點。
獲得有效的需求：http://www.cnblogs.com/jackei/archive/2006/12/12/589473.html

如果上面的幾點，你都很清晰了，那麼開啟你的效能測試工具開始錄製（或編寫）你的效能測試指令碼吧！

注：以上個人觀點，如有錯誤的之處，請高手指證，以免誤導別人。