调用登录接口登录了，其他的接口怎么保持登录状态呢？
首先来看一看，web端或者说客户端是怎么样用cookie/token等保持登录状态的。一般来说，cookie都会在登录接口由服务端返回，而且会是在header里面返回，并且，header里面有一个set-cookie这样的key，是的，就是这家伙，会把登录的cookie写到客户端的cookie缓存里，而后，当客户端要请求指向这个path的其它接口时，将此缓存的cookie塞到请求里面请求，服务端认得这个cookie，即认为后面的接口为已登录状态。
当然，也不排除，有些变态的系统，cookie并不是由登录接口返回的。我碰到过一例，请求主页面时即返回set-cookie，然后客户端拿此cookie及用户名密码登录成功后，cookie激活。有点变态，不是常规实现，后来被重构了。还有些接口，直接把登录token啥的带在url里面，直接在url拼一拼就能完成鉴权。要具体问题具体分析，我接触的项目有限，只能讲讲比较常见的场景，给大家提供一些思路。
这是登录接口的返回headers截图：
比较常见的情况下，关键字create session会创建session对象，下一个请求带上session别名，该session对象会自动完成请求在上下文传递过程中的 Cookie 处理，如下面的例子：
另小伙伴们还可能有其他场景，如服务器间session共享，第二个请求要发往另一个host/域名，如某些app接口请求参数中需要带上cookie/token字段，部分SSO，这时候新请求可能需要创建另一个session，将cookie主动塞到session里面，f5可以看到create session关键字有个${cookies}参数，嗯，就是放到这里面，下图第11行脚本，注意是以键值对的方式传递的（抓包也看得出）：
第8行有个把set suite variable的操作，目的是在此suite下还有跨域名（如其它二级域名）的请求，也可以使用该登录cookie值，只要cookie未过期，只要服务器的session能识别。第8行也是为了重构做准备。
第一次重构：
因为登录是一个很多接口都会依赖的动作，所以要把它抽取成关键字，个人建议是放在suite setup里面，这样做的好处是，省去了每个用例中都去调一次登录接口的时间。关键字抽取，会抽取图2的1-5行，图3中的1-8行做为一个关键字，将用户名密码设为入参，重构完，大概会变成：
在这个suite中，是对banner功能点的接口测试集合，在suite setup里放了登录接口，用例一运行就先登录，名为newmanage的session保持了我的登录状态，其后的待测接口，都请求的同一个域名，因此使用alias为newmanage的get 和post请求，服务端认为已经登录，请求成功。
还有前面说的另外一种情况，在登录时已经把cookie最核心的键值对取出来了，所以待测接口需要的话，新建个seesion把该cookie塞进去就行了，至于如何写会使脚本更精炼合理，建议按实际情况重构脚本。嗯，最后养成好习惯，suite结束时delete all sessions放在suite teardown下。