cookie本来就是header（消息头）的一部分，你把获取到的cookie放到header里就好了
https://testerhome.com/articles/19976

如果是自己公司的系统，验证码可以从缓存拿，cookie也是头的一部分，可以从响应体中把头的cookie取下来放在接下来需要鉴权的请求头内

感觉你太忙了，以后有机会多聊聊

其实并不会，很多年前我也有你这类的想法，认识系统的本质，追求卓越的技术最终落地是以品质为中心的，只是它代替了人为而以更高效更稳定的方式执行。产生这样的想法也许是你认为当前某些黑盒因素是技术无法取代的，就像当年手工工艺者一样 认为机器的出现不会做的比手工工艺更精细，而事实证明目前机器所带来的精细化远超手工劳作预期

被测系统对业务建模，测试被测系统不仅需要对业务建模，还需要对业务的系统进行建模，所以真实的自动化不比业务简单，对于传统的用例脚本方案设计，多数是对业务被测要素，行为操作进行抽离，需要依赖人为去构造测试案例。以此进行上升应该是对领域模型进行抽离，元素依据被测模板生成，测试用例按照被测元素节点以及领域行为生成，能够做到后者的 应该少之又少吧。

中间件：线程池、JDBC连接池、JVM（GC/FULL GC/堆大小）。。。 . 中间件应该是 ：<消息中间件> MQ ，<服务治理中间件> dubbo ...<缓存中间件> redis .... <数据库中间件>myCat ，atlas 一类的。 这里概念似乎有些问题 .

技能太过专注，就业机会较少 - 这点不是很认同，我觉得应该是横向拓展 ，纵向挖深，我相信市场更喜欢T字形人才，一个位置深挖，挖到别人都看不到的领域，那么你一定是这一领域专家，这样的人是很多大公司可遇不可求的。

嗯 ，我之前看到帖子里说的了，我之前以为设计思路是直接关联某id， 再通过某id 检索到匹配某ID的具体信息 （如 url，参数 ，头等等）。 检索到后 再拿具体的信息去回放。

回放竟然还要带上params，不可思议。。。 常态不应该是只需要traceId标识就可以吗，自用的时候发现只用traceid也是失败的。。

实现逻辑一般这样。 前端请求服务端 , 这里请求时会自带一个imageid，后端会通过id返回验证码图片信息，并存储某个通过image改造加密后的id在缓存中间件，最终当你在前端输入验证码做登录请求的时候，接口层会通过你输入的验证码与缓存中的验证码来对比获取鉴权认证。 这里的关键还是在于你要获取key来取值做输入