获取接口数据

接口测试，第一步就是需要获取接口数据。

目前已实现2个方案，可以获取到线上环境用户操作的接口数据：

方案一、通过和运维沟通，通过运维从后端取log日志发过来，我这边再写一个脚本，从log文件里面取需要的url和parameter保存下来。

方案二、调用es的接口，通过脚本查询拉取kibana上面对应的index的数据。

从方案暴露的问题作为切入点，记录一下问题和实现的过程。

方案一的不足：

背景：

因为需求不是很明确，一开始的想法是，只需要拿到线上环境的用户操作的接口数据，通过脚本去跑接口，得出一份respond的数据作为版本前的标准数据就可以了。

但是，细想一下，这样的标准数据是死的，方案一 就暴露了很大的不足：

1.很依赖运维什么时候给的接口log，什么时候才能更新这份版本前的数据。而且数据量巨大，0.5天的接口数据解压出来有12Gb，单单提取url和parameter的文本文件有将近7Gb。

2.如果版本更新后接口进行了CUD，那么，版本前接口没CUD的respond数据是没有更新的，版本后，如果也还是用运维给的log的url和parameter去跑，这份respond的数据也是没有更新的，即是版本前和版本后都没有把已经CUD的接口给加进去做对比，显然，这是一个很大的漏洞。

方案二的优&缺点：

背景：

显然，方案一 存在不足，才会诞生方案二、方案三  。。。

方案二针对方案一 的疼点，解决了以下问题：

1.接口数据依赖运维的问题，可解藕。

2.接口数据迭代麻烦的问题，可随时更新接口数据，today，yesterday and so on ，只要需要，随时可以取一份新的接口数据下来。但，方案二 也有限制，因为面向的对象不是运维了，面对运维，可能说你要多少的数据，运维就给你发多少Gb。而，方案二 是通过脚本查询去从es取想要的数据，面向对象就从运维变成elk了，方案二 的限制的根本，其实也在于es的限制，因为调用es的接口，es default就是一次最多只能返回10000条数据，当你想要取1000000条数据当时候，抱歉，报错了：size shoud be < = 10000

但，10k的数据，很明显是不够的，中午高峰期的时候，10分钟就有100k左右的数据：

所以，如果要取的话，大约取1000k应该就差不多了。

那怎么办，怎么从10k变成1000k

换位思考下，如果这个是money呢，既然不能一次取那么多钱，那么分多次取，不就可以了吗

既然不能从深度获取更多的数据，那么可以从广度下手呀，于是在代码里面加入了如下逻辑：

1.date是自定义取那个时间的数据，精确到 %Y-%m-%d %H:%M:%S

2.然后每一次取10k条数据，同时在当前设定的时间上增加5分钟，也就是，一个小时取12个5分钟前面的10k条数据

3.如果range(100)，10k*100 = 1000k，100次基本上可以覆盖到一整天高峰时期的接口数据（10：00-18：00）

4.同时增加异常处理，报错了，也会继续跑下个5分钟（可能偶尔会出现些不符合json格式的接口），目的是取接口数据，报错不应该停止。

5.考虑到会给es的服务器大的压力，所以，每取完一次，等待10s再去执行下一次，尽量希望那边的服务器能扛住（心慌慌）

 （如果不行，会考虑给30s等待时间）

  problem：

      虽然，这样已经可以取到大量的接口数据了，但是，还有个问题就是，取的接口数据并不是连续的，1000k的数据都是取每个5分钟前面的10k条，和运维给的log的文件的连续的数据是有区别的。考虑到我们的需求是接口测试自动化对比，接口数据是否连续的应该是影响不大的，只要量够大，是基本都覆盖到了，而且，如果真的要连续的数据，半天就有7G的数据，覆盖一天，就有十几G，如此大的数据量，对于接口测试也是很大的压力，所以选择了脚本实现的散点分布的大覆盖实现方法。

（当然，需要取连续的数据在某些场景是需要的，有方法是改es的配置，但是，个人觉得这并不是最优解，es既然做了限制，自然会有它的道理，估计是不想给服务器太大的压力，所以这里也为以后埋个伏笔）