在性能測試的學習過程中，堅持思想與工具（分開）并行，當前面世面上的性能測試書籍大多把理論與loadrunner融為一體講解，這樣做是正確的，因為有一些性能名詞概念也源于工具。但是，性能測試不是loadrunner，所有的作者也是這么認為的。但他們在講性能測試的時候講的就是loadrunner有，只是講的多少不同罷啦。
你是否覺得我對loadrunner有仇？我之所以將其分開來學，只是希望自己在學習性能測試的時候不要被loadrunner局限了而已。只是覺得在做性能測試時不要帶loadrunner的思維，這樣更容易把握性能測試的本質。
-----------------------------------------------------
性能測試工具，從廣義上講，在性能測試過程中使用到的所有工具都可以稱其為性能測試工具。從狹義上來講，我們可以把性能測試工具分為服務器端性能測試工具與前段性能測試工具。
服務器端性能測試工具也我們測試人員通常所認為的性能測試工具。LoadRunner、JMeter、SilkPerformance、服務器端壓力性能工具需要支持產生壓力和負載，錄制和生成腳本，設置和部署場景，產生并發用戶和向系統施加持續的壓力。
前端性能測試工具應用比較廣泛，開發人員，前端開發人員、測試人員都會經常用到。Firebug 、fildder2、Yslow 、前端性能測試工具只需要關于心瀏覽器等客戶端工具對具體需要展現的頁面的處理過程。
服務器性能測試工具原理
性能測試工具的主要作用是通過模擬生產環境中的真實業務操作，對被測試系統實行壓力負載測試，監視被 測試系統在不同業務、不同壓力性能下的性能表現，找出潛在的性能瓶頸進行分析、優化。
客戶端與服務器相當于兩個人，通過信息來進行交流。由于初次見面不好意思直接交流，與是找來了中間傳話人，客戶端把信息告訴給傳話人，由傳話人來轉達給服務器。那么服務器反饋的信息也由傳話人轉達給客戶端。一般性能測試工具都需要錄制或編寫客戶端行為腳本。
這樣傳達人就有了客戶端的行為能力，從而假扮客戶端來欺騙服務器，與之進行通信。有了客戶端行為了傳達人可以進行自我復制。從而變出N多個傳達人對服務器進通信。---這個傳達人的行為和能力也就是性能測試工具的基本特質。（突然覺得性能工具像第三者插足，而且是可以自我復制瘋狂變態的第三者，哈哈！）
對于目前流行的性能測試工具，他們的基本工作原理都是一致的。在客戶端通過多線程或多進程模擬虛擬用戶訪問，對服務器端施加壓力，然后在過程中監控和收集性能數據。
性能測試工具應該具備什么的特質呢？
1、工具本身占用系統資源少，可擴展性好，可用性強。
2、能模擬真實業務事務操作，在并發時能真正產生業務壓力。（這一點是核心）
3、對壓力測試結果能很好地進行性能分析，快速找出被測試系統的瓶頸。
4、測試腳本的重復性強。
服務器性能測試工具的架構
用戶行為生成部分
我為什么說的這么朦朧，對于熟悉loadrunner的朋友，我說成虛擬用戶腳本生成器，你更容易理解，這個腳本，我們可以錄制，也可以手工編寫。你不要以為這是生成用戶行為的唯一方式。因為在JMeter成中是添加各種組件，通過對組件的配置來完成用戶行為的，當然也可以通過錄制。而在相對簡陋的性能測試工具curl_loader（linux環境下的運行的），他是通過編寫配置文件的形式來描述用戶形為的。
我前面也有提了，雖然性能測試工具由不同的形式來描述，但他們的原理是一樣的，都是通過Proxy方式來實現，具體來說，Proxy作為客戶端和服務器之間的中間人，接收客戶端的數據包。
壓力產生器
壓力產生器用于根據腳本內容產生實際的負載，在性能測試工具中，壓力產生器扮演著“產生負載”的角色。也就根用戶的設置，進行自我復制來生成多個客戶端向服務器發送請求。對于工具來說，每復制出來的一份就是一個進程或線程，進程和線程的運行是要占用系統資源的。所以，對一臺壓力測試機來說能運行的虛擬用戶數也是有限的。根基測試機的配置而定。那么這個時候就要通過多臺測試機合作，來模擬更多的虛擬用戶向服務器發請求。
那么，對于性能測試來說，很重要的一點就是產生“并發”的請求，不然就不會對服務器產生壓力。那多臺機子如何產生“步調一致”的虛擬用戶呢？使用“用戶代理”
用戶代理
用戶代理是運行在負載機上的進程，該進程與產生負載壓力的進程或線程協作，接收調度系統的命令，調度產生負載壓力的進程或線程，從這個意義上看，用戶代理也是壓力產生器的一部分。
調度能力
我們在做復雜的性能測試時，常常會設計各種場景，不同的虛擬用戶數，不同事務的用戶比例，運行時間，設置同步點等，這個時候也需要我們的測試工具有壓力調度能力。從而才能更真實的模擬我們所設計的運行場景。
監控系統
監控系統是性能測試工具直接與用戶進行交互的主要部分，監控系統，主要用戶在壓力測試過程中對各種軟硬件進行監控，如對數據庫、應用服務器，服務器的主要性能表現情況進行監控。用于判斷系統當前處于什么狀態。
當然，監控系統不是性能工具必須的部分，可以通過軟硬件系統自身的監控工具或者第三方監控工具進行監控。但是否有強大的性能計數器監控系統是衡量性能測試工具是否強大的指標之一。
壓力結果分析
壓力結果分析工具可以用來輔助進行測試結果的分析，性能測試工具一般都能將監控系統獲取的性能技術數器值生成曲線圖，折線圖等各種圖表。通過展現性能測試過程中的各種參數指標，來供測試人員進行分析。
但這里需要強調的是，壓力結果分析工具本身不能代替分析者進行性能結果分析，而只是提供多種不同的數據揭示和呈現方法而已。對于這些數據進行分析必然要依靠測試工程師對系統性能分析的知識和經驗。
-------------------------------------------------------
對上面介紹的性能測試工具架構的組成部分，不是第一個性能測試工具都具備，而所具備的強大程度也不相同。比如，有些性能測試工具不具備用戶代理能，有些監控系統能監控的資源很有限或簡陋，有些結果分析數據的呈現不夠詳盡等。
一：性能測試工具模型
廣義地說，性能測試工具是指性能測試過程中使用到所有工具，但是我們習慣上把“性能測試工具”定位于LoadRunner、SilkPerformer一類的工具。
關于性能測試的幾個誤區：
1、認為性能測試就是使用性能測試工具進行測試。
性能測試工具只能幫助你實施性能測試，并不能幫助你完成性能測試的需求、設計和分析。
2、認為性能測試工具可以完成性能測試結果分析工作。
性能測試工具只是能夠根據你的要求以各種方式提供報表，這些報表可以被您用來分析系統性能狀況。
3、不清楚性能測試工具的錄制/回放與功能測試工具的錄制/回放的區別。
功能測試工具的錄制/回放一般是針對GUI的操作錄制，腳本中記錄的是用戶對控件的操作，例如按下了“確認”按鈕或是在“姓名文本框”中輸入了ABCD等內容，這時因為功能測試工具主要是通過操作和數據來驗證功能的正確性，評價的主要標準是GUI的正確性（界面內容的正確性）。而性能測試工具錄制的是服務端和應用之間的通信數據，而不是應用的GUI操作。^_^^_^理解了這一點，就不難明白為什么在進行性能測試腳本錄制的時候，需要首先選擇錄制的協議了。
4、不清楚何時選擇何種協議。
選擇何種協議取決于應用和客戶端之間的通信協議。
二：性能測試工具架構
1、虛擬用戶腳本產生器（Virtual User Generator）：通過一個Proxy作為客戶端和服務器之間的中間人。
2、壓力產生器(Player)：壓力器扮演著“產生負載”的角色。
3、用戶代理(Agent)：運行在負載機(LoadMachine)上的進程，該進程于產生負載壓力的進程或是線程寫作完成“產生負載”的功能。如一臺PC可以順利運行200個左右的VU，但對需要1000個VU的情況顯然很難指望一臺PC，這時就需要通過多臺及其進行協作，“用戶代理“就幫助產生”步調一致“的VU。
4、壓力調度和監控系統(Conductor)：直接與用戶交互的主要內容，壓力調度可以根據用戶的場景要求，設置各種不同腳本的VU數量，設置同步點等，而監控系統則可以對各種數據庫，應用服務器、服務器的主要性能計數器進行監控。
5、壓力結果分析工具(Analysis)：用來輔助進行測試結果的分析。
三：性能測試腳本錄制時的協議類型
^_^^_^不要想當然地根據開發語言來決定協議的選取，這樣子極有可能導致錄制后的腳本不能回放成功。
幾點說明的內容：
1、使用Socket協議可以對任何類型的應用通信進行錄制，但這種錄制生成的腳本很可能沒有任何意義。
2、在對應用間的通信進行錄制生成腳本后，對腳本進行回放，有時會出現回放無法繼續的情況（停留在某個步驟無法進行下去），此時應該考慮是否使用了合適的協議。
——————————————協議選擇參考方案——————————————————————
1、Web應用：應用特點：采用J2EE或是dontNet結構，HTTP/HTTPS協議。
2、C/S應用：
a、客戶端程序以ADO、OLEDB方式連接后臺數據庫，選擇后臺數據庫類型選擇相應的協議。
b、客戶端程序以ODBC方式連接后臺數據庫，ODBC協議。
c、其他協議，根據具體協議類型進行分析。
3、組件：a、COM/DCOMcom/dcom協議。
b、EJB，EJB協議。
4、服務：
a、WebService，WebService協議。
b、Mail服務器，SMTP/POP3協議。
c、FTP服務器，FTP協議。
5、應用服務器：
a、OracleApplicationServer,OracleApplicationServer協議。
b、SAP，SAP協議。
c、Tuexdo,Tuexdo協議。
四：性能測試工具的選擇與評估
這個問題通常會有兩個層面的意義：第一，創建還是購買？第二，如果購買，如何選擇一種商業工具？
1、創建還是購買？
總而言之，”購買“的方式可以以較低的總體成本快速獲得可用的軟件，但如果被測試對象本身有一定的特殊需求，最好使用”創建“的方式構建適合的測試工具。
2、測試工具的評估和選擇過程。
（1）列出需要的工具功能列表
（2）工具比較
（3）成本分析