性能测试之JMeter断言

导读
介绍响应断言的用法
请求重定向的问题
1、从浏览器登录Redmine
（1）从浏览器登录Redmine，使用正确的用户名、密码登录，登录完成后，右上角显示登录账号的名称，如下图所示： 

（2）使用错误的用户名、密码登录，会提示登录失败，然后右上角还是登录按钮，如下图所示： 

上面这个现象很正常，符合我们的预期。

2、使用JMeter发送请求
（1）正确的用户名、密码 
之前发送的请求都是使用正确的用户名、密码，能够请求成功。

（2）错误的用户名、密码 
发送请求，仍然会提示成功，额，什么原因呢？ 
 
默认情况下，JMeter会将响应码是200的默认为请求发送成功，没错，这个请求确实送达了服务器，服务器也给了响应，只不过告诉你“用户名或密码错误”。由于我们是要对登录功能进行压测，假如1000个人并发登录，只有100个人能正常登录，其余900个人登录失败，这肯定不是我们要的结果。所以在这个场景下，只有登录成功，才能算压测成功。这时候就需要给响应结果加个断言（检查点）了。

3、JMeter断言
（1）给JMeter登录请求添加一个断言（Response Assertion） 

（2）Response Assertion页面 

Name名称：随意设置，就是这个断言的名字；
comments注释：描述性文字，可以为空；
Apply to：应用范围，有4个选项 
Main sample and sub-samples：匹配当前父取样器及其子取样器
Main sample only：匹配当前父取样器；
Sub-sample only：仅匹配子取样器；
JMeter Variable Name to use：支持对JMeter变量值进行匹配
Field to Test：要测试的区域，9个选项 
Text Response：服务器返回响应的文本内容，HTTP协议排除Header部分；
Response Code：响应的状态码，200，404等
Response Message：响应的message，“OK”等
Response Headers：响应的Headers；
Request Headers：请求的Headers；
URL Sample：匹配URL链接
Document（text）：对文档内容进行匹配，查看结果树，响应数据标签内容
Ignore Status：一个请求有多个响应断言，假如第一个断言选中此项，当第一个断言失败时，忽略，继续下一个断言（有什么用？？？）
Request Data：请求数据
Pattern Maching Rules：模式匹配规则，4个选项 
Contains：上面要测试的区域包含要匹配的内容，则成功，支持正则
Maches：被测区域要完全匹配需要匹配的内容，则成功，大小写不敏感，支持正则
Equals：被测区域要完全等于需要匹配的内容，则成功，大写小敏感，需要匹配的是字符串，不是正则
Substring：被测区域要包含需要匹配的内容，则成功，大小写敏感，需要匹配的字符串而不是正则
Not：配合前面的选项使用，比如配合Contains使用，就是不包含
Or：或
Pattern to Test：要匹配的字符串或者正则，可以填多个，如果不选Or，就是都要匹配，如果选Or，就是匹配其中一个就算成功
Custom failure message：自定义匹配失败时候的信息。

（3）添加登录请求的断言 

这里我们使用断言“如果没有匹配到无效的用户名字样”就说明登录成功了。

（4）使用错误的用户名、密码登录，看看结果 

可以看到，确实登录请求失败了，提示信息，就是我们前面自定义的信息。

（5）使用正确的用户名、密码登录试试 
请求没有报错

4、换个断言
（1）换个断言 
前面我们断言登录成功，是通过，其检查没有登录失败的提示信息来做检查点，这个有点怪怪的。一般来说，我们断言登录成功，会使用检查页面是否显示登录名来做断言。好，我们替换一下断言试试。 

我们断言响应中应该包含user1（登录用户名），发送请求试试 
 
很不幸，失败了，赶紧来看看登录请求的响应中是否包含user1 

我擦，一搜索，果然不包括user1，这和我们从页面上看到的不一样啊，什么鬼？

（2）抓包看看

打开Chrome浏览器；右键，检查，（或者按Ctrl + Shift + I）打开开发者工具
切换到Network标签
打开Redmine登录页，http://192.168.132.134:8080/redmine/login
点击clear，先清除一下多于的信息
输入用户名密码，点击登录按钮，登录Redmine
查看截获到的请求如下图所示： 

可以看到login本身这个请求，返回码是302，302是什么？重定向，重定向到了哪里？下面一个请求，重定向到了http://192.168.132.134:8080/redmine/ 
在来分别看看两个请求，发现第一个请求的响应确实没有user1的信息，而哪个重定向的请求响应才有user1的信息，如下图所示： 

问题应该是找到了，Badbody只录制到了登录请求本身，但是重定向的请求并没有录制到，所以回放的时候自然没有回放这个重定向的请求，那么页面响应自然也拿不到。

（3）修改JMeter脚本 
将登录请求，修改为“跟随重定向”，如下图所示： 

（4）回放脚本试试 

成功了！完美，看看登录请求有两个子请求，一个是登录本身，一个是重定向请求，在重定向请求的响应中，能看到usr1的信息。

小结
JMeter提供的断言种类很多，本节我们只介绍了响应断言的用法，其它的我们后续介绍。只靠JMeter来检查响应码是不能完全判定请求成功的，还需要我们给请求加上适当的断言。