這里是清安，基礎篇我們已經講解完了，記得從頭看看，其中也出了部分的實戰操作，滿滿的細節，在作業中或者培訓中都不一定會講到的操作：

Jmeter--【作為測驗你必須要知道的】基礎名詞與環境搭建_清歡無別事-CSDN博客

Jmeter--基礎使用_清歡無別事-CSDN博客jmeter從0-1系列，教你一點點使用jmeter，了解別人不告訴你的細節！https://blog.csdn.net/weixin_52040868/article/details/121755533

Jmeter--【作為測驗你必須知道】實用技巧--實戰篇_清歡無別事-CSDN博客_jmeter測驗實戰滿滿的實用小技巧，不看是損失https://blog.csdn.net/weixin_52040868/article/details/120221158

Jmeter--結合fiddler使用+jmeter斷言_清歡無別事-CSDN博客簡單的斷言，加fildder介紹https://blog.csdn.net/weixin_52040868/article/details/121768556

Jmeter--【作為測驗你必須知道】高級應用--斷言、變數的使用+報告輸出_清歡無別事-CSDN博客_jmeter斷言中使用變數實戰篇，涉及內容不多，很容易看懂https://blog.csdn.net/weixin_52040868/article/details/120265891

目錄

實戰

壓測

壓測任務需求

壓測設定

壓測結果查看

壓測結果的分析

實戰

本章所講的API，可以私信我拿到，開源介面，餓了嗎的，博主也是從GitHub上拿到的，

上教學吧，本章將結合前面所見綜合寫腳本，

首先我們添加一個模塊控制器，這個作用看了前面的操作的朋友應該就懂得，模塊控制器需要搭配測驗片段來使用，此處的腳本也可不用這一方法，因為腳本是你一個人寫的，并非好幾個人，

我們再測驗片段中 添加兩個HTTP請求：

我們先來看看當前城市的事務器中存放了什么：

這里我添加了一個用戶自定義變數，什么作用呢，就是后面介面中只要介面地址有所改動，我直接更改這里就ok了， 不需要進入到每一個請求中一個個更改，

參考的寫法，${變數}，這里還是比較易懂的，這里我們可以做一個斷言，

斷言這里需要說明的是，挑關鍵的斷言，別整很多欄位斷言，如果資料是可變的，那就沒回都需要更改，這里我斷言了name跟id，這兩個對應的，所以我直接加進來了，id我給了一個錯誤的，我們來看看，

這里的提示是自己寫的，在回應斷言的下面有一個自定義提示資訊，不過不建議寫，因為哪里錯了它會自動告訴你是id=12了，

來看看正則，我提取了id，因為下一個介面就是獲取id的城市的資訊，所以我就寫了提取，正好一起做個解釋，你們大可寫其他的id，每個人獲取的id不一樣，你也可以拿到介面檔案把第一個HTTP引數改成獲取熱門城市，

Java請求我是拿來列印獲取內容的，

看好這里的寫法，是把提取的變數id加入了喲，并且下面做了跟上面一樣的回應斷言，

如果在這里需要壓測，提供一下個人思路，添加一個回圈控制器，在下面接入這兩個事務器其中一個，接入幾個添加幾個回圈控制器看需求，然后寫csv檔案讀取，或者隨機值id讀取喲，

我么接著寫，搜索地址，這里我在用戶自定義中新增了一個變數，因為路由變了：

地址隨便寫了一個，主要是用于后面的經緯度，這一介面可以獲取到，

接下來我們根據拿到的經緯度進行詳細的定位，用正則提取出來用于發起請求

下面的請求我用到了JSON斷言，這里用于介紹斷言，跟樓上的斷言自行選擇就好，

這里的提取值跟回應的值對應哦，別搞混了，看看：

提取后還需要添加一個斷言設定，這一項其實在此處就顯的有些繁瑣了，

來看看結果如何是否都能跑通：

