随着IT技術的飛速發展和企業網際網路+業務規模不斷擴張，IT架構經曆了以資料計算為核心的C/S架構、以聚焦業務功能及服務化建構應用的經典網際網路架構和如今整合IT資源和按需使用的雲計算架構三個階段。
與之同步發展的壓力測試同樣有三個發展階段，從防火牆内的壓力測試到基于雲計算的壓力測試，再到使用者視角的外部壓測，雲智慧的壓測寶就是第三代壓力測試産品。而Apache JMeter作為一款大名鼎鼎的開源壓力測試産品，在設計之初就被用來測試C/S結構的軟體，其實作原理就是在防火牆内部産生壓力來進行壓測，測試目的也僅是對内網的系統硬體資源以及服務、資料庫在内網并發負載下的性能表現。
繼《雲智慧壓測實戰分享之JMeter工具使用初探》和《雲智慧壓測實戰分享之JMeter腳本錄制執行個體》兩篇内容之後，今天雲智慧工程師為您帶來的是《雲智慧壓測實戰分享之JMeter場景設定與監控》，主要包含以下三部分内容：場景設定、場景運作和測試監聽。
場景設定：
測試場景是測試過程中通常盡量模拟真實系統環境及使用者操作而設計的場景，場景設計源于使用者的真實操作，設計原則是貼近于使用者實際操作，組合使用者的各種操作到場景中來。JMeter是通過線程組的設定來完成場景設定的，有些複雜場景還需要與邏輯控制器配合。
JMeter 線程組實際上是建立一個線程池，JMeter根據使用者的設定進行線程池的初始化，及在運作時做各種異常處理。下面我們用一幅圖看一下線程組的一些參數：
名稱：根據實際業務需求，最好有業務含義，與場景相符。
注釋：可以随意設定，可以為空，但是為了以後友善使用，這裡最好寫上有意義的備注，和程式設計裡的注釋的目的是一樣。
在取樣器錯誤後要執行的的動作：就是線程組内某一個請求出錯後的異常處理方式
繼續：某一線程的某一請求出錯後，繼續運作，就是忽略本次錯誤繼續執行；
Start_NextThread loop:進行下一次線程循環，類似于for循環中的continue；
停止線程：當某一線程失敗或報錯後停止本線程，類似于LoadRunner中的停止該Vu；
停止測試：某一線程某一請求失敗後，停止所有線程，也就時停止本次測試，但不時立即停止測試，是在本場景中其他線程執行疊代結束後，停止本次測試；
stop Test Now：馬上停止本次測試，不管其他線程是否執行結束；
線程屬性：
線程數：可以了解為并發使用者數，一個線程對應一個并發使用者；與LoadRunner中的VU一緻，隻是LoadRunner中VU可以是線程，也可以是程序（以Http協定為例）；
Ramp-up period(in second)：線程啟動開始運作的間隔時間，此處機關為秒，即所有線程多長時間内全部啟動，假設線程設定為100（模拟100vu并發），Ramp-up period設定為10秒，那就是10秒内将100個線程啟動，相當于每秒中有10個線程啟動（100/10）；如果設定1，就是場景發起後1秒内全部啟動100個線程。
循環次數：“永遠”就是場景不結束就所有線程一直發起壓測，如果想每個線程疊代多少次之後就停止壓測，就可以填入具體的數字。
Delay Thread creation until needed：選擇該項，線程在Ramp-up period的間隔時間啟動并運作，如100并發線程，10秒的ramp-up period時間，那麼1秒種啟動10個線程并運作采樣器中的請求。如果不勾選，測試計劃啟動所有線程（100個）為new狀态，但不立即運作采樣器（sampler）中的請求，是按照ramp-up period時間來運作的，如100個線程，ramp-up 的時間是10秒，那麼每秒會有10個線程有new狀态轉為Running，并執行采樣器中的請求。實際測試場景設定時，選不選該項都不會影響測試結果。二者的差別是勾選線程是在間隔時間内建立啟動并運作，不勾選是先建立所有線程然後按間隔逐漸執行。
排程器： 選擇排程器可以控制場景執行時間或指定那個時間段執行，如秒殺場景就可以設定為某日某點某分開始執行，某日某點某分結束，具體排程器中各個參數如下：
持續時間：表示腳本持續運作的時間，以秒為機關，例如腳本模拟使用者持續不斷登入1個小時，你可以在文本框中填寫3600。如果在1小時以内，結束時間已經到達，它将會覆寫結束時間，繼續執行。
啟動延遲：表示腳本延遲啟動的時間，在點選啟動後，如果啟動時間已經到達，但是還沒有到啟動延遲的時間，那麼，啟動延遲将會覆寫啟動時間，等到啟動延遲的時間到達後，再運作系統。例如你的測試場景需要再另外一個場景結束後開始，上一個場景需要10分鐘後結束，那麼你可以再啟動延遲中設定601秒，點選啟動，就可以在上一個場景結束後，開始本次測試場景；
啟動時間：表示我們腳本開始啟動的時間，當你不想立即啟動腳本測試，但是啟動腳本的時間不會再電腦旁的時候，你可以設定一個啟動的時間，然後再運作那裡點選啟動，系統将不會立即運作，而是會等到你填寫的時間才開始運作。
結束時間：與啟動時間對應，表示腳本結束運作的時間。
注意：如果我們需要用到排程器來設定持續時間，如果線程數不夠多到持續時間結束，我們就必須将循環次數勾選為永遠，如果線程組裡面有其他的循環，我們也需将該循環次數勾選為永遠。
在雲智慧壓測寶中場景設定就簡單多了，選擇好腳本和測試資料後，設定并發使用者和場景運作時間及壓力發起方式，平行還是坡度，壓測寶能自動計算每秒啟動多少VU并發，如上圖所示。
場景運作：
JMeter的場景運作方式分為兩種，一種是GUI可視化運作,測試者可以實時看到壓測執行過程和壓測結果，像LoadRunner的Controller一樣；另外一種是非GUI模式運作，即通過指令行像執行Shell一樣，在指令視窗運作。
JMeter的場景運作可以在本地運作（即單機運作），也可以是遠端運作，不論是GUI模式還是非GUI模式都支援本地和遠端執行。本機運作類似于LoadRunner中将本機做為Controller同時也作為Agent；遠端執行類似于LoadRunner中将Agent安裝在别的機器上。
通常在需要大壓力的場景下，一台機器産生的壓力不能滿足測試需求，就需要多台壓力機，這時就需要遠端執行，如下圖所示：
GUI運作：GUI方式是可視化，直接通過點選滑鼠就可以控制場景的啟動和停止，同時也能随時檢視場景的運作狀況，實時結果，測試線程數等。
1. 本地運作的所有請求從一台機器發出，如下圖，設定了4個并發線程：
運作的快捷菜單按鈕是：
，本地運作點選
按鈕開始運作，或者通過運作菜單開始運作，如下圖：
場景運作後，我們可以看到下圖中的狀态，時間00:00:01顯示的是目前場景運作的時長，後面感歎号的圖示是目前場景中是否有線程異常，0為沒有線程異常，0/4中前面代表目前運作的線程數，後面的4代表共運作了4個線程。
在場景運作過程中點選，
可以停止目前場景。
遠端執行：
遠端執行通常是在一台機器上的JMeter作為Controller，遠端的多台機器（slave）作為負載生成器，JMeter控制台與負載機的通信是通過RMI方式來完成的。在負載機上運作Agent程式，首先啟動jmeter-server，在JMeter控制機（Master）上點選
啟動遠端控制機。
說到這裡需要補充說明一下，在啟動遠端機之前需要在JMeter控制機上配置jmeter.properties檔案，将遠端負載機IP位址配置到控制台jmeter.properties檔案中；如下圖所示，将遠端負載機的IP位址配置在Remote_hosts=配置項後面，多台機器用逗号間隔，如果沒有制定端口的話，預設不配置端口。
注意：遠端運作方式如果腳本有依賴的參數檔案或Jar包等檔案，需要先把這些檔案拷貝到遠端機負載機上，這點不是很人性化，雲智慧的壓測寶就不存在這樣的問題，隻要把參數傳上就可以了。
非GUI方式運作：
非GUI方式是沒有JMeter圖形化界面，在指令行視窗通過指令來運作場景，之是以用非GUI方式運作，是因為JMeter可視化界面及監聽器動态展示結果都比較消耗負載機的資源，在大并發下GUI方式往往會導緻負載機資源緊張，對性能測試結果造成影響。當然這個影響不是影響被測系統如導緻響應時間變大，處理能力減小等，而是影響負載機負載壓力的産生，如非GUI方式可以産生200TPS的負載，而GUI方式隻能産生140TPS的負載。當然如果資源比較充足的情況下，GUI方式更能直覺實時了解測試場景運作狀況。至于用哪種方式，個人認為根據實際情況選擇，資源不寬裕的情況下選擇非GUI方式，資源充足的情況下可以用GUI方式。
非GUI方式運作指令共兩種方式，如下：
1、 jmeter –n –t /home/jeff/script/jmeter_test.jmx –l /home/jeff/result/test.jtl
2、java –jar /apache-jmeter-3.0/bin/ApacheJMeter.jar –n –t /home/jeff/script/jmeter_test.jmx –l /home/jeff/result/test.jtl
jmeter 非GUI方式下的各種指令行參數這裡不在細說，大家可以根據幫助文檔按圖索骥。
測試監聽：
性能測試監控的主要任務是擷取運作狀态、收集測試結果，測試結果有事務的響應時間、吞吐率、伺服器硬體資源性能（CPU、記憶體、DISK I/O、網絡等）名額及JVM使用情況、資料庫性能狀态等，這些在JMeter中是監聽器負責監聽的工作。
JMeter監聽器比較多，如下圖所示：
長時間執行測試計劃使用的監聽器主要是Summary Report 或者aggregate Graph (聚合報告)，也是今天主要介紹的内容。Summary Report以表格的形式顯示采樣結果，如果不同采樣器（不同請求）使用相同的名字，那麼測試結果在Summary Report中會統計到同一行，是以在給采樣器命名時不要都為空或取相同的名字，根據實際業務進行命名。這個類似于LoadRunner腳本中的事物，如果事物名稱一緻，測試結果中不同腳本相同僚物将被統計到一起，如下圖所示：
Label：每個 JMeter 的 element （例如 HTTP Request ）都有一個 Name 屬性，這裡顯示的就是 Name 屬性的值；
#Samples：表示你這次測試中一共發出了多少個請求，我的測試計劃模拟 10 個使用者，每個使用者疊代 10次，是以這裡顯示 100；
Average：平均響應時間 —— 預設情況下是單個 Request 的平均響應時間，當使用了 Transaction Controller 時，也可以以 Transaction 為機關顯示平均響應時間；
Min： 最小響應時間 在測試場景中采樣器一次請求最小的響應時間；
Max： 最大響應時間 在測試場景中采樣器一次請求最大的響應時間；
Error%： 本次測試中出現錯誤的請求的數量 / 請求的總數；
Throughput： 吞吐量 —— 預設情況下表示每秒完成的請求數（ Request per Second ）RPS或者是TPS。
上面字段基本上已經能夠說明測試結果，當然測試者也可以根據自己需求添加一些需要監控的參數，點選config按鈕，彈出下圖中配置頁面：
提示：儲存的監聽參數越多，對本機和負載機的IO産生的壓力越大，是以并不是參數越多越好，夠用就可以了。
Aggregate Graph(聚合報告)
在Aggregate Report中，會顯示一行資料，共有10個字段，Label、#Samples、Average、Min、Max、Error%的含義和Summary Report一樣，有差異的字段如下：
Median：中位數，也就是 50％ 使用者的響應時間；
90% Line：90％ 使用者的響應時間；
Throughput：吞吐量——預設情況下表示每秒完成的請求數（Request per Second），當使用了 Transaction Controller 時，也可以表示類似 LoadRunner 的TPS[Transaction per Second]；
KB/Sec：每秒從伺服器端接收到的資料量，相當于LoadRunner中的Throughput/Sec；
通過上面的介紹，可以看到Summary Report和Aggregate Graph(聚合報告)類似，隻是 聚合報告更詳細一點。說了這麼多是不是覺得jmeter的監聽器很複雜，是以還是壓測寶更友善，不需要設定什麼監聽器，測試結果直接實時展現，如下圖所示：
好了，今天就分享到這裡，JMeter 還有很多内容，後面有機會再一一介紹，謝謝大家！
轉載于:https://my.oschina.net/cloudwise/blog/815902