httprunner2.x--关于 SessionID 问题
HttpRunner：关于 SessionID 问题
HTTP 是一个无状态的协议，每次请求之后不会留下任何痕迹。就像是有一个失忆的家伙，从来记不住是谁到过他家里，客人必须每来一次都重新告诉他姓名。如果碰到这么一个傻服务器，这就麻烦了，每访问一个页面都要重新输入一次用户名和密码，这肯定要让人崩溃的。
于是为了避免这种问题的发生，就需要一个机制来记忆每个用户的身份，即给每个客户发放一个凭证，因此 Cookie、Session、Token、JWT、OAuth2 等这些技术应运而生。那么我们在进行接口测试的时候，就需要把服务器第一次发给我们的这些凭证拿到，在后续请求中再把这些凭证传给服务器来验明正身。
这个过程主要涉及两个操作：
- 发送第一个请求（可以带上用户名密码等信息），从服务器的响应中提取凭证信息。
- 发送后续请求，请求中要附带前面取得的凭证信息，从而模拟前一个的用户身份。
案例分析
浏览器和服务器之间，通过一种 Cooke + Session 的技术，可以保证记住访问的用户及其身份，这样访问一个系统的时候，只要输入一次用户名和密码就可以了：
- 浏览器首次访问服务器的时候，服务器返回一个唯一的 SessionID 编号（见图中红线部分）
- 该 SessionID 对应于服务器中的某块存储空间（内存或数据库中），称之为 Session
- 该 SessionID 通过响应头域“Set-Cookie”传递给浏览器端
- 该 SessionID 被浏览器保存于临时“cookie”中
- 后续该浏览器向该服务器发起的所有请求，都会把这个 SessionID 附带上
- 一般登录成功后，服务器会将用户信息（如用户ID）保存到 Session 中
- 服务器通过请求附带的“SessionID”找到对应的“Session空间”，再读取里面的用户信息，就可以判断用户身份了。
综上，在进行测试的时候，我们要模拟一个用户的请求，就要获取到该用户的 SessionID
注意：
1. 在本被测系统中， SessionID 是保存在临时 Cookie 中的一个“键-值对”
2. 每次会话都会生成一个新的 SessionID（此会话期间各请求的SessionID不变），其中：
- “键”的名称，前面部分是固定不变的，后面部分是可能会改变的
- “值”的部分，每次会话都会不同
需要解决的问题：
1. 从响应中提取 SessionID，为后续请求做准备
思路：将提取出来的 SessionID 保存到一个变量中，后续请求直接调用即可
2. 该系统中的 SessionID 名称是不固定的
思路：通过正则表达式的方式解决名称变化
