性能测试流程

一、明确性能测试需求：

一般性能测试需求有以下几种：

1、新系统能力验证

例如，新系统在上线前需要验证系统性能。那就可以自由选择测试环境、压力点、测试工具和测试策略。并且如果性能测试结果没有明显的短板，也不需要进行调优。

2、客户有明确要求

例如，客户要求系统能同时满足100用户登录，平均每个用户登录时间不能超过5秒。那就可以对现系统做一次性能测试，至于，是通过优化系统还是增加硬件设备才能达到要求，就不是测试考虑的问题了。

3、找出系统性能瓶颈

如果要找出系统的性能瓶颈，进行调优或硬件扩容，那么性能测试的重点就在系统的架构分析和业务分析上面。

4、稳定性验证（强度测试）

稳定性是系统的一个重要指标。因为系统一旦上线，就有可能会长期处在用户的访问状态，可能以前没发现的一些问题就会暴露出来。比较典型的就是内存溢出，这种需求在测试策略上就要考虑性能测试的运行时长。

*内存溢出(Out Of Memory，简称OOM)是指应用系统中存在无法回收的内存或使用的内存过多，最终使得程序运行要用到的内存大于能提供的最大内存，此时程序就运行不了，系统会提示内存溢出Out of memory。有时候关闭软件、重启电脑或者软件，释放掉一部分内存又可以正常运行该软件，而由系统配置、数据流、用户代码等原因而导致的内存溢出错误，即使用户重新执行任务依然无法避免。

*在开发程序中，一般是因为开发对内存使用不当，如对该释放的内存资源没有释放，导致其一直不能被再次使用而使内存被耗尽。常见的有以下几种：

1、内存中加载的数据量过于庞大，如一次从数据库取出过多数据；

2、集合类中有对对象的引用，使用完后未清空，使得JVM不能回收；

3、代码中存在死循环或循环产生过多重复的对象实体；

4、使用的第三方软件中的BUG；

5、启动参数内存值设定的过小；

根本的解决办法是对代码进行优化：在内存引用上做些处理。

二、了解系统架构：

  一般来说，最简单的系统架构都是包括表示层、业务逻辑层和数据层。表示层负责应用的呈现，业务逻辑层负责业务逻辑的处理，数据层负责数据库的存储。

常用的系统架构:

* Linux + Apache + PHP + MySQL

*Linux + Apache + Tomcat + Java+ Oracle

*Windows Server 2003/2008 + IIS + C#/ASP.NET + Oracle

*Window Server 2003/2008 + tomcat + Java + MySql/Oracle

三、分析测试点：

1、性能测试点的选取

*发生频率非常高的：例如，某邮箱核心业务系统中的登录、收发邮件等业务，它们在每天的业务总量中占到90%以上；

*关键程度非常高的：被认为绝对不能出现问题的，如登录等；

*资源占用非常严重的：导致磁盘I/O非常大的，例如某个业务进行结果提交时需要向数十个表存取数据，或者一个查询提交请求时会检索出大量的数据记录。

2、对性能需求点的描述

*准确：如某系统必须在不超过 10 秒的响应时间内，处理 20 个登录任务。再如发邮件时间最大不超过5秒以及平均时间在2秒以内。

*一致：用户和性能测试工程师对有关术语的理解要一致，如：并发用户数、在线用户数、注册用户数:等。

*特定：性能测试的需求一定是有条件的。例如，检查系统后台关键业务数据10G、操作数据量为20K、1500 个用户、500 个并发用户运行的负载下，连续运行12小时过程中，业务操作是否满足性能需求。

3、一般性能需求描述

3.1、Web首页打开速度5s以下，Web登录速度15s以下。

3.2、邮件服务支持50万个在线用户。

3.3、订单成功率达到99.999%以上。

3.4、在100个并发用户的高峰期，邮箱的基本功能，处理能力至少达到10QPS(TPS)。 QPS(TPS)指的是每秒钟请求/事物的数量

3.5、系统能在高于实际系统运行压力1倍的情况下，稳定的运行12小时。

3.6、这个系统能否支撑200万的VU（每天登录系统的人次）。VU指的是Virtual user(虚拟用户)。

四、测试工具选型：常用LoadRunner和Jmeter，只要能满足需求就可以了，可以是商业工具、开源工具或者自己研发的性能测试工具。

五、测试计划：

5.1、简介

项目的背景，进行此次性能测试的原因，以及性能测试覆盖的范围等等。

5.2、性能测试需求

经过分析与系统数据收集，寻找被测试对象和压力点。被测的系统应该是最重要的、最基本的功能，也是用户使用最频繁的功能。 以下取几个典型的压力点：

登录：对于一般的系统来说，登录是用户操作系统的前提，如果用户根本就登录不了，那么其它功能将毫无用处。

