本文共 4944 字，大约阅读时间需要 16 分钟。

1、HTTP Cookie管理器介绍

在接口测试中，某些接口的调用，需要带入已有Cookie，比如有些接口需要登陆后才能访问。

JMeter接口请求中使用Cookie有如下两种方式：

1. 直接在HTTP信息头管理器组件中添加Cookie头域信息，适用于已经知道请求所用Cookie数据的情况。
2. 使用JMeter的Cookie管理机制，既可以手动添加，同时JMeter也会将操作流程中获取的参数自动保存，因此可以通过调用前置接口来完成Cookie获取。

官方提示：

If there is more than one Cookie Manager in the scope of a Sampler,there is currently no way tospecify which one is to be used.Also. a cookie stored in one cookie manager is not available toany other manager so use multiple Cookie Managers with care.

如果一个取样器范围内不止一个Cookie管理器，则当前无法指定要使用哪个Cookie管理器。 另外存储在一个Cookie管理器中的Cookie信息，与其他任何Cookie管理器之间均不能相互引用，因此请谨慎使用多个Cookie管理器。

2、HTTP Cookie管理器界面详解

添加HTTP Cookie管理器组件的操作：选中“线程组”右键 —> 添加 —> 配置元件 —> HTTP Cookie管理器。

HTTP Cookie管理器界面如下：

界面详细说明：

• 名称：HTTP Cookie管理器自定义名称，见名知意最好。
• 注释：即添加一些备注信息，对该HTTP Cookie管理器的简短说明，以便后期回顾时查看。

（1）Options选项：

1. Clear cookies each iteration：如果勾选Clear cookies each iteration？（每次反复清除Cookies？）此项，意味着线程在每次请求结束后，都会将本次请求产生的Cookie进行清除，下次请求时重新获取。
2. Cookie Policy：选择Cookie的管理策略。建议选择Standard或Standard strict。这两种策略兼容性设计要求是适应尽可能多的不同的服务器，也就是兼容性更好。

（2）存储在Cookie管理器中的Cookie（User-Defined Cookies） ：

1. Name：Cookies包含对值的name。
2. Value：Cookies包含对值的value。
3. Domain：接收HTTP请求的服务器的域名。
4. Path：路径，地址URI，就相当于定义哪个路径下，以及子路径可以使用这个Cookie。
5. Secure：安全性，默认不勾选为false。
6. Add：新增一条Cookie。
7. Delete：删除选中的Cookie。
8. Load：从本地目录加载已有的Cookie。
9. Save：手动添加的Cookie存储到本地目录。

3、JMeter中对Cookie的管理

在使用Cookie管理器时，没有选择对应的策略 会导致Cookie传递不了

HTTP Cookie管理器的作用：用于管理测试计划运行时的所有的Cookie。

（1）Cookie的存储

JMeter中对Cookie的管理，可以自动存储是，也可以手动存储。

1）自动存储：

• Cookie管理器会自动记录每一个请求所产生的Cookie，在后边对同源站点进行的请求中，都可以使用对应的Cookie进行发送，每个Cookie都有自己的存储区域。每一个cookie是完全独立的，即当遇到非同源站点时请求所带的cookie将不一样。
• Cookie管理器的行为与浏览器中存储和发送Cookie的行为是一致的。
• 注意：JMeter中这种自动收集的Cookie不会在Cookie管理器中进行展示，但是运行后通过查看结果树可以查看到Cookie信息，接受到的Cookie会被自动存储在线程变量中，在2.3.2版本之后不再存储，如果你想要Cookie管理器自动存储收集到 的cookie，你需要修改JMeter.property文件。

保存Cookie数据到线程变量中：

修改jmeter/bin/jmeter.properties文件。

CookieManager.save.cookies=true   # 取消注释，false修改成true

默认线程中变量名为COOKIE_ + Cookie名。

JMeter.property文件中的CookieManager.name.prefix= 属性，能够用来修改默认的COOKIE_开头。

提示：默认情况下，空值的Cookie会被忽略。可以通过设置 JMeter 属性来更改此设置 CookieManager.delete_null_cookies = false 。

2）手动存储：

手动添加的Cookie具有全局性，会在发送请求时自动附加到所有的请求中，即被所有的请求所共享。

手动添加Cookie的方式有两种：

1. 在Cookie管理器组件界面中一个一个的添加；
2. 直接利用浏览器的插件（如火狐的firebug）导出。然后通过load按钮将Cookie进行导入。使用Firefox的firebug插件导出的Cookie信息，和JMeter中配置的Cookie样式几乎同样。

提示：自定义 Cookie 的过期时间会很长。

手动存储Cookies示例：

比较简单的做法是使用Firefox的firebug插件导出Cookies信息。

如下图所示：

然后，在把Cookies数据文件导入到JMeter的HTTP Cookie管理器组件中。

如下图所示：

（2）Cookie的管理策略

