接口测试,第一步就是需要获取接口数据。
目前已实现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.接口数据迭代麻烦