查询：查询一般比较消耗系统和数据库资源。

交易：对于一些电子商务系统来说，交易过程的性能要求是很高的，如果交易过程消耗用户很长时间的话，用户可能会转投其它平台。当然，除了交易速度外，对交易的成功率要求也是非常高的。

5.3、测试环境

这里的测试环境主要指的是软件、硬件环境和网络环境。

性能测试最好在一个独立的环境内进行，这样不会受到外界的干扰，能够保证测试的数据是独立有效的。如果让你对某个已经上线的网站进行压力测试，那么你得到的数据不是独立的，因为你在做压力测试的时候，其它散户也在访问系统。

软件环境：主要指项目运行的环境，比如采用什么样的操作系统、中间件、和数据库。

硬件环境：除了主要包括主机内部部件，CPU、内存、磁盘以及主板、网卡等，传输介质和路由器也应该考虑在内。

网络环境：除了考虑测试机与被系统服务器在一个局域网中进行，还应该保证这个网络的独立性。如果在在性能测试的过程中，其它机子也在消耗着路由器资源。那么路由器也会影响到数据库的传输速度。    

5.4、数据准备

  在很多时候，我们是要准备测试数据的。例如系统不允许相同用户的重复登录，那么必须要生成合法的用户数据。有时要对系统进行查询测试，那么系统得有一定数据量。一个数据库中有2条数据和有2千万条数据，相同一条查询操作，对系统造成的压力是完全不一样的。

  系统所需数据的分析可以参考以下方式：

1、历史数据分析有助于数据量级的确定。从历史数据入手，找出高峰期数据量。

2、从其他相似或者相同系统入手，进行数据分析，找出高峰期数据量。

3、无历史或者相关系统可以参考的时候，就要对系统的性能数据进行估算，包含系统容量，并发数等数据，估算以后给相关人员进行评审或者修订以后，按照大家同意的性能指标进行测试。

     测试数据最好和真实数据相同，如果能够获得真实系统运行3个月的数据，我们就可以在此基础上进行性能测试。

     关于数据的生成，我们可以借助一个工具完成，如数据库数据生成工具，大小文件生成工具等。  

5.5、测试工具

  在引入工具的时候，除了考虑是否满足需求，还应该考虑工具的成本，这不单指工具的购买成本，还有测试人员对工具的学习成本。

5.6、测试策略

  对于一个特定的业务系统，用户一般会分散在一天的各个时间段进行访问。在不同的时间段中，用户使用业务系统的频率不同，而系统的繁忙程度不同。在一些特定的条件下，可能出现短时间内用户集中访问某个业务系统的情况。

  例如对于秒杀系统而言，可能就存在某个时间内大量用户秒杀某个商品的情况。在进行性能测试时，应当使用【考虑最坏情况的原则】。也就是应当在用户使用业务系统最频繁、对系统造成最大压力的情况下对系统的功能进行测试，判断各功能是否能够满足性能的要求，系统的响应时间是否过长。

  另一方面，系统性能的验证必须做到【覆盖全面】。虽然系统中各个功能的使用频率并不相同，一些功能的使用频率相对于其他功能来说比较低，但是在进行性能测试和优化时，不能忽略这些功能，编制测试用例时也不能仅仅选择最常用功能。例如可能所有的用户都会访问我的通知列表，但是一般只有5%的用户会使用通过系统设置模块查找某个用户的信息。但是在测试时，我们并不能因为查看用户信息功能的使用频率相对较少，而忽略掉这项功能的测试。所以，这里进行系统性能测试时，对于不同业务，用户的访问比例应该做一个合理分配。

  在测试策略上，我们还应该考虑，同一个系统在不同硬件环境下的性能表现。从而让系统满足需求的情况下，硬件配置也能达到一个最佳的状态。过份的增加硬件来满足需求也是一种浪费，再说增加硬件设备不是能解决所有性能问题的。

5.7、人力与时间安排

  根据项目的进度要求以及规模，来进行人力与时间的安排。对于大型的性能测试，项目前期的需求调研，环境的部署，工具的选购或开发，人员对测试工具的学习与使用，性能测试的后进行，后期数据的分析与调优。都需要人员安排的。有可以需要专业的，系统工程师、数据库工程师、软件开发工程师、网络工程师以及性能测试工程师的共同参与配合完成，不是一个性能测试人员就可以全部搞定的。

六、测试环境搭建：

1、保证测试环境与生产环境的一致性

1.1、硬件环境，包括服务器环境与网络环境：如服务器的型号以及是否和其它应用程序共享此服务器，是否在集群环境下，是否进行负载均衡，客户使用的硬件配置情况，使用的交换机型号，网络传输速率。

