1. 準備工作
1.1 場景預設
之前的測試中單獨抽離出了一個注冊登入的場景，而實際的電商場景中，絕大多數都是已經登入并保持登入狀态的，使用者的登入資訊可能被儲存在浏覽器的 cookie 中或在 App 的 localstorage 中，更多的是拿到現有的 cookie 去做驗證;
是以這裡在預設使用者登入狀态下抽離出一個典型的電商場景，浏覽首頁-添加商品-下單結算，涉及到的接口如下：
1）浏覽首頁
2）增加浏覽記錄(自動觸發)
3）添加商品/購物車
4）下訂單/結算
1.2 Token 資料準備
在此次示範場景中，是擷取 token 值帶入 header 中的 Authorization 以完成使用者身份的驗證，借用之前建立的注冊登入腳本，擷取到了很多使用者 token 值儲存在了本地以供測試使用：
2. 腳本編寫
2.1 浏覽首頁
2.1 浏覽首頁
1）設定請求頭的全局變量——HTTP Header Manager
由于每個請求都需要在 header 中帶入 token ，是以我們借用 HTTP Header Manager 來完成一個全局變量的設定。
2）token資料的參數化擷取——CSV Data set Config
利用 CSV Data set Config,擷取提前在 TokenFile 準備好的 token 值，傳給變量 ${auth}。
3）事務抽離——Transaction Controller
根據場景，我們可将不同的事務進行抽離合并，以友善我們後續的資料檢視，這裡可以事務控制器 Transaction Controller 将首頁的事務單獨抽離在一起。
4）控制首頁接口比例——Loop Controller
首頁中有很多商品分類，這裡假設通路一次首頁後會通路兩次商品分類清單，那麼利用 Loop Controller 來控制在它裡面的商品分類清單請求 /home/productCateList/{parentId} 會被請求兩次：
5）這裡可以看到商品分類接口需要傳入參數 parentId：
通常不太建議在壓測腳本中使用 同一個 id 去通路，一來是容易命中緩存，即使沒有 Redis 緩存， MySQL 對于同樣的請求也會有加載上的優化，這樣就會對測試資料與真實場景造成誤差。是以這裡我們還是選擇提前将分類 id 擷取，通過 CSV Data set Config 傳入。
檢視資料庫，不同的分級有多種分類資訊
去重後擷取所有的 parent_id ：
将parentId儲存檔案中并設定CSV：
$ cat parentId_Data
1
12
2
3
4
5
tp=webp&wxfrom=5&wx_lazy=1&wx_co=1)
6）擷取推薦商品設定和首頁的通路量一緻：
7）控制首頁分類專題接口比例——if Controller
這裡我們設定的場景為通路專題的使用者量為首頁的一半，那麼利用 if Controller 寫方法定義，使請求數量不能被2整數的時候再執行請求，這樣就可以保證請求數減半，具體如下：
關于/home/subjectList利用 CSV Data set Config 做參數化的方式和上述分類資訊接口一緻，這裡就不再贅述：
關于 if Controller 中函數的說明
上述的函數生成可以利用JMeter自帶的函數助手（ Tools->Function Helper Dialog ）中的 __jexl3 函數或 __groovy 函數，對判斷條件的表達式進行求值計算，生成對應的求值運算函數，然後将此運算函數複制到 If Controller 的 Expression 輸入框中即可：
例如本例中我們需要先擷取使用者請求的數量，可以先在 Function Helper 中選中 __counter ，設定為true，點選 Generate & Copy to clipbord 生成函數式
複制函數式，再次選中 __jexl3 ，然後設定生成counter不能整數2時的函數式：
3. 實操示範
腳本的首頁部分已經完成，各個接口的比例按照2:4:2:1的比例安排，然後實際運作檢驗一下效果
先起10個線程運作一次驗證腳本的正确性：
從結果可以看到接口都請求成功并且按照了2:4:2:1的比例
如果持續壓測，也可以在 Grafana 中看到測試資料的顯示：