事情的起因是这样的
上周三下午要出去打个电话，经过小会议室门口的时候测试负责人叫住我问有事吗？小A做的性能测试出现了点问，要我帮忙分析一下。打完电话后到小会议室与小A、测试负责人一起看小A的性能测试出现了什么问题。小A说她对X项目进行了性能测试，但是结果与现在线上的差距特别大，线上入库是10条/秒，而她测试的结果是3-4条/秒，对于她测试得出来的结果项目的负责人很不认同，认为是她做错了，而她又找不出来问题出在哪，她很郁闷。
接下来是我们的一段对话
我：小A，你说一下这次性能测试，是对哪几个点做的，场景都是啥样的？
小A：主要是两个点，一个是单一场景针对短信入库的，景设计的是30、50、100条数据并发持续2个小时，是根据线上前段时间出现的问题发3万条短信，结果处理的时间特别长这个问题设计的；另外一个是将接收到的不同类型的短信入库，是个混合场景，场景是短信2条、彩信1条、WAPPUSH1条、EMN1条，这些数据并发，持续2个小时。
我：问一下，线上对于短信发送真实操作场景是什么样子的呢？
小A：这个我不知道啊，反正我只知道现在线上要求1个小时内必须把这些短信发完，线上现在预计的入库量是10条/秒。
我：好吧，换个问法，X系统小A你最熟了，线上的这个问题，有大量的数据过来，X系统 对这些数据是怎样处理然后入库的呢，是一批一批的处理，还是一条一条的处理呢，如果是一批一批的处理，对于这一批数据是怎样处理的呢，是同时处理掉，还是一条一条的数据。
小A：这个我不清楚，要不一会儿我去问一下开发的吧。
我：我再问一下，现在搭建的这套测试环境，各个机器的配置是怎么样的？和线网的机器配置差距有多大？线网的带宽是多少？现在测试环境的带宽是多少？线网是有负载均衡的，有VPN通道的，测试环境上有这些吗？
小A：tomcat的机器是一台服务器，4核的，另外两台数据库还有LR加压机都是实体机。线网的机器配置我不知道，测试环境也是100兆带宽，负载均衡啥的测试环境都做不了。
我：线网带宽是千兆的，测试环境的百兆带宽不全是给你来测试用的，公司上班时间所有同事办公还占用一部分带宽呢。线网的数据库做过一次优化的，有几个参数是调整过的。
我觉得这次问题的分析可以从几个方面来入手查，第一，场景设计，我从开发的那里了解到线上真实的情况是没有并发的，只是一条一条的来处理，处理的数据量是3万条，1个小时处理完，是我们自己的要求。所以场景可以重新设计，设计成没有并发，处理3万条数据；第二，测试脚本的性能，测试脚本里的代码可能本身响应时间就长；第三，机器配置、网络带宽，查看现在测试机的配置与线网比相差多少，这些能不能想办法进行一下换算，结果可能有误差，如果找到依据，看看误差能控制在多少范围内。
小A：我觉得脚本代码不是问题，我就是这样写的都能执行过去，能执行过去为啥就会有问题呢。线上真实的操作那在那台服务器上还可能有别的省发短信呢，对那台服务器还有影响呢，那台服务器的配置好可能还有别的省来占用呢，所以机器配置也不应该是问题。带宽我觉得也不是问题，公司百兆的带宽也够用了呀，我在测试的时候也没发现网络上哪里出现了问题，CPU占用率呀都非常少的。
我：。。。。。。。无语
对于性能测试，到底应该怎样做，会用了工具（最著名的是LR）就会了性能测试了吗？NO,NO,NO
我认为：
前期分析：
分析业务：分析用户群，业务真实使用和操作情况。比如在哪个时间段哪个操作会多，哪个操作会少，怎样来操作，是会有很多人一起对系统发起请求呢（所谓的并发），还是数据量很大，但是都是一个请求一个请求过来的，很持续很长时间吗（比如8个小时都在做这样的操作），还是主要是对一定的数据量操作的（比如处理完几十万条数据后任务就完成了），每次只有一个场景吗，还是是个混合场景都有，如果是混合场景，那么各个场景的比例大约是多少呢。线上已经有多少数据量了？预期要达到多少数据量？
分析环境：线上系统环境是什么样子的？有负载均衡吗？有多次转发吗？。。。。。机器配置是什么样子的，每台机器上都有哪些服务？线网的带宽是多少？是专用的吗？搭建的测试环境和线网真实的环境有多大的差距，带宽是多少，是专用的吗？测试环境不可能与线网环境是一模一样的，有办法换算吗？误差大约是多少？
分析团队成员：给你配备的配合的开发人员了吗？与你配合的开发人员靠谱吗？你的团队里有性能测试的高手吗？团队对这个项目的性能测试支持吗？
时间分析：测试的时间充足吗？哪些是必须测的，哪些是可以不测的。
测试执行：
有了前面的详细的分析之后，才能整理出测试需求、设计测试方案、编写测试用例、编写测试脚本、设计出合理的测试场景，才能执行测试。
结果分析：
测试出了结果，不能就算完事了，把结果丢给别人让别人分析查找原因，那不是高手，真正的高手是可以分析出问题在哪里，是什么原因产生的，怎样优化。简单的几个切入点可能从服务器系统CPU、内存等等，数据库中SQL执行速度，数据库CPU、内存等入手。查看事务平均响应时间是否在可控范围内，每秒处理的事务数怎样等等。借用一些工具查看操作数据库的SQL执行情况等等。
总结一下，性能测试个人认为最重要的不是使用工具，而是测试前的分析和结果的分析，前面的分析够透彻才能保证后面做的是对的，而不是一上来就是用工具，就大并发，只有大量的并发才是性能测试，一定得根据现实的真实使用情况来做才可以，违背了现实做再多也是无用。每次一听到有开发的对我讲你帮我们做一下性能测试吧，弄个几万的压一下，我就特无语。