最近有一个测试任务，是测试一个类似于搜索的接口，返回结果如下所示：
主要就是对搜索的结果进行返回。功能测试没有一点儿问题，于是就用ab工具对其进行压力测试。
这压力测试一执行，问题就来了：发起10000次请求，并发100，错误的情况能达到30%--50%了！
不应该有这么多啊？哪儿出问题了？于是就用loadrunner 和jemeter做了同样的测试，失败率为0，响应时间也差不多。这不科学啊？
没有办法，只好去百度google一下，大多数结果说的是apache
ab工具的使用方法，参数介绍，结果分析什么的。一直没有想要的结果，最后找到了：http://stackoverflow.com/questions/579450/load-testing-with-ab-fake-failed-requests-length
上面是全英语的，讲到了这个问题。
The apache benchmarking tool (ab)
assumes that length of response content will be the same during
entire test.
if the connection is closed server-side before the total amount of bytes declared in the Content-Length header has not been received by the client. That can happen if there are other parties between the client and the server, for example, naive handcrafted load balancers (my case).
大概是说如果返回的内容长度不一样，或是连接断了就会出现错误。先分析一下连接吧，我们的网络是非常好的，而且测试端和被测试的对象机器在同一网段，网络是没有任何问题的。
现在就分析一下内容的长度了，因为我是对同一个查询发起的请求，按原理来说结果不会不一样啊？于是就将请求的结果打到日志中好好分析一下，最好才发现原来返回结果中有一个：“took”字段（见第一幅图），这个字段标识的是每次请求所花费的时间。并发请求的时候，所花费的时候肯定是不会一样的，如果时间不一样，就导致返回结果长度不同，于是ab就给记录成failure了，这是ab的一个Bug，我们没有办法解决。找到了问题所在，就好办了，最后换成其他的压力测试工具来测试。
总结：
一，
遇到问题的时候，不能固定思维，如果一直认定是自己的程序问题，在那反复优化，这是没有结果的。要大胆的去怀疑各个方面的问题，像这次测试工具的问题。
二，
解决问题的办法很多，要多尝试一下，多试几个工具，这样对比着来，才能达到解决问题的结果。
三，
善于总结，问题解决后要善于总结，把问题产生的原因，解决办法记录下来，这样才能不断的进步！