事情的起因是最近收到的一批測試需求，要測試公司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 也能獲得正確的應答。
腳本編寫工作基本完成了。