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 to
any other manager so use multiple Cookie Managers with care.

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

2、HTTP Cookie管理器界面详解

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

HTTP Cookie管理器界面如下:

『动善时』JMeter基础 — 20、JMeter配置元件【HTTP Cookie管理器】详细介绍-LMLPHP

界面详细说明

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

(1)Options选项

  1. Clear cookies each iteration:如果勾选Clear cookies each iteration?(每次反复清除Cookies?)此项,意味着线程在每次请求结束后,都会将本次请求产生的Cookie进行清除,下次请求时重新获取。
  2. Cookie Policy:选择Cookie的管理策略。建议选择StandardStandard 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_开头。

2)手动存储:

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

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

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

手动存储Cookies示例

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

如下图所示:

『动善时』JMeter基础 — 20、JMeter配置元件【HTTP Cookie管理器】详细介绍-LMLPHP

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

如下图所示:

『动善时』JMeter基础 — 20、JMeter配置元件【HTTP Cookie管理器】详细介绍-LMLPHP

(2)Cookie的管理策略

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