Sandbox 改造记2——Token替换

文章相关内容较早前就已经开发完了，一直没空记录，这次忙里偷闲，将内容记录一下。
此前已经有两篇改造记了，猛戳跳转：
Sandbox + ES 改造踩坑记
SandBox改造记-1

将Sandbox的存储迁移到ES之后，其实陆陆续续碰到了很多问题，包括存储的数据量过大（每天新增10W+）、ES查询代码不够完善等，好在这些问题不是很难处理，都已经依次解决。

解决了上述问题后，存储和获取接口信息的问题基本都解决了，接下来就是正式开始使用已经录制到的Sandbox数据了。

很快我就碰到了今天主要记录的问题——

Token已失效

Sandbox记录的数据，很可能是半个月，一个月之前的，当需要使用到这些数据时，Token基本上都已经处于失效状态。

第一次使用报出了大量的403之后，我才意识到这个问题。

咋办呢？

方法1：重新登录获取最新Token

我想的第一个办法是，根据原Token解析出用户信息后，重新登录。

这个办法有几个好处，一是无需第三方介入，直接解析数据后，从数据库拿到用户账号；二是可以保证每次接口测试前Token都是最新的。

但是它也有一些不好的地方，一是需要重置用户密码为统一密码，这导致测试环境准备比较麻烦，且需要开发协助；二是会重复调用登录接口，测试时间大大增加。

当这个方案做完了之后，整体的接口测试流程：

1、联系开发准备测试环境。
2、从ES获取某个时间段的所有接口数据。
3、拿到数据后在setup阶段，对token进行解析、重新登录、替换token的操作。
4、使用替换后的数据进行测试阶段，进行网络请求并将返回值与Sandbox记录的response进行噪音对比。
5、全部测试完成后，将测试结果记录到数据库并发送飞书消息。

以上步骤中，最麻烦的就是联系开发准备测试环境，会出现各种问题导致测试的效率非常低，而且要各种沟通，成本非常高。与之相比，大大增加的测试时间其实也不算什么问题了。

在使用了两次之后，因为第一步的问题太大导致不得不思考另一种办法去解决问题。

方法2：生成Token后直接在Redis替换

方法1最大的问题其实是因为重新登录需要重置密码，这个操作不能在录制流量的环境直接替换，不然正常用户就要暴走了，只能拉个新环境导数据。所以非常麻烦。

如果可以不走登录，直接替换Token的话，应该就可以绕过这个问题了。

咨询了一下开发后发现上面这个设想是可以成立的。那没啥好说，直接开干。

当然中间的过程肯定没那么简单，涉及到公司的一些信息就不透露了，总之还是经过一番探索，最终还是在不进行登录的情况下，成功生成了新的Token。

这个时候整个测试流程就变成了：

1、从ES获取某个时间段的所有接口数据。
2、拿到数据后在setup阶段，对token进行解析、生成新的Token后分别替换测试数据header中的Token和Redis中存储的Token。
3、使用替换后的数据进行测试阶段，进行网络请求并将返回值与Sandbox记录的response进行噪音对比。
4、全部测试完成后，将测试结果记录到数据库并发送飞书消息。

这个办法不仅将准备环境这个阶段完全绕过去了，还把重复登录这件事给解决，整体的测试速度得到了极大的提升，单线程的情况下，7000条左右的接口请求只需要7-8分钟。

总结

整个过程还是比较曲折，方法2和方法1是同步想到的，甚至能很直观的看到，方法2是更优的做法，但是基于客观条件，只能先花费了比较大的精力去尝试方法1，效果也确实不够理想。

主要的压力其实是来自于为了让Sandbox接口测试这个项目的进度更符合预期，当然最终还是没达成这个预期（笑），后续面对这个问题时还是要提前规划、积极沟通。

不管怎么说，整个的接口测试在单独执行时，已经可以正确执行了，接下来就是对它的能力进行下一步的拓展。