接口测试的基础

目录

Cookie

获取 Cookie 的途径

使用浏览器的开发者工具或专业抓包工具获取

从本地文件中获取

通过前端技术获取

Cookie 的生命周期

Cookie 不可跨域名以及跨浏览器使用

Session

Session 的传输媒介

通过 Cookie 传输

URL 地址重写

Session 的生命周期

Token

Token 的原理

JSON Web Token

创建 JWT 的步骤

首次登录

再次登录 

 HTTP 协议

术语

状态码

HTTP 扩展

cache

cookie的运用

session的运用

 Token 的运用

HTTPS

加密算法

对称加密

非对称加密

数字签名

传输过程

 WebSocket

WebSocket 的属性

---

Cookie

获取 Cookie 的途径

使用浏览器的开发者工具或专业抓包工具获取

测试人员对抓包工具应该是相当熟悉的了。不论你使用浏览器（ F12 ），还是专业抓包工具，

能达到目的即可。以 fiddler 抓包工具为例

可以点击“Raw”页直接保存 Cookie 至记事本

Cookie:pgv_pvi=5652430848;pgv_pvid=7416737810;ts_uid=1441173412;noticeLoginFlag=1; 
ua_id=ULnauSmHPx7514RJAAAAAGJZIJOw5KpRZBildRgJVR8=;xid=e4a3147d43bb13054c49316938b9368b; 
openid2ticket_oIpcIuEiT50JLoyUG3UQMVMpAxN0=qqE9Zco4yzKZM/jIJG5K/ksgIKErrOzJ6iQMfIFtVw4=
If-Modified-Since: Sat, 7 Oct 2017 21:26:21 +0800

从本地文件中获取

既然 Cookie 信息被浏览器保存至本地，那么测试人员就可以在本地文件中寻找 Cookie 信息了。

举几个常用浏览器的存放地址。

（ 1 ） IE 浏览器 Cookie 数据位于： %APPDATA%\Microsoft\Windows\Cookies\ 目录中的 xxx.txt

文件（里面可能有很多个 .txt Cookie 文件）。

（ 2 ） Firefox 的 Cookie 数据位于： %APPDATA%\Mozilla\Firefox\Profiles\ 目录中的 xxx.default

目录名为 cookies.sqlite 的文件。

（ 3 ） Chrome 的 Cookie 数据位于： %APPDATA%\Google\Chrome\User Data\Default\ 目录中，

名为 Cookies 的文件。

在 IE 浏览器中， IE 将各个站点的 Cookie 分别保存为一个 XXX.txt 这样的纯文本文件（文件

个数可能很多，但文件容量都较小）。而 Firefox 和 Chrome 是将所有的 Cookie 都保存在一个文

件中（文件容量较大），该文件的格式为 SQLite3 数据库格式的文件。为了查看及运用方便，一

般浏览器都会保存多域名的 Cookie 信息。可以通过使用 Chrome 和 Firefox 浏览器的设置，直观

地拷贝 Cookie 信息。

以 Chrome 浏览器为例。

①进入 Chrome 设置。

②找到【隐私设置】。

③进入【内容设置】。

④在 Cookie 选项中可以查看及搜索所有保存的 Cookie

⑤根据不同的域名查看该域名下具体的 Cookie 内容，例如，要查看微信公众号平台的

Cookie 信息

⑥查看每个 Cookie 项里的具体内容，

从以上截图可以看出 Cookie 里的几个关键信息：名称、内容、域名、路径、创建时间、到期时间。 如上所述，对于 Firefox 浏览器可以选择如下操作

①进入 Firefox 设置。

②找到【工具设置】。

③进入【选项设置】。

④进入【隐私设置】。

⑤显示 Cookie 。

⑥在 Firefox 浏览器的设置中查看 Cookie 的具体信息。

通过前端技术获取

测试人员可以通过前端技术查看某个网站颁发的 Cookie 。

例如，在浏览器地址栏输入

Javascript:alert (document. cookie)

中弹出的对话框中显示的为 Baidu 网站的 Cookie 。可以看到为了信息的安全性， Baidu

使用特殊的方法将 Cookie 信息加密了

Cookie 的生命周期

Cookie 的生存时间是整个会话期间：浏览器会将 Cookie 保存在内存中，浏览器关闭时就

会自动清除这个 Cookie 。

Cookie 的生存时间是长久有效： Cookie 保存在客户端的硬盘中，浏览器关闭的话，该

Cookie 也不会被清除，下次打开浏览器访问对应网站时，这个 Cookie 就会自动再次发送

