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机制的时候，常常听到这样一种误解“只要关闭浏览器，Session就消失了”。想象一下会员卡的例子，除非顾客主动对店家提出销卡，否则店家绝对不会轻易删除顾客的资料。对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的默认超时时间。
四、参考
1、《python测试之道》
