本文為霍格沃茲測試學院優秀學員課程學習系列筆記，想一起系統進階的同學文末加群交流。

在上一篇文章完成首頁瀏覽壓測任務後，我們開始下單-
支付場景的壓測實踐。

** 1. 分步拆解**

1.1 POST /cart/add

**1.1.1 介面分析

**

在電商購物場景中，最為常見和典型的就是新增購物車了，按照之前選定的介面，來看看新增購物車介面POST /cart/add的情況。

從介面文件中我們可以知道新增購物車需要例如價格、品牌、分類id、商品id、商品sku等資訊，相對還是比較多的，這個時候再到原始碼中分析檢視一下：

**找到新增購物車的實現方法：
**
可以看到首先需要獲取到當前的 Member，再通過 UmsMember 物件來獲取對應的Member 資訊,其中 CurrentMember

再找到getCurrentMember()的實現方法:
從這裡就可以看到它需要獲取一個鑑權資訊去解密，然後獲取當前的Member資訊，也就是我們最開始需要在請求Header中帶入的Authorization:${token}:
最終如果購物車不存在就新增一個購物車，如果購物車已經存在就更新購物車資訊；

1.1.2 介面資料構造

**購物車資料構造注意事項：
**
到這裡，我們看似已經知道了購物車如何新增，呼叫介面傳參隨意插入資料即可，但是要注意的是：

如果我們隨意的插入資料，可能介面會通過，資料也能插入成功，但是很可能會影響其他相關一系列業務的介面；例如我們可能插入了某個sku的商品，而這個商品已經庫存不足了，那麼接下來下單的業務就必然會失敗。因此我們需要新增符合真實邏輯的購物車資料。

通過梳理傳參可以知道了購物車的資料來源於兩張表 pms_sku_stock 和 pms_sku_stock：

在pms_sku_stock表中構建sku資料時，需要注意的是stock數，下單一定要有庫存的概念，Real_stock真實庫存+lock_stock鎖定庫存一定不能大於固定的總庫存值，否則就會下單失敗，這是構造資料的限制。

從原始碼中也可以看到 realStock

**購物車資料構造：
**
現在我們開始構造資料，通過MySQL的join多表查詢，將pms_sku_stock和pms_sku_stock表中涉及到的請求欄位且庫存數大於50的商品都查找出來：

select p1.id, p1.product_category_id, p1.product_sn, p1.brand_name, p1.price, p1.name, p1.pic, p1.sub_title, p2.sku_code, p2.idas product_sku_id, p2.sp1, p2.sp2 from mall.pms_product as p1 join mall.pms_sku_stock as p2 on p1.id = p2.product_idwhere p1.stock >=50 and p2.stock > 50;

將資料儲存：

1.1.3 Jmeter 指令碼編寫

1.1.4 Jmeter 指令碼除錯

經過上面一通分析與操作，還要考實踐來驗證指令碼的正確性：

OK，順利通過了！(其實沒有那麼順利，只是我踩過坑了，在嘗試了各種失敗後將成功的一次展現到了這裡而已~)

在去資料庫中看一下，沒問題，成功插入：

補充說明：除錯過程中出了可以看Jmeter的結果樹中的資料，還可以檢視對應容器的spring.log,進入容器，在目錄/var/logs/下：

1.2 GET ** /cart/list**

GET /cart/list

1.2.1 介面分析

由於日常我們新增完購物車的時候都會去重新整理一下購物車資訊，並且通過cart/list也可以驗證購物車是否新增成功，所以對於/cart/list介面的測試是很有意義的

此介面比較簡單，只是一個get請求來獲取當前使用者的購物車資訊：

1.2.2 Jmeter指令碼編寫

1.3 GET/cart/list/promotion

GET /cart/list/promotion

1.3.1 介面分析

訂單資訊是通過購物車去生成，在生成訂單的同時可能還會涉及到優惠券，積分等資訊，因此在生成訂單的時候需要check一下會員的各種優惠促銷資訊。

