1、jmeter在測試中的定位
對於測試工具或測試框架，咱們可能會以爲，若是一個工具就能知足全部的測試需求就行了，測試數據生成、自動測試、結果分析、報告產出、日誌回溯等等，所有由一個工具來實現。因而，當了解到jmeter有這麼強大的功能以後，咱們很天然就去研究如何用jmeter來實現上述種種功能。而後通過長時間調研發現，jmeter確實能夠作到，由於jmeter有各類控制器、取樣器、斷言、監聽器，甚至還有BeanShell這樣能夠在中間某個環節本身寫代碼來處理一些邏輯的方法。
第一感受，好像確實這些工做都用jmeter來實現就行了，但實際上，這裏的坑卻有很多。舉個最簡單的例子，當咱們用jmeter來處理請求數據、返回數據時，每一個請求至關於會在jmeter這裏增長額外的耗時和資源佔用，若是處理的邏輯比較複雜，好比寫個超級複雜的BeanShell，這些額外的開銷可能會很大程度上影響咱們測試的結果。小編曾經遇到過，爲了實現一個對返回結果進行判斷和分類的功能，致使測試獲得的接口QPS比以前降低了不少，雖然最後實現了將返回結果進行自動化分析、歸類等操做，但最重要的性能指標卻出現了誤差，還得返工再測，得不償失。
因此，在這裏，咱們須要明確下jmeter在測試中的定位，小編認爲，jmeter最重要的功能是實現自動化併發測試+日誌收集，而並不是是用來作數據處理和統計的。在jmeter接口測試的腳本中，若是存在不少的與請求無關的邏輯處理，在這裏強烈建議你們對腳本進行精簡，避免出現問題。
web
2、jmeter線程組的使用
利用jmeter的線程組，咱們能夠很方便地對接口進行併發測試，不管是性能測試仍是穩定性測試，咱們均可以用線程組來實現。jmeter一個測試計劃中能夠添加多個線程組，每一個線程組均可以獨立起若干個線程進行測試。因而有時咱們會在測某個服務時，把該服務的全部接口分紅不一樣線程組放到測試計劃下，指望實現「一個腳本測全部」。但每每這樣作又會產生一些意想不到的問題。小編在實際測試中就遇到過相似定時器跨線程組使用的時間問題，多個線程組共享變量致使的問題、多個線程組的啓停問題等等，給測試帶了比較大的困擾，雖然每次能夠找到解決方法，但這樣頻繁踩坑也着實不爽。
爲了不麻煩，後來我逐漸換了一種設計腳本的方式，那就是儘可能在一個腳本中只使用一個線程組，不一樣的接口，若是互不關聯，就分紅不一樣的腳原本進行測試。這樣看似增長了腳本的數量，但實際上卻大大優化了設計、修改腳本以及執行測試的效率和自由度。測試時，每一個接口的測試都是單獨的進程，彼此之間不會產生影響，且能夠作到每一個接口的測試隨起隨停，在NO-GUI模式下操做起來很是方便。
centos
一個極簡的jmeter腳本，只需一個線程組、一個請求微信
3、使用NO-GUI模式進行測試
jmeter支持使用GUI和NO-GUI兩種模式進行測試，這兩種模式的各有特色。在GUI模式下，咱們能夠經過圖形化界面直觀地進行測試腳本的設計以及經過監聽器實時觀察測試結果，使用起來十分方便；而NO-GUI模式與GUI模式執行測試腳本的方式是相同的，但因爲不顯示圖形界面，也不實時打印測試結果，使得測試中jmeter自己對資源佔用的影響降到最低，在併發測試中能夠很大程度得減小對性能結果的干擾。在公司環境中，性能好的機器通常都使用centos等linux操做系統，幾乎不會用到圖形界面，加之爲了得到更準確的測試結果，在進行大併發測試時，咱們通常會採用NO-GUI模式進行測試。
因此，在腳本設計階段，咱們依然能夠在PC上使用GUI模式進行設計，發揮圖形化設計的優點。當腳本設計完成後，咱們只需將腳本放到linux機器上，而後用NO-GUI模式執行，以最大程度保證得到更準確的測試結果。測試完成後，若是須要在GUI模式下查看測試結果或圖表信息，將NO-GUI模式下產生的日誌文件在GUI模式下導入便可。
併發
小結app
有任何想說的話，均可以發送內容到「搜狗測試」公衆號，咱們一塊兒聊聊~編輯器
歡迎添加咱們的搜狗測試微信號，與咱們一塊兒聊聊測試。工具
本文分享自微信公衆號 - 搜狗測試（SogouQA）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。性能