xhr请求有两个sessionid_接口测试：A06_HttpRunner关联_01_SessionID 问题引入

A06_HttpRunner关联_01_关于SessionID问题的引入

HTTP 是一个无状态的协议，每次请求之后不会留下任何痕迹。就像是有一个失忆的家伙，从来记不住是谁到过他家里，客人必须每来一次都重新告诉他姓名。如果碰到这么一个傻服务器，这就麻烦了，每访问一个页面都要重新输入一次用户名和密码，这肯定要让人崩溃的。

于是为了避免这种问题的发生，就需要一个机制来记忆每个用户的身份，即给每个客户发放一个凭证，因此 Cookie、Session、Token、JWT、OAuth2 等这些技术应运而生。那么我们在进行接口测试的时候，就需要把服务器第一次发给我们的这些凭证拿到，在后续请求中再把这些凭证传给服务器来验明正身。

这个过程主要涉及两个操作：

1. 发送第一个请求(可以带上用户名密码等信息)，从服务器的响应中提取凭证信息。
2. 发送后续请求，请求中要附带前面取得的凭证信息，从而模拟前一个的用户身份。

案例分析

浏览器和服务器之间，通过一种 Cooke + Session 的技术，可以保证记住访问的用户及其身份，这样访问一个系统的时候，只要输入一次用户名和密码就可以了：

• 浏览器首次访问服务器的时候，服务器返回一个唯一的 SessionID 编号(见图中红线部分)
• 该 SessionID 对应于服务器中的某块存储空间(内存或数据库中)，称之为 Session
• 该 SessionID 通过响应头域“Set-Cookie”传递给浏览器端
• 该 SessionID 被浏览器保存于临时“cookie”中
• 后续该浏览器向该服务器发起的所有请求，都会把这个 SessionID 附带上
• 一般登录成功后，服务器会将用户信息(如用户ID)保存到 Session 中
• 服务器通过请求附带的“SessionID”找到对应的“Session空间”，再读取里面的用户信息，就可以判断用户身份了。

综上，在进行测试的时候，我们要模拟一个用户的请求，就要获取到该用户的 SessionID

访问登录页面，第一次请求，服务器返回的响应信息中，包括了需要提取的 sessionid

注意：

1. 在本被测系统中， SessionID 是保存在临时 Cookie 中的一个“键-值对”

2. 每次会话都会生成一个新的 SessionID(此会话期间各请求的SessionID不变)，其中：

• “键”的名称，前面部分是固定不变的，后面部分是可能会改变的
• “值”的部分，每次会话都会不同

服务器返回的 SessionID 图解

需要解决的问题：

1. 从响应中提取 SessionID，为后续请求做准备

思路：将提取出来的 SessionID 保存到一个变量中，后续请求直接调用即可

2. 该系统中的 SessionID 名称是不固定的

思路：通过正则表达式的方式解决名称变化