事情的起因是最近收到的一批测试需求，要测试公司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 也能获得正确的应答。
脚本编写工作基本完成了。