對于不同的介面且關系不大的介面，我們可以另起一個模塊來寫，如下，有一個食品分類的介面，跟前面的不搭邊，我們可以另起一個模塊控制器來進行控制：

這里需要注意的是，模塊控制器中必須選中新增的測驗片段，否則無法跑哦：

最后我們再來添加一個介面，查詢經緯度周圍的商家資訊：

上述的limit的是只展示一家商品資訊，

最后我們在把回圈控制器添加上，設定好執行緒數，回圈次數來跑一遍，

執行緒組里執行緒數一百，回圈5次，回圈控制器里面再次回圈5次，來看看結果，

這里的例外率跟定位有一定的關系，定位不準確導致的，我們沒有控制它的吞吐量，有想法的朋友可以自己添加一下，另外這里回圈控制器跟事務控制器調換一下順序我個人覺得更好一些，將回圈控制器寫在事務控制器中來進行回圈控制，

這里樣本數量不正確，是因為我沒跑完就暫停了，

壓測

最后，什么是壓力測驗？

壓力測驗分兩種場景：一種是單場景，壓一個介面的；第二種是混合場景，多個有關聯的介面，壓測時間，一般場景都運行10-15分鐘，如果是疲勞測驗，可以壓一天或一周，根據實際情況來定，

壓測任務需求

壓測前要明確壓測功能和壓測指標，一般需要確定的幾個問題：

1. 固定介面引數進行壓測還是進行介面引數隨機化壓測？
2. 要求支持多少并發數？
3. TPS（每秒鐘處理事務數）目標多少？回應時間要達到多少？
4. 壓服務器名稱還是壓服務器IP，一般都是壓測指定的服務器

壓測設定

執行緒數：并發數量，能跑多少量，具體說是一次存在多少用戶同時訪問
Rame-Up Period(in seconds):表示JMeter每隔多少秒發動并發，理解成準備時長：設定虛擬用戶數需要多長時間全部啟動，如果執行緒數是20，準備時長為10，那么需要10秒鐘啟動20個數量，也就是每秒鐘啟動2個執行緒，
回圈次數：這個設定不會改變并發數，可以延長并發時間，總請求數=執行緒數*回圈次數
調度器：設定壓測的啟動時間、結束時間、持續時間和啟動延遲時間，

壓測結果查看

運行完后，聚合報告會顯示壓測的結果，主要觀察Samples、Average、error、Throughput，

Samples:表示一共發出的請求數
Average：平均回應時間，默認情況下是單個Request的平均回應時間（ms）
Error%:測驗出現的錯誤請求數量百分比，若出現錯誤就要看服務端的日志，配合開發查找定位原因
Throughput:簡稱tps,吞吐量，默認情況下表示每秒處理的請求數，也就是指服務器處理能力，tps越高說明服務器處理能力越好，

壓測結果的分析

有錯誤率同開發確認，確定是否允許錯誤的發生或者錯誤率允許在多大的范圍內；

Throughput吞吐量每秒請求的數大于并發數，則可以慢慢的往上面增加；若在壓測的機器性能很好的情況下，出現吞吐量小于并發數，說明并發數不能再增加了，可以慢慢的往下減，找到最佳的并發數；

壓測結束，·登陸相應的web服務器查看CPU等性能指標，進行資料的分析;

最大的tps:不斷的增加并發數，加到tps達到一定值開始出現下降，那么那個值就是最大的tps，
最大的并發數：最大的并發數和最大的tps是不同的概率，一般不斷增加并發數，達到一個值后，服務器出現請求超時，則可認為該值為最大的并發數，

壓測程序出現性能瓶頸，若壓力機任務管理器查看到的cpu、網路和cpu都正常，未達到90%以上，則可以說明服務器有問題，壓力機沒有問題，

影響性能考慮點包括：資料庫、應用程式、中間件（tomact、Nginx）、網路和作業系統等方面，