第十八篇【测试数据准备的那些事儿--后话】

亲爱的同志们~上次说的那个事情，作者本以为已经结束了，可是昨天晚上，因作者的坚持调查，发现事情，远远没有想象的那么简单。

好啦，让我开启柯南模式，给他家先来场景还原一下：

1. 作者制作了一个用登录的性能测试脚本，环境、数据都准备妥当。

2. 昨天作者在试运行的时候发现，脚本运行成功，但是没有日志信息。

3. 作者的需要验证的问题是，由于系统会在登录的时候写日志到数据库，在高并发下会发生死锁，以及中止线程。

于是作者就蒙圈了，脚本运行完毕，没有日志，这是什么鬼。。。这时作者的柯南基因瞬间爆棚，首先作者先再次运行脚本，一共运行了10次，然后查看日志信息，最先查看数据库里的日志信息，没有被记录下来，然后又问了同事，有没有其他途径，结果发现还有两个方法，一个是通过URL访问日志接口，另一个是通过后台查看日志信息，作者逐一查看了之后，发现都没有响应日志，于是作者做出了如下推测：

1. UAT环境没有部署完全，少了什么，或者除了什么缺陷

2. 直接调用接口不会产生日志，日志写入的时机不在接口这里，而是在程序的某个环节

3. 作者的脚本，看着没问题，其实是有问题的

随后作者就开始找问题了，首先作者用正常的用户登录了一次，发现UAT是有日志的，好了直接排除第一个问题，然后作者打电话询问了做接口的开发同事，从他那里确认了，接口调用时不会触发日志写入的，好嘛，这下脚本只做了一半的事情，还有一半的事情就这么没有了。作者瞬间石化，这要怎么弄。

作者后来花了半天的时间想了想，这个事情的来龙去脉，慢慢貌似明白了我老大的用意，大家来听我讲讲哦，不对的也请大家指正。

1. 就纯粹的技术而言，作者是有办法解决这个问题的，那就是让开发把这个登录的程序提交到测试部门来，然后做白盒的性能测试，或者是让开发做一个WEB的登录小界面，用LR来做性能测试。

2. 就个人而言，作者自然不想把一个事情搞得那么大，因为这个除了万不得已，不然作者也不会去用这么高端的方案。

3. 站在我老大的角度而言，作者认为有可能，我老大只是想我把UAT环境弄弄好，借我这个性能的应头，让开发和运维兄弟们快点动起来，一般性能测试出手必有大事，哈哈哈哈，自吹自擂一下，不要拍脸。

4. 还有一种情况就是，这个事情在当时的情况下，开发、运维、测试都争执不下，作者做为当时最为强力的后援顶了坑，平息了战乱。

当然这些都是作者自己的猜测，作者最近也在一直开会，发现自己不太会说话，也是个棒槌，哎，这个作者以后再分享经验。接着说上面的，作者觉得作为测试，作为一个有技术且有理想和抱负的测试，必须选择第一条，怒刚正面，然后作者准备装着一脸的萌样去问我老大了，哈哈哈，但是在作者自己的内心，隐约感觉这其实是一件政治任务。

同志们不要笑，其实在工作中有什么解决不了的还是多问问领导，领导嘛经验肯定很丰富，作者一向皮厚，而且是个打不死的小强，这个事情如果还有后话，作者还会接着分享的。。。