接口测试,第一步就是需要获取接口数据。
目前已实现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既然做了限制,自然会有它的道理,估计是不想给服务器太大的压力,所以这里也为以后埋个伏笔)