此介面也是個比較簡單的get介面：

1.3.2 Jmeter指令碼編寫

1.4 POST／order/generateConfirmOrder

GET /cart/list

1.4.1 介面分析

上述是一個確認訂單的post請求介面，但是從介面文件中看到的是沒有需要傳入的請求引數，具體原因可以來看一下原始碼：
找到對應的方法實現：
通過原始碼可以看到，程式會去回去當前使用者的購物車資訊、地址資訊、優惠券資訊等來計算生成訂單；這也就是為什麼購物車相關介面要放在整個鏈路靠前執行(本例中目前只涉及購物車，未涉及優惠券積分等資訊)。

1.4.2 Jmeter指令碼編寫

1.5 POST／order／generateOrder

1.5.1 介面分析

有介面文件可以看到這是一個傳入購物車資訊然後生成訂單的介面，這裡傳入的有優惠券id，收貨地址，付款型別和積分資訊，檢視部分原始碼如下：
從原始碼中可以看到會先對優惠券和積分的null值進行判斷，而在剛才介紹過當前的場景中不涉及優惠券和積分，因此在介面傳參時我們就不傳入couponId和useIntegration了。

1.5.2 Jmeter 指令碼編寫

執行除錯指令碼，我們發現瞭如下失敗：

我們檢視日誌，發現在OmsPortalOrderServiceImpl.generateOrder方法的第189行報了空指標異常的錯誤：

以此我們找到原始碼的位置處，發現原來是缺少收貨地址資訊：

因此到這裡我們需要新增收貨地址資訊，那就利用相關介面，通過Jmeter去構建我們需要的資料。

1.6 POST/member/address/add

1.6.1 介面分析

按照請求引數填入請求資訊即可。

1.6.2 Jmeter指令碼編寫

因為只是為了構造資料，所以我們單獨線上程組下面建立一個執行緒，其餘的都暫時Disable：

另外，id和MemberId也同樣是通過鑑權資訊獲取到，不需要傳入：

一個使用者生成一個地址資訊即可，所以在鑑權的CSV Data中將迴圈設為false

除錯驗證指令碼通過，創造執行緒構造資料即可：

1.7 獲取 memberReceiveAddressID

在確認訂單的介面返回值中，我們可以看到 memberReceiveAddress``Id

這樣的話直接通過JSON Extractor獲取即可：
下單成功：

1.8 POST／order ／paySuccess

訂單總算是完成了，到了最後一步支付了。

1.8.1 介面分析

**
**

從介面文件中可以看到支付介面需要傳入訂單的 orderId，這裡有個坑要注意的是它的引數傳遞是類似get請求形式的在URL後面接引數：

orderId自然是要從確認的訂單返回值中，因此還是老方法，JSON Extractor獲取即可：

1.8.2 Jmeter 指令碼編寫

除錯驗證：

** 2. 階段總結**

到這裡，整個電商模式的典型購物下單場景指令碼已經幾乎完成，整體概覽如下：

上面說幾乎完成，也就是還差一點，我們還需要對實際的發壓場景做最後的調整，因為目前的執行緒數是一次性發起的，沒有一個梯度的概念，而實際的場景中是呈現一種遞增的形式。

所以為了測試的更真實性，我們要藉助外掛來完成需求，具體在下篇文章談 Ultimate Thread Group 外掛的應用。

** _
來霍格沃茲測試開發學社，學習更多軟體測試與測試開發的進階技術，知識點涵蓋web自動化測試 app自動化測試、介面自動化測試、測試框架、效能測試、安全測試、持續整合/持續交付/DevOps，測試左移、測試右移、精準測試、測試平臺開發、測試管理等內容，課程技術涵蓋bash、pytest、junit、selenium、appium、postman、requests、httprunner、jmeter、jenkins、docker、k8s、elk、sonarqube、jacoco、jvm-sandbox等相關技術，全面提升測試開發工程師的技術實力

點選獲取更多資訊