本文為霍格沃茲測試學院優秀學員課程學習系列筆記，希望大家可以在這裡學到想了解知識。
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
在確認訂單的接口返回值中，我們可以看到 memberReceiveAddressId
這樣的話直接通過JSON Extractor獲取即可：
下單成功：
1.8 POST／order ／paySuccess
訂單總算是完成了，到了最後一步支付了。
1.8.1 接口分析
從接口文檔中可以看到支付接口需要傳入訂單的orderId，這裡有個坑要注意的是它的參數傳遞是類似get請求形式的在URL後面接參數：
orderId自然是要從確認的訂單返回值中，因此還是老方法，JSON Extractor獲取即可：
1.8.2 Jmeter 腳本編寫
調試驗證：
2. 階段總結
到這裡，整個電商模式的典型購物下單場景腳本已經幾乎完成，整體概覽如下：
上面說幾乎完成，也就是還差一點，我們還需要對實際的發壓場景做最後的調整，因為目前的線程數是一次性發起的，沒有一個梯度的概念，而實際的場景中是呈現一種遞增的形式。
所以為了測試的更真實性，我們要藉助插件來完成需求，具體在下篇文章談 Ultimate Thread Group 插件的應用。