到服务器端。

测试人员可以通过对浏览器的设置修改 Cookie 的生命周期

除了通过浏览器修改，可以运用开发手段在服务器端的代码层面对 Cookie 的生命周期进行修改。

以下举几个 Cookie 的常用属性，便于测试人员根据测试场景进行修改。

（ 1 ） Name ：该 Cookie 的名称。 Cookie 一旦创建，名称便不可更改。

（ 2 ） Value ：该 Cookie 的值。如果值为 Unicode 字符，需要为字符编码。如果值为二进制数

据，则需要使用 Base64 编码。

  Unicode 编码：保存中文

中文与英文字符不同，中文属于 Unicode 字符，在内存中占 4 个字符，而英文属于 ASCII 字

符，内存中只占 2 个字节。 Cookie 中使用 Unicode 字符时需要对 Unicode 字符进行编码，否则会

乱码。

Base64 编码：保存二进制图片

Cookie 不仅可以使用 ASCII 字符与 Unicode 字符，还可以使用二进制数据。例如，在 Cookie

中使用数字证书，提供安全度。使用二进制数据时需要进行 Base64 编码。

小知识点： Base64 是一种基于 64 个可打印字符来表示二进制数据的表示方法。

（ 3 ） MaxAge ：该 Cookie 失效的时间，单位为秒。如果为正数，则该 Cookie 在 MaxAge 秒之

后失效。如果为负数，该 Cookie 为临时 Cookie ，关闭浏览器即失效，浏览器也不会以任何形式

保存该 Cookie 。如果为 0 ，表示删除该 Cookie 。默认为 −1 。

（ 4 ） Secure ：该 Cookie 是否仅被使用安全协议传输。安全协议有 HTTPS 、 SSL 等，在网络上

传输数据之前先将数据加密。默认为 False 。

（ 5 ） Path ：该 Cookie 的使用路径。如果设置为“ /sessionWeb/ ”，则只有 contextPath 为

“ /sessionWeb ”的程序可以访问该 Cookie 。如果设置为“ / ”，则本域名下 contextPath 都可以访问

该 Cookie 。注意最后一个字符必须为“ / ”。

（ 6 ） Domain ：可以访问该 Cookie 的域名。如果设置为“ .google.com ”，则所有以“ google.com ”

结尾的域名都可以访问该 Cookie 。注意第一个字符必须为“ . ”。

Cookie 不可跨域名以及跨浏览器使用

Cookie 除了不能跨域名使用，也不能跨浏览器使用。大家可能会遇到一种情况，既然 Cookie

不能在不同的浏览器中使用，为什么使用 IE 登录了腾讯网站后，使用 Firefox 能保持登录状态呢？

不同浏览器使用不同的 Cookie 管理机制，无法实现公用 Cookie 。如果使用 IE 登录腾讯网站，使用 Firefox 也能登录，这是由于在安装腾讯 QQ 软件时，你的计算机上同时安装了针对这两个浏览

器的插件，可以识别本地已登录 QQ 号码进而自动登录。本质上，这个现象并不是由 Cookie 造

成的。

Session

Session 是另一种记录用户状态的机制，不同的是 Cookie 保存在客户端浏览器中，而 Session 保存在服务器上

Session 的传输步骤如下。

（ 1 ）服务器端程序运行的过程中创建 Session ，并且为该 Session 生成唯一的 Session ID 。

这个 Session ID 在随后的请求中会被用来重新获得已经创建的 Session 。在 Session 被创建之

后，就可以调用 Session 相关的方法向 Session 中增加内容，这些内容只会保存在服务器中。

（ 2 ）服务器将 Session ID 发到客户端。

（ 3 ）当客户端再次发送请求的时候，会将这个 Session ID 带上。

（ 4 ）服务器接收到请求之后就会依据 Session ID 找到相应的 Session ，完成请求响应。

Session 的传输媒介

通过 Cookie 传输

Session 的信息是保存在服务器端的。测试人员只需要运用抓包工具从 Cookie 中获取 Session

ID 的值用于模拟用户请求。虽然 Session 保存在服务器，对客户端是透明的，但它的正常运行仍

然需要客户端浏览器的支持。这是因为 Session 需要使用 Cookie 作为识别标志。因此服务器向客

户端浏览器发送一个名为 JSESSIONID 的 Cookie ，它的值为该 Session 的 ID 。测试人员获取

JSESSIONID 的值即可.

Session 的有效期与会话有关。存储 JSESSIONID 的 Cookie 是服务器自动生成的，它的 maxAge

