事情的起因是最近收到的一批測試需求，要測試公司HR系統的接口性能。這個是需要測試的接口列表：

所有的接口請求，都基於登錄驗證成功，否則將無法獲得正確的應答。

首先想到的是在瀏覽器上捕捉請求。打開Chrome瀏覽器，調出開發者工具欄，在地址欄輸入登錄模塊的地址，訪問登錄頁面：

輸入賬號和密碼，錄制登錄過程；然後定位到開發工具的Network頁面，找到登錄的事務。如下圖：

註意右下方的Form Data，這是登錄POST方法提交的三個參數，我們需要捕捉的就是_csrf的那個動態令牌。

通過在網上的一番查找和本地實驗，成功的完成腳本的調試。

以下是整個過程：

首先啟動Jmeter UI，新建一個線程組；然後添加一個HTTP請求，取名UserLogin – Open，意在獲得首次打開登錄頁面的CSRF Token。

方法使用GET，而實際的登錄提交將為POST；這裏並不是實際登錄，不用在意。

這裏一定要勾選【跟隨重定向】，包括之後創建的HTTP請求，都勾選此選項。

請求參數部分，填寫用戶名和密碼。由於現在還不能獲取CSRF Token，此時登錄並不會成功，但目的不在於登錄，而在獲得CSRF Token的內容。

完成後，創建一個【後置處理器 - 正則表達式提取器】，這裏抽取登錄頁面響應報文中的CSRF Token。內容如下圖：

Apply to選項：選中僅應用於主Sample。

這裏需要註意的是“要檢查的響應字段”，在網上查到的指導都是“消息頭”，但在本人的測試中，從消息頭中未能獲取CSRF Token的信息；因此要設置在“主體”。

引用名稱：可以隨便寫；

正則表達式：也就是希望提取的內容，格式需要從應答報文中去找。這裏可以參考LoadRunner的關聯的寫法（左邊際、右邊際、正則表達式匹配的規則）。

實在沒有頭緒的朋友，可以從【察看結果樹】的應答報文中找到，如下圖：

模版：$1$，表示取第一次的值；也只有一個；

缺省值：隨意，默認為空。

接下來，再創建一個HTTP請求，這次是實現真正的登錄請求。

創建第二個HTTP請求，取名UserLogin – POST；因為登錄的方法為POST，和前一個進行區分：

這次需要把登錄提交的三個參數都填上，CSRF Token需要引用上一步從【正則表達式提取器中獲取】的，寫法是： ${token} 。

完成後，理論上我們就可以運行登錄的腳本了；但是別急，還需要添加一個HTTP Cookie管理器。

我們先看看沒有HTTP Cookie管理器的情況：

兩處CSRF Token內容不一致，說明被當成兩次不相關的訪問。

再看看第二個HTTP請求提交的信息，此處的CSRF Token的內容已經和第一個應答報文一樣了，說明我們前面的努力是正確的；可是為何還是沒有登陸成功呢？

稍微想一想就能理解了，服務器端判斷兩次請求是否來自同一個客戶端，不止一個CSRF Token，還有別的，比如會話ID。

我們翻回瀏覽器的開發者工具的頁面看看：

Cookie中顯然有三個參數，可以預料每次提交的請求，這三個參數都是動態取值；

而要保持會話過程中始終一致，我們需要在JMeter腳本裏添加HTTP Cookie管理器：

添加以後也不需要設置什麽項目，保持最初狀態就夠用了。

補充一下，為了確保HTTP Cookie管理器生效，需要修改jmeter\bin目錄下的jmeter.properties。

找到選項CookieManager.save.cookies，將值修改為true，並刪除句首的 # 號，讓配置生效。

完成修改後，需要重啟JMeter。

重啟之後，我們再執行一次看看結果：

對比前一次的執行結果，UserLogin – POST的響應數據發生了變化，顯示的標題是【我的工作臺】，這是登錄成功的重要標誌；

而且兩次HTTP請求獲得的CSRF Token內容相同，登錄操作完美成功。

後面就是添加其他業務API 的請求了，由於都是GET方式，很容易完成腳本的編寫。

完成後，添加聚合報告和監控的Backend Listener就齊活了。

比如，我們查看一下這個用戶的考勤記錄：

執行一遍看看響應報文：

和期望的一樣，登錄之後，再訪問其他功能的API 也能獲得正確的應答。

腳本編寫工作基本完成了。

利用Jmeter測試CSRF令牌驗證的Web API