本文章转载于搜狗测试
上篇性能测试过程（一）的文章主要讲了环境准备、逻辑了解和数据准备及需要注意的事项。下面咱们接着说：
除了以上过程外，下面的过程主要有：测试过程、问题定位&调优、回归、报告产出这几个过程。
测试过程：
这里主要指打压的过程了。打压过程并不是放那里不管，需要时刻关注被测服务器的性能指标，结合LoadRunner场景的曲线来动态判断是否存在瓶颈。LoadRunner场景曲线主要关注HPS、TPS、responsetime。服务端主要监控cpu、内存、磁盘IO、网络IO。然后从这几方面再层层深入查找问题。另外，值得强调的是，打压过程不仅需要关注被测服务器的指标，也需要关注打压agent的性能指标是否正常。比如说如果并发数一直上不去，可能是打压机本上连接数受限导致的。也可能是打压机自己出口带宽满了导致的。
问题定位&修改优化&回归：
问题定位是一个比较考验个人综合技术能力的地方。也是整个性能测试的核心所在。需要强调的是，不是看到某个参数遇到问题了，就直接可以断定服务区的瓶颈就在这个地方。比如：
大量的页调入请求导致内存队列的拥塞
网卡的大吞吐量可能导致更多的CPU开销
大量的CPU开销又会尝试更多的内存使用请求
大量来自内存的磁盘写请求可能导致更多的CPU以及IO问题
具体是哪个部分的问题，需要再根据具体的逻辑实现和推断来逐步缩小范围。主要的过程可以参考以下步骤来层层深入的定位问题：服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。
最后就是开发优化，测试回归，这里需要强调一点：测试回归时，如果开发优化时修改了功能逻辑，则需要根据改动回归功能逻辑是否正常。不能只盯在性能指标满足了就OK了。
性能报告：
对于性能测试报告，没有固定的格式，但是大体需要包括以下几个方面：
整体结论：本次性能测试的整体结论。是否符合预期，是否可以上线，可以抗住多少用户数。
具体推算方式：主要指给出整体结论的参考数据、计算公式等。
具体性能图标：服务器cpu、内存、网络IO、磁盘IO、TPS、responsetime等指标，涉及到数据库的还需要给出与服务器相关的指标。
测试方法：主要解释打压的脚本逻辑，数据来源等。