1.2、软件环境，包括版本和配置的一致性：如操作系统/数据库/中间件的版本/被测系统的版本；系统（操作系统/数据库/中间件/被测试系统）参数的配置一致，这些系统参数的配置有可能对系统造成巨大的影响。

1.3、使用场景的一致性，包括基础数据的一致性和使用模式的一致性：如预测的业务数据量，以及数据类型的分配。很简单的一个列子，一个系统的数据库只有10条数据和一条数据库里几千万条数据，我们在对其进行性能测试时，得到的性能指标可能会有非常大的差别；尽量模拟真实场景下用户的使用情况，其实，我们在做性能测试前期的需求分析，其主要目的也就是为了更真实地模拟用户的使用情况。

七、测试执行：

7.1、准备测试数据；

7.2、使用测试工具模拟测试点，回放OK；

7.3、根据测试策略，使用不同的虚拟用户和测试组合运行测试；

7.4、监控系统CPU、内存、中间件、数据库的性能，收集数据；

7.5、重复3、4。

八、性能调优：

  性能测试调优需要先发现瓶颈，系统一般的瓶颈如下（不仅仅是以下5种）：

1、硬件上的性能瓶颈：

     一般指的是CPU、内存、磁盘I/O方面的问题，分为服务器硬件瓶颈、网络瓶颈（对局域网可以不考虑）、服务器操作系统瓶颈（参数配置）、中间件瓶颈（参数配置、数据库、web服务器等）、应用瓶颈（SQL 语句、数据库设计、业务逻辑、算法等）。

2、应用软件上的性能瓶颈：

     一般指的是应用服务器、web 服务器等应用软件，还包括数据库系统。

例如：中间件weblogic 平台上配置的JDBC连接池的参数设置不合理，造成的瓶颈。

3、应用程序上的性能瓶颈：

     一般指的是开发人员新开发出来的应用程序。

     例如，程序架构规划不合理，程序本身设计有问题（串行处理、请求的处理线程不够），造成系统在大量用户访问时性能低下而造成的瓶颈。

4、操作系统上的性能瓶颈：

     一般指的是Windows、UNIX、Linux等操作系统。

     例如，在进行性能测试，出现物理内存不足时，虚拟内存设置也不合理，虚拟内存的交换效率就会大大降低，从而导致行为的响应时间大大增加，这时认为操作系统上出现性能瓶颈。

5、网络设备上的性能瓶颈：

     一般指的是防火墙、动态负载均衡器、交换机等设备。

     例如，在动态负载均衡器上设置了动态分发负载的机制，当发现某个应用服务器上的硬件资源已经到达极限时，动态负载均衡器将后续的交易请求发送到其他负载较轻的应用服务器上。在测试时发现，动态负载均衡器没有起到相应的作用，这时可以认为网络瓶颈。

性能调优的步骤：

8.1、确定问题

8.1.1、检查应用程序代码：在通常情况下，很多程序的性能问题都是写出来的，因此对于发现瓶颈的模块，应该首先检查一下代码。

8.1.2、数据库配置：经常引起整个系统运行缓慢，一些诸如oracle 的大型数据库都是需要DBA进行正确的参数调整才能投产的。

8.1.3、操作系统配置：不合理就可能引起系统瓶颈。

8.1.4、硬件设置：硬盘速度、内存大小等都是容易引起瓶颈的原因，因此这些都是分析的重点。

8.1.5、网络：网络负载过重导致网络冲突和网络延迟。

8.2、分析问题

  当确定了问题之后，我们要明确这个问题影响的是响应时间、吞吐量，还是其他问题？是多数用户还是少数用户遇到了问题？如果是少数用户，这几个用户与其它用户的操作有什么不用？系统资源监控的结果是否正常？CPU的使用是否到达极限？I/O 情况如何？问题是否集中在某一类模块中？ 是客户端还是服务器出现问题？ 系统硬件配置是否够用？实际负载是否超过了系统的负载能力？ 是否未对系统进行优化？

  通过这些分析及一些与系统相关的问题，可以对系统瓶颈有更深入的了解，进而分析出真正的原因。

8.3、确定调整目标和解决方案

  提高系统吞吐量，缩短响应时间，更好地支持并发。

8.4、测试解决方案

  对通过解决方案调优后的系统进行基准测试。（基准测试是指通过设计科学的测试方法、测试工具和测试系统，实现对一类测试对象的某项性能指标进行定量的和可对比的测试）

8.5、分析调优结果

   系统调优是否达到或者超出了预定目标？系统是整体性能得到了改善，还是以系统某部分性能来解决其他问题。调优是否可以结束了。

   最后，如果达到了预期目标，调优工作就基本可以结束了。

参考链接：测试教程网-性能测试流程