性能测试流程

一、设定性能目标
        是否有性能问题？为什么需要调优？

二、执行、分析
      “定位到问题”或“发现了瓶颈”：性能不好体现在哪里？
分析原则：

　　● 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）

　　● 查找瓶颈时按以下顺序，由易到难。

　　服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）

　　注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。

　　● 分段排除法 很有效

分析的信息来源：

　　● 1 根据场景运行过程中的错误提示信息

　　● 2 根据测试结果收集到的监控指标数据
具体分析参考：http://blog.51testing.com/?49159/action_viewspace_itemid_869.html

三、提出调优方案
       你要调什么？希望得到什么结果？
       同一个问题，可能可以从多个方面进行处理。这就需要考虑到工作量、效果、隐患等多种因素，当然也不排除几种优化共同作用。
eg：一个慢SQL，优化的方式可能是加个索引、绑定缓存、改写SQL、表分区、甚至是升级硬件。
        资源争用问题，既可以从配置层面进行优化、减小争用发生的机率，又可以从程序的实现方式上做改变、从源头上避免争用。

四、调优
        是否从源头上调优？
eg：如果我已经发现数据库较慢，通过进一步监控又发现了一个cache的spinlock contention这个指标超过了正常的范围。那么我会猜测可能是这块 缓存的争用导致了数据库的运行状况变差，针对这个现象我知道可以通过将cache分区来减少争用，改变配置后再重新测试和监控，这就可以算是一次调优的尝 试。
但如果你只停留在数据库慢的这个层面上，又怎么能进行调优呢？

五、验证
       是否得到希望得到的结果？
       对原问题的验证，还必须确认对其他部分是否产生了副作用。理论上这就需要在每一次调优尝试后，进行一次足够全面的复测。否则，很容易出现“拆东墙补西墙”的问题。
注意要点：● 每次只改变一处。● 每次改变后进行复测。有效的保留，无效的复原。● 不断的迭代，直到达到预期。
参考：http://www.spasvo.com/news/html/2013219150040.html