属性一般为 −1 ，表示仅当前浏览器内有效，并且各浏览器窗口间不共享，关闭浏览器就会失效，

因此同一机器的两个浏览器窗口访问服务器时，会生成两个不同的 Session ，但是由浏览器窗口内

的链接、脚本等打开的新窗口（不是双击桌面浏览器图标等打开的窗口）使用同一个 Session 。这

类子窗口会共享父窗口的 Cookie ，因此会共享一个 Session 。

注意：新开的浏览器窗口会生成新的 Session ，但子窗口除外。子窗口会共用父窗口的 Session 。例如，在链接上右击，在弹出的快捷菜单中选择“在新窗口中打开”时，子窗 口便可以访问父窗口的 Session 。

那么，如果客户端浏览器将 Cookie 功能禁用，或者不支持 Cookie 怎么办？例如，绝大多数

的手机浏览器都不支持 Cookie 。对于 Session 的传输方法存在另一种解决方案： URL 地址重写。

URL 地址重写

URL 地址重写是对客户端不支持 Cookie 的解决方案。它的原理是将该用户 Session 的 ID 信息重写到 URL 地址中。服务器能够解析重写后的 URL，获取 Session 的 ID。这样即使客户端不 支持 Cookie，也可以使用 Session 来记录用户状态。 服务器代码会先自动判断客户端是否支持 Cookie。如果客户端支持 Cookie，会将 URL 原封 不动地输出。如果客户端不支持 Cookie，则会将用户 Session 的 ID 重写到 URL 中。重写后的输 出可能是这样的。

https://mp.weixin.qq.com/s?jsessionid=ByOK3vjF7C2HmdnV6QZcEbzWoWiBYE-145

用户单击这个链接的时候会把 Session 的 ID 通过 URL 提交到服务器上，服务器通过解析 URL

地址获得 Session 的 ID 。

如果测试人员要构造特殊测试场景，需要获取非 Cookie 传输的 Session ，方法是要找开发人

员帮忙获取 Session ID 或者自行从服务端代码中获取。

Session 的生命周期

除非程序通知服务器删除一个 Session ，否则服务器会一直保留，程

序一般都是在用户做 log off 的时候发个指令去删除 Session 。然而浏览器从来不会主动在关闭之前

通知服务器它将要关闭，因此服务器根本不会有机会知道浏览器已经关闭，之所以会有这种错觉，

是大部分 Session 机制都使用会话 Cookie 来保存 Session ID ，而关闭浏览器后这个 Session ID 就消

失了，再次连接服务器时也就无法找到原来的 Session 。如果服务器设置的 Cookie 被保存到硬盘

上，或者使用模拟发包工具改写浏览器发出的请求头，把原来的 Session ID 发送给服务器，则再

次打开浏览器仍然能够找到原来的 Session 。

关闭浏览器不会导致 Session 被删除，迫使服务器为 Seesion 设置了一个失效时间，当距离客

户端上一次使用 Session 的时间超过这个失效时间时，服务器就可以认为客户端已经停止了活动，

才会把 Session 删除，以节省存储空间。例如， Tomcat 中 Session 的默认超时时间为 20 分钟，可

以通过 setMaxInactiveInterval （ int seconds ）方法修改 Session 的默认超时时间。

cookie和session的区别

1．存储位置不同

通常情况

 Cookie 的数据信息存放在客户端浏览器上。

 Session 的数据信息存放在服务器上。

2．存储容量不同

通常情况

 单个 Cookie 保存的数据≤ 4KB ，一个站点最多保存 20 个 Cookie 。

 对于 Session 并没有上限，但出于对服务器端的性能考虑， Session 内不要存放过多的东西，

并且设置 Session 删除机制。

3．存取方式的不同

 Cookie 中只能保管 ASCII 字符串，需要通过编码的方式存取 Unicode 字符或者二进制数

据。运用 Cookie 难以实现存储略微复杂的信息。

Session 中能够存取任何类型的数据，包括且不限于 String 、 Integer 、 List 、 Map 等。

4．隐私策略的不同

 Cookie 对客户端是可见的，别有用心的人可以分析存放在本地的 Cookie 并进行 Cookie

欺骗，所以它是不安全的。

 Session 存储在服务器上，对客户端是透明的，不存在敏感信息泄露的风险。

假如选用 Cookie ，比较好的方法是：敏感的信息，如账号密码等，尽量不要写到 Cookie 中。

可以将 Cookie 信息加密，提交到服务器后再进行解密。存储在本地的 Cookie 就需要自行加密了。

5．有效期上的不同

