1、HTTP Cookie管理器介绍
在接口测试中,某些接口的调用,需要带入已有Cookie,比如有些接口需要登陆后才能访问。
JMeter接口请求中使用Cookie有如下两种方式:
- 直接在HTTP信息头管理器组件中添加Cookie头域信息,适用于已经知道请求所用Cookie数据的情况。
- 使用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管理器界面如下:
界面详细说明:
- 名称:HTTP Cookie管理器自定义名称,见名知意最好。
- 注释:即添加一些备注信息,对该HTTP Cookie管理器的简短说明,以便后期回顾时查看。
(1)Options选项:
-
Clear cookies each iteration
:如果勾选Clear cookies each iteration?
(每次反复清除Cookies?)此项,意味着线程在每次请求结束后,都会将本次请求产生的Cookie进行清除,下次请求时重新获取。 -
Cookie Policy
:选择Cookie的管理策略。建议选择Standard
或Standard strict
。这两种策略兼容性设计要求是适应尽可能多的不同的服务器,也就是兼容性更好。
(2)存储在Cookie管理器中的Cookie(User-Defined Cookies) :
-
Name
:Cookies包含对值的name。 -
Value
:Cookies包含对值的value。 -
Domain
:接收HTTP请求的服务器的域名。 -
Path
:路径,地址URI,就相当于定义哪个路径下,以及子路径可以使用这个Cookie。 -
Secure
:安全性,默认不勾选为false。 -
Add
:新增一条Cookie。 -
Delete
:删除选中的Cookie。 -
Load
:从本地目录加载已有的Cookie。 -
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的方式有两种:
- 在Cookie管理器组件界面中一个一个的添加;
- 直接利用浏览器的插件(如火狐的
firebug
)导出。然后通过load
按钮将Cookie进行导入。使用Firefox的firebug
插件导出的Cookie信息,和JMeter中配置的Cookie样式几乎同样。
提示:自定义 Cookie 的过期时间会很长。
手动存储Cookies示例:
比较简单的做法是使用Firefox
的firebug
插件导出Cookies信息。
如下图所示:
然后,在把Cookies数据文件导入到JMeter的HTTP Cookie管理器组件中。
如下图所示:
(2)Cookie的管理策略
-
Standard
策略:默认使用,选择Standard
或Standard strict
。这种策略兼容性设计要求是适应尽可能多的不同的服务器,也就是兼容性更好。 -
RFC2109
策略:RFC2109
是W3C组织第一次推出的官方Cookies标准。理论上,所有使用版本1-Cookies
的服务端都应该使用此标准。HttpClient已经将此标准设定为默认。遗憾的是,许多服务端不正确的实现了标准或者仍然使用Netscape
标准。所有有时感到此标准太多于严格。RFC2109
是HttpClient使用的默认Cookies协议。
总结:RFC2109
为官方HTTP状态管理规范,并被RFC 2965
取代的老版本,即过时的严格策略。 -
RFC2965
策略:RFC2965
定义了版本2并且尝试去弥补在版本1中Cookie的RFC2109
标准的缺点。RFC2965
是,并规定RFC2965
最终取代RFC2109
。
总结:RFC2965
为官方HTTP状态管理规范。 -
Netscape
策略:Netscape
是最原始的Cookies规范,同时也是RFC2109
的基础。尽管如此,还是在很多重要的方面与RFC2109
不同,可能需要特定服务器才可以兼容。 -
Browser Compatibility
策略:这种兼容性设计要求是适应尽可能多的不同的服务器,尽管不是完全按照标准来实现的。如果你遇到了解析Cookie的问题,你就可能要用到这一个规范。
有太多的web站点是用CGI脚本去实现的,而导致只有将所有的Cookies都放入Request header
才可以正常的工作。这种情况下最好设置http.protocol.single-cookie-header
参数为true。
总结:这是一个浏览器兼容性的策略。 -
Ignore Cookies
策略:此规格忽略所有Cookie 。被用来防止HttpClient接受和发送的Cookie。 -
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
属性是必选项,其它属性都是可选项。
参考: