最近群里來了很多新朋友，大都是新做測試或準備做測試工作的，見好多新手上來就問關于LoadRunner的使用上的問題。對性能測試的理解也不是太清楚。公司說讓他們對系統做個性能測試，他們聽說LoadRunner是做性能測試的，在網上找了點LoadRunner的使用說明就開始對系統下刀了。對于一些大公司的專業性能測試人員來說，這個很可笑，但是這種情況是存在的，我當初剛到公司時也這么干的。
那時還真把性能測報告給整出來了，現在看來那報告沒有任何意義。雖然對現在的我來說性能測試也只是只懂皮毛。但還是希望通過我這篇文章能讓那些新手們對于性能測試有個入門的了解。
----//理發店模式
關于理解性能，記得我那時是看了“《LoadRunner沒有告訴你的》之三---理發店模式”不管你有沒有看過，我這重提一下理發店模式。
前提：
1、一個理發店有三位理發師傅
2、每位理發師傅理一個發需要一小時
3、顧客都很忙，從進理發店起最多只等三小時（等待時間+理發時間），如果三小時后還沒輪到自己理發，立馬走人。
思考：
這里我們來理解“最佳用戶數”和“最大用戶數”。
最佳用戶數：
理發店的最佳狀態，理發店收入最多（理發師傅沒有休息時間，一直在理發），顧客滿意度最高（顧客隨時到隨時理，無需要等待）。在一個時間點來說，三個理發師傅服務于三位顧客，那么這個最佳用戶數是三。
最大用戶數：
理發店的最大承受狀態，理發店收入最多（理發師傅沒有休息時間，一直在理發），顧客的最大忍耐度（來的顧客等待+理發需要等上三個小時）。
假如理發店生意非常好，早上一開門一下子來了一群顧客（很多），A、B、C三位顧客先理，D、E、F顧客需要等待一小時才能得到理發師傅的服務，G、H、I三位顧客等待了兩小時才得到服務，后面排隊的J、K、L.....等顧客，已經等了三小時還沒得到服務，因為這已經得達到了他們等待的極限，所以后他們氣憤和無奈離開。
當然，理發店還會不斷的來新的顧客，不斷有等了三小時而沒有得到服務的顧客離開，但對于理發店而言，他們在一個時間點上，能服務的最大用戶數是九（三位正在接受服務、三位已經等待一小時，三們已經等待兩小時）。
對于最大用戶數，需要注意的兩點：
1、在理發店里很大，可以容納很多位顧客（大于9），總有一部分在這里等待了三小時而沒有得到服務離開，不要把等待了三小而沒有得到服務的顧客納入最大用戶數里。
2、假如理發店很小，最多只能容納六位顧客，當第七個顧客來時，雖然，我們知道他只需要等待兩小時就可得到服務（這個時間是他可以接受的等待時間），但由于理發店容量有量，這第七個顧客只有改天再來了。
關于理發店原理，詳細請瀏覽http://www.51testing.com/html/58/n-10558.html
不知道通過上面對理發店的分析，你對性能有了一些眉目。假如理發店相當于我們的系統的話，顧客就我們向服務器所發送的請求，最佳用戶數和最大用戶數是我們衡量一個系統的處理能力的一種方法。 ----//要帳的模式
注：上圖是自己找來修改的，湊合著看吧！呵呵
這個是我在給一朋友說瀏覽器與服務器之間交流時用到的例子，感覺比容易理解，所以拿來分享一下。
假設：
1）A、B、C三個人。
2）C欠A錢（這里不考慮多少）
3）B是專門要賬
思考：
瀏覽器與服務器的信息傳遞次數：
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一分錢沒有。
瀏覽器與服務器傳遞數據的大小：
還是上面的過程，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.51testing.com/html/68/n-10568.html
如果上面的幾點，你都很清晰了，那么打開你的性能測試工具開始錄制（或編寫）你的性能測試腳本吧！
注：以上個人觀點，如有錯誤的之處，請高手指證，以免誤導別人。