最近作者有个做性能的任务，任务本身很简单就是做一个登录的脚本。但是随着深入了解，发现这个数据准备却是一个棘手的事情。
场景是这样的，系统部署在一个内网，要登录系统必须先远程一个终端机，然后通过这个终端机再访问系统，然后这个终端机的配置并不优秀，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上。
至此作者终于准备好了测试环境，测试数据，测试脚本。
作者这么多废话，其实就想表达一点，测试数据的准备，没有什么一定的方法，或是必须由什么人来制作出来，条条大路通罗马，八仙过海，就是这么回事。
作者在这个任务中基本上把所有的可用手段都用上了，从开发知识到业务知识再到数据库知识，自动化性能测试知识也都统统用上了。数据准备工作虽然麻烦，但是作为高质量的测试却是必不可少的一个环节。
【测试|第十七篇【测试数据准备的那些事儿】】好了作者也唠叨完了，希望可以给大家一些启发吧。
