性能測試總結(三)--工具選型篇

　　本篇文章主要簡單總結下性能測試工具的原理以及如何選型。性能測試和功能測試不同，性能測試的執行是基本功能的重復和并發，需要模擬多用戶，在性能測試執行時需要監控指標參數，同時性能測試的結果不是那么顯而易見，需要對數據進行分析。這些特點決定了性能測試更適合通過工具來完成。

一、淺談為什么需要工具

我們來看下工具的定義：它原指工作時所需用的器具，后引申為為達到、完成或促進某一事物的手段。（---來自百度的解釋）?

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	不支持	支持
網速模擬	不支持	支持
擴展性	開源，可根據需求修改源碼	通過擴展函數庫實現
學習成本	主要是自學官網上的資料	網上資料和相關培訓很多，購買正版的話，還有技術支持