本篇文章主要簡單總結下效能測試工具的原理以及如何選型。效能測試和功能測試不同，效能測試的執行是基本功能的重複和併發，需要模擬多使用者，在效能測試執行時需要監控指標引數，同時效能測試的結果不是那麼顯而易見，需要對資料進行分析。這些特點決定了效能測試更適合通過工具來完成。
一、淺談為什麼需要工具
我們來看下工具的定義：它原指工作時所需用的器具，後引申為為達到、完成或促進某一事物的手段。（---來自百度的解釋）
1、從人類進化的角度來看，會製造並使用工具是人和猿人最根本的區別，因為工具可以幫助我們提高生產力和效率。
2、想象下如果不使用工具進行效能測試會怎麼樣？
我們可以從效能測試的定義的角度來分析，效能測試是指通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項效能指標進行測試。如果不使用工具，僅靠人工進行效能測試會存在以下的弊端：
a）測試需要投入大量的資源：
為了模擬多種負載、併發的場景需要多人協同工作，通常測試沒有很多的資源，而且就算有資源人工的效果也會大打折扣，甚至於某些場景僅憑人工是無法完成的。
b）可重複性非常差：
效能測試經常需要反覆調優和測試執行，如果沒有工具的幫助，全靠人工實在不敢想象。
c）測試準確性較差：
由於需要模擬多種負載和併發場景，如果由人工來操作，難免會存在誤差，而且相對工具或程式來說這種誤差會更大，對測試結果影響也非常大。
d）結果的收集、整理和呈現形式差：
如果沒有工具，全憑人工採集資料相對工具來說也會存在較大的誤差。
二、效能測試與效能測試工具的關係
1、效能測試從測試階段來劃分屬於系統測試，其和具體使用什麼工具並沒有直接的關係。使用工具只是為了提高效能測試效率和準確性的一種方法和手段。從本質上來看，同做其它事情時使用工具沒有什麼實質性的區別。
2、效能測試不等於Loadrunner，LR只是效能測試工具其中的一種，而且它也不是萬能的，在某些情況下它也並不能派上用場。推薦看下《讓LoadRunner走下神壇》和《讓LoadRunner再次走下神壇》這兩篇文章於對效能測試和LR的關係講的比較深刻。
3、自動化測試工具與效能測試工具的區別：效能測試工具一般是基於通訊協議的（客戶器與伺服器交換資訊所遵守的約定），它可以不關心繫統的UI，而自動化使用的是物件識別技術，關注UI介面。自動化無法或很難造成負載，但是通過協議很容易。
三、效能測試工具選型參考：
通常在公司或專案中，我們選擇任何工具時都會做一些調研，目的就是為了選擇適合公司或專案的工具。那麼效能測試工具也不例外，通常可以從以下幾個方面進行考慮：
1、成本方面：
a）工具成本：工具通常分為商業閉(shou)源(fei)和非商業開(mian)源(fei)兩種，商業工具通常功能比較強大，收費，由於收費所以可提供售後服務，如果出了問題有專業人士幫忙處理。而開源工具通常是免費的，功能有限，維護工具的組織也是自發的，所以如果碰到問題需要自行解決，沒有專人提供服務。具體選擇商業還是開源的工具，需要根據公司的情況，比如公司規模、願意承擔的成本、專案綜合情況等方面考慮。一般來看大公司通常可以承擔的起工具的費用，會考慮購買商業工具。而小公司由於資金壓力，可能會選擇開源的工具。
b）學習成本：使用任何工具都需要進行學習，這樣一來就會產生學習成本（比如：時間），因此我們在選擇工具時也需要考慮到專案組成員的學習成本。如果有兩種工具A和B都能滿足專案組測試的需求，如果A工具大部分人都會使用，而B工具只有極少部分人會使用，那麼建議優先考慮A工具。通常，對於測試人員最好熟悉一款流程的商業（效能）工具，一款開源免費（效能）工具，還需要熟悉常見的（效能）指令碼開發語言等，這是基本要求。
2、支援的協議：
效能測試通常跟協議聯絡非常緊密，比如B/S的系統通常使用http協議進行客戶端和伺服器商的資訊交換，C/S的系統通常使用socket協議進行資訊交換。在選擇工具時，需要考慮專案使用的協議。一個測試工具能否滿足測試需求，能否達到令人滿意的測試結果，是選擇測試工具要考慮的最基本的問題。
3、生命力：
現在的效能測試工具非常多，比如LR，jmeter這類較大眾的工具網上相關的資料非常多，但一些小眾工具可能網上資料比較少。如果在工具使用過程中碰到了比較極手的問題，在錄求解決方案或幫助時，大眾的的工具相對來說會比較有優勢一點，畢竟使用的人越多，資料越多，那麼自己碰到的問題也許別人早就碰到並解決了，即時之前沒有人碰到過，由於使用研究的人多，通過社群或論壇的幫助相信總會有高手能協助解決的。
4、跨平臺：
這一點自不必多說，看看JAVA為什麼一直這流行就知道了。
四、常見效能測試工具：
效能測試工具，從理論上來講在效能測試過程中使用到的所有工具都可以稱其為效能測試工具，通常分為以下幾類：
說明：
- 伺服器端效能測試工具：需要支援產生壓力和負載，錄製和生成指令碼，設定和部署場景，產生併發使用者和向系統施加持續的壓力。
- web前端效能測試工具：需要關於心瀏覽器等客戶端工具對具體需要展現的頁面的處理過程。
- 移動端效能測試工具：同web端效能測試工具也需要關心頁面的處理過程，另外還要具體資料採集的功能，比如：手機CPU、記憶體、電量，啟動時間等資料的記錄。
- 資源監控工具：這個主要是能夠收集效能測試過程中的資料以及良好的結果展現方式。
PS：本篇文章主要總結下伺服器端效能測試工具LR和Jmeter，後面也會對這兩個工具進行簡單的對分。
五、常見效能測試工具特點
- JMeter：採用的是多執行緒模型，擴充套件性很強，不過製造壓力沒有那麼高。它很適合用來壓一些Tomcat服務，或者一些後端介面。JMeter的缺點是壓力值不能精確控制，難以適應高併發的情況，而且由於是JAVA編寫的，本身比較消耗資源。
- LoadRunner：更像是一個模擬器，它比較適用於前端構造較複雜場景的情況，比如模擬100個使用者登入的場景，LoadRunner對非技術人員提供了很好的支援。LoadRunner不適用後端介面。
下表為JMeter和LoadRunner對比表：
| 描述 | JMeter | LoadRunner |
| 架構原理 | 通過中間代理，監控和收集併發客戶端的指令，把他們生成指令碼，再傳送的應用伺服器，再監控應用伺服器反饋的過程 | 同JMeter |
| 安裝 | 簡單，解壓即可，比較靈活 | LoadRunner安裝包比較大，安裝比較麻煩，工具本身相對比較笨重 |
| 支援的協議 | 支援多種協議：HTTP、HTTPS、SOAP、FTP、Database via JDBC、JMS等，但相對LR還是不夠全面，由於此原因相對來說jemter比較靈活，輕便 | 支援的協議非常多，比較全面，但正因此顯得工具本身比較笨重，不夠靈活 |
| 指令碼錄製 | 提供了一個利用本地ProxyServer（代理伺服器）來錄製生成測試指令碼的功能，也支援badboy錄製再生成JMeter指令碼 | 自帶錄製功能強大，可直接錄製回放 |
| 併發模型 | 通過增加執行緒組的數目，或者是設定迴圈次數來增加併發使用者 | 支援多種併發模型，通過在場景中選擇要設定什麼樣的場景，然後選擇虛擬使用者數 |
| 分散式測試 | 支援，可設定多臺代理，通過遠端控制實現多臺機器併發壓力 | 同JMeter |
| 資源監控 | 通過JMeterPlugins外掛和ServerAgent實現 | 自帶資源監控功能 |
| 報告分析 | 通過與Ant整合，生成HTML報告 | 自身支援生成HTML、Word報告 |
| 虛擬IP | 不支援 | 支援 |
| 網速模擬 | 不支援 | 支援 |
| 擴充套件性 | 開源，可根據需求修改原始碼 | 通過擴充套件函式庫實現 |
| 學習成本 | 主要是自學官網上的資料 | 網上資料和相關培訓很多，購買正版的話，還有技術支援 |
六、效能測試工具學習教程：
1、Loadrunner：目前還未整理，後續會慢慢整理成文章，敬請期待...
2、Jmeter：可檢視我的另一篇文章Jmeter教程索引貼
3、Gatling：未使用過，網上資料也比較少，入門推薦：新一代伺服器效能測試工具Gatling