测试|第十七篇【测试数据准备的那些事儿】

最近作者有个做性能的任务,任务本身很简单就是做一个登录的脚本。但是随着深入了解,发现这个数据准备却是一个棘手的事情。
场景是这样的,系统部署在一个内网,要登录系统必须先远程一个终端机,然后通过这个终端机再访问系统,然后这个终端机的配置并不优秀,CPU和内存基本处于快饱和状态,然后作者需要制作1500条左右的登录数据。
当然作者第一步就是想着如何偷懒,首先去数据看看有没有可用的数据,有么就直接可以用了,那是自然好啦,结果通过终端打开数据库管理器,然后SELECT了一下,发现等了一支烟的时间,结果数据愣是没有出来,作者是加了 top 500的, 好吧终端硬件吃紧我也就认命了,然后作者优化了SQL语句,主要是把不需要的字段复杂的表连接统统去掉,发现SQL语句还是可以用了,但是没有作者要的数据量,只能自己动手丰衣足食了。
但是找到的数据是没有加密的,而在脚本中的数据是需要加密的,好嘞~事情又来了,怎么加密呢,作者几经询问,找到了一个接口,是用来加密的。这下在做性能之前又需要做自动化了,1500条数据难道要手动一条一条加密吗?当然是不行的,这不是人都变傻了,得嘞自动化的搞起,自动化脚本折腾好了,数据也收集到了,这下应该没问题了吧。
结果就是个悲剧,作者发现接口的方式从GET变POST了,数据库对应的表都变化了,这下作者傻眼了,好吧接着倒腾,作者抓来了系统测试,询问了相关开发后,终于搞到了必要信息,接口的格式,数据库的对应表和字段,然后作者还要往数据库里的一个表插入必要数据才能使用接口,作者又风风火火的看了数据,发现这张表还有一个唯一键的字段,都没人知道是干嘛的,于是作者毛了,直接找了个有效的值,改了最后5位数,就这么INSERT了,还好结果是可以用的。
不过作者这个时候又发现一个问题,这样的数据作者要插入1500条,于是乎作者需要制作一个读取TXT数据,写入数据库的小程序,说干就干,通过一天的努力,作者写出了程序,打了个包,直接实验,结果惨败,数据库直接KILL了我的进程,我瞬间哭都哭出来了。作者自暴自弃了4个小时,然后又狗回了自己的位子,然后查看除了什么问题,查看了LOG,看了数据库的LOG,发现也没什么,然后又尝试了几次,发现INSERT到500多条的时候,程序进程就会被KILL掉,想了好久作者认为是数据库安全策略,好了DBA,他老人家不在,又找了运维兄弟,看了也不知道为啥,好嘛~不知道就不知道吧,作者突然灵机一动,直接把自己的程序改了,改成每到450次INSERT后就断开SQL连接重新连接,哈哈哈哈,天无绝人之路作者成功了。
然后作者从新尝试了一下测试脚本,发现测试成功,但是有个好奇怪的事情,单笔登录时间居然要十几秒,这个做毛毛的性能啊,直接可以砍死开发大大们了。于是作者抱着普度众生的心态,问了自己的老大,这个任务的由来是怎么回事,后来发现,这件事情是线上发现的,结果UAT上还没弄了,好吧。。。作者于是又找了运维兄弟,从生产线上复制了必要的文件和信息,然后安装在了UAT上。
至此作者终于准备好了测试环境,测试数据,测试脚本。
作者这么多废话,其实就想表达一点,测试数据的准备,没有什么一定的方法,或是必须由什么人来制作出来,条条大路通罗马,八仙过海,就是这么回事。
作者在这个任务中基本上把所有的可用手段都用上了,从开发知识到业务知识再到数据库知识,自动化性能测试知识也都统统用上了。数据准备工作虽然麻烦,但是作为高质量的测试却是必不可少的一个环节。
【测试|第十七篇【测试数据准备的那些事儿】】好了作者也唠叨完了,希望可以给大家一些启发吧。

    推荐阅读