1. Standard策略：默认使用，选择Standard或Standard strict。这种策略兼容性设计要求是适应尽可能多的不同的服务器，也就是兼容性更好。
2. RFC2109策略：RFC2109是W3C组织第一次推出的官方Cookies标准。理论上，所有使用版本1-Cookies的服务端都应该使用此标准。HttpClient已经将此标准设定为默认。遗憾的是，许多服务端不正确的实现了标准或者仍然使用Netscape标准。所有有时感到此标准太多于严格。
   RFC2109是HttpClient使用的默认Cookies协议。
   总结：RFC2109为官方HTTP状态管理规范，并被RFC 2965取代的老版本，即过时的严格策略。
3. RFC2965策略：RFC2965定义了版本2并且尝试去弥补在版本1中Cookie的RFC2109标准的缺点。RFC2965是，并规定RFC2965最终取代RFC2109。
   总结：RFC2965为官方HTTP状态管理规范。
4. Netscape策略：Netscape是最原始的Cookies规范，同时也是RFC2109的基础。尽管如此，还是在很多重要的方面与RFC2109不同，可能需要特定服务器才可以兼容。
5. Browser Compatibility策略：这种兼容性设计要求是适应尽可能多的不同的服务器，尽管不是完全按照标准来实现的。如果你遇到了解析Cookie的问题，你就可能要用到这一个规范。
   有太多的web站点是用CGI脚本去实现的，而导致只有将所有的Cookies都放入Request header才可以正常的工作。这种情况下最好设置http.protocol.single-cookie-header参数为true。
   总结：这是一个浏览器兼容性的策略。
6. Ignore Cookies策略：此规格忽略所有Cookie 。被用来防止HttpClient接受和发送的Cookie。
7. best-match策略：最佳匹配Meta（元）策略。Meta（元）Cookie规范采用了一些基于又HTTP响应发送的Cookie格式的Cookie策略。它基本上聚合了以上所有的实现到以一个类中。

概括总结：

• Cookie Policy：Cookie策略，从JMeter3.0开始默认是Standard，具体是跟服务器端的实现方式有关的，各公司可能不一样，我试用了其它的几个选项都获取不到Cookie，只有Netscape策略才能获取到。所以当你获取Cookie有问题时，也可以检查一下这个选项。
• 存储在Cookie管理器中的Cookie：在这里可以添加用户自定义的Cookie，并且会被作用域内的所有线程共享。

4、补充：Cookie的属性介绍

Cookie的主要属性如下：

• name：唯一的Cookie名称。通常来讲Cookie的名称是不区分大小写的。
• value：Cookie变量的值，最好为Cookie的name和value属性进行URL编码。
• Domain：Domain属性指定浏览器发出 HTTP 请求时，哪些域名要附带这个 Cookie，也就是Cookie的有效区域，该区域发送的请求中都会包含这个Cookie信息。
  如果没有指定该属性，浏览器会默认将其设为当前 URL 的一级域名，比如www.example.com会设为example.com，而且以后如果访问example.com的任何子域名，HTTP 请求也会带上这个 Cookie。如果服务器在Set-Cookie字段指定的域名，不属于当前域名，浏览器会拒绝这个 Cookie。
• Path：Path属性指定浏览器发出 HTTP 请求时，哪些路径要附带这个 Cookie。只要浏览器发现，Path属性是 HTTP 请求路径的开头一部分，就会在头信息里面带上这个 Cookie。比如，PATH属性是/，那么请求/docs路径也会包含该 Cookie。当然，前提是域名必须一致。
• Expires：Expires属性指定一个Cookie具体的到期时间，到了指定时间以后，浏览器就不再保留这个 Cookie。它的值是 UTC 格式，可以使用Date.prototype.toUTCString()进行格式转换。
  如果不设置该属性，或者设为null，Cookie 只在当前会话（Session）有效，浏览器窗口一旦关闭，当前 Session 结束，该 Cookie 就会被删除。
  另外，浏览器根据本地时间，决定 Cookie 是否过期，由于本地时间是不精确的，所以没有办法保证 Cookie 一定会在服务器指定的时间过期（会存在偏差）。
• Max-Age：Max-Age属性指定从现在开始 Cookie 存在的秒数，比如60 * 60 * 24 * 365（即一年）。过了这个时间以后，浏览器就不再保留这个 Cookie。
  如果同时指定了Expires和Max-Age，那么Max-Age的值将优先生效。
  如果Set-Cookie字段没有指定Expires或Max-Age属性，那么这个 Cookie 就是 Session Cookie，即它只在本次对话存在，一旦用户关闭浏览器，浏览器就不会再保留这个 Cookie。
• secure：安全标识。它是一个布尔值，指定在网络上如何传输Cookie。
  Cookie默认是不安全的，是通过一个普通的HTTP连接传输。
  指定secure标识为True后，只有在使用SSL链接时候才能发送到服务器，如果是HTTP链接则不会传递该信息。就算设置了secure 属性也并不代表他人不能看到你机器本地保存的 Cookie 信息，所以不要把重要信息存放入Cookie 中就对了。
• HttpOnly：告知浏览器不允许通过脚本document.cookie去更改这个值，同样这个值在document.cookie中也不可见。但在HTTP请求中仍然会携带这个cookie。注意这个值虽然在脚本中不可获取，但仍然在浏览器安装目录中以文件形式存在。（这项设置通常在服务器端设置）

提示：其中name和value属性是必选项，其它属性都是可选项。

参考：

转载地址：http://kglzk.baihongyu.com/