前言
往期文章我们已经介绍了前期性能测试阶段的准备，中间性能测试工具的选型和执行，本文介绍性能测试方案最后一部分性能分析与调优。性能测试结果分析与调优是性能测试中的一个重要部分，同时也是一个难点。不同的软件系统，不同的性能指标，结果分析方法都是不一样的。文章源自玩技e族-https://www.playezu.com/185237.html
系统的瓶颈文章源自玩技e族-https://www.playezu.com/185237.html
性能测试调优需要先发现瓶颈，那么系统一般会存在哪些瓶颈，下面按照先后顺序逐一介绍。文章源自玩技e族-https://www.playezu.com/185237.html
1.硬件上的性能瓶颈：文章源自玩技e族-https://www.playezu.com/185237.html
一般指的是CPU、内存、磁盘I/O 方面的问题，分为服务器硬件瓶颈、网络瓶颈（对局域网可以不考虑）、服务器操作系统瓶颈（参数配置）、中间件瓶颈（参数配置、数据库、web服务器等）、应用瓶颈（SQL 语句、数据库设计、业务逻辑、算法等）。文章源自玩技e族-https://www.playezu.com/185237.html
2.应用软件上的性能瓶颈：文章源自玩技e族-https://www.playezu.com/185237.html
一般指的是应用服务器、web 服务器等应用软件，还包括数据库系统。文章源自玩技e族-https://www.playezu.com/185237.html
例如：中间件weblogic 平台上配置的JDBC连接池的参数设置不合理，造成的瓶颈。文章源自玩技e族-https://www.playezu.com/185237.html
3.应用程序上的性能瓶颈：文章源自玩技e族-https://www.playezu.com/185237.html
一般指的是开发人员新开发出来的应用程序。文章源自玩技e族-https://www.playezu.com/185237.html
例如，程序架构规划不合理，程序本身设计有问题（串行处理、请求的处理线程不够），造成系统在大量用户访问时性能低下而造成的瓶颈。
4.操作系统上的性能瓶颈：
一般指的是windows、UNIX、Linux等操作系统。
例如，在进行性能测试，出现物理内存不足时，虚拟内存设置也不合理，虚拟内存的交换效率就会大大降低，从而导致行为的响应时间大大增加，这时认为操作系统上出现性能瓶颈。
5.网络设备上的性能瓶颈：
一般指的是防火墙、动态负载均衡器、交换机等设备。
例如，在动态负载均衡器上设置了动态分发负载的机制，当发现某个应用服务器上的硬件资源已经到达极限时，动态负载均衡器将后续的交易请求发送到其他负载较轻的应用服务器上。在测试时发现，动态负载均衡器没有起到相应的作用，这时可以认为网络瓶颈。
性能测试出现的原因及其定位十分复杂，以上只是总结的几种常见的类型和特性，实际的性能测试分析，对于不同的应用系统，不同的测试目的，不同的性能关注点，我们要综合考虑，具体问题具体分析。
性能调优步骤
1.确定问题
应用程序代码：在通常情况下，很多程序的性能问题都是写出来的，因此对于发现瓶颈的模块，应该首先检查一下代码。
数据库配置：经常引起整个系统运行缓慢，一些诸如oracle 的大型数据库都是需要DBA进行正确的参数调整才能投产的。
操作系统配置：不合理就可能引起系统瓶颈。
硬件设置：硬盘速度、内存大小等都是容易引起瓶颈的原因，因此这些都是分析的重点。
网络：网络负载过重导致网络冲突和网络延迟。
2.分析问题
当确定了问题之后，我们要明确这个问题影响的是响应时间吞吐量，还是其他问题？是多数用户还是少数用户遇到了问题？如果是少数用户，这几个用户与其它用户的操作有什么不用？系统资源监控的结果是否正常？CPU的使用是否到达极限？I/O 情况如何？问题是否集中在某一类模块中？是客户端还是服务器出现问题？系统硬件配置是否够用？实际负载是否超过了系统的负载能力？是否未对系统进行优化？
通过这些分析及一些与系统相关的问题，可以对系统瓶颈有更深入的了解，进而分析出真正的原因。
3.确定调整目标和解决方案
提高系统吞吐量，缩短响应时间，更好地支持并发。
4.测试解决方案
对通过解决方案调优后的系统进行基准测试。（基准测试是指通过设计科学的测试方法、测试工具和测试系统，实现对一类测试对象的某项性能指标进行定量的和可对比的测试）
5.分析调优结果
系统调优是否达到或者超出了预定目标？系统是整体性能得到了改善，还是以系统某部分性能来解决其他问题。调优是否可以结束了。
如何判断性能测试达标
1.对于新上线系统
新上线测试系统没有明确的数字标准比对情况下，被测试系统已经被测试到了系统极限(系统的某些资源已经耗尽、cpu、句柄、内存、数据库出现大量的slow query、系统有些处理已经变慢)，并且系统证明是可以水平扩展的，则可以上线。
2.对于老系统
有以往测试结果进行比对，只要证明类似的测试条件下，此次的结果比以往的测试结果更好即可(每秒处理个数更多，单次请求的处理速度更快)
3.对于老系统，但是没有以往测试结果比对的
没有可以比较的测试结果，但是产品已经上线一段时间(至少3个月)，有一些运营数据则需要分析运营的数据来作为比对的基准，主要被测系统达到3个月内系统并发峰值的4倍，就可以认为是可以接受的(这个4倍是以前多次测试积累的经验)
(如果接口为测试对象，则需要混合主要的接口来进行性能测试)
4.开发提供经验值
开发人员提供经验值作为比对的基准，则被测对象只要证明满足开发人员提出的经验值即可。
如果选择以上的某一种策略，则必须明确系统的每秒处理个数和每次请求的平均时间的具体数值，并出具最终的性能测试报告。
总结
性能测试一直是软件测试的难点，要求我们掌握很多技能，测试思路、系统架构、性能测试工具等等，同时我们还需要加强跟开发、DBA、运维、组内测试人员的沟通，大型系统的软件性能测试，需要大家通力合作才能有效的保障软件系统的质量。以上部分就是软件性能测试方案的全部内容了，希望能够帮助到大家。