性能测试学习

http://blog.csdn.net/henni_719/article/details/51908063?locationNum=5&fps=1

http://blog.csdn.net/qq_16209077/article/details/50762177?locationNum=2&fps=1

http://www.cnblogs.com/jackei/archive/2006/12/12/589473.html

在开始性能测试之前需要知道什么：

1、性能测试的目的：

首先要知道客户的要求

性能测试按目的分为以下几种：

1）客户有明确要求：如系统要求同时满足100用户登陆，平均每个用户的登陆时间不能超过5秒。有确定完整的性能测试指标文档需求这种。

2）只是想知道目前系统性能（容量测试）：可以把我们的目的就是求得最大用户数和最佳用户数。但是，这仍然是比较含糊的一个需求，我们需要对系统做出分析，找出系统的压力点

3）找出系统性能瓶颈：这个同样需要分析可能对系统造成瓶颈的逻辑业务，然后才能进行性能测试

4）了解系统在长时间的压力下性能测试（强度测试）：这个一般验证系统的稳定性，因为系统一旦上线，就有可能长期处在大用户访问状态，可能以前没发现的一些问题就会暴露出来，比较典型的就是内存溢出。

2、性能测试的环境

1、硬件环境：我们需要了解被测服务器硬件配置，用于加压客户端的机子配置，CPU内存等

2）软件环境：我们需要了解被测系统的架构，前端、中间件、服务器（这里指运行系统软件服务器，如tomcat）、数据库，以及他们的部署位置。

3）网络环境：网络环境很重要，在上面的几个目的中，除了找出系统性能瓶颈可以再广域网进行，因为这个目的可以不用设置太多的虚拟用户，只有找出系统哪个地方影响了整个系统的性能就行，其他的目的测试都需要在，局域网进行，不然压力工具所发送的请求都会卡死在网络的传输过程中

3、寻找系统的压力点

我们需要对系统的哪个页面或业务进行加压。这个不是自己想出来的，需要与开发人员的沟通，系统的首页？系统的登陆？还是系统的交易过程？各个业务的用户比例是多少？只有获得有效的性能需求，才容易寻找和定位压力点

http://www.cnblogs.com/fnng/archive/2011/11/15/2250445.html

性能测试的一些技术指标：

work load=virtual users

工作负荷=虚拟用户数

   对服务器产生多大压力，可以由多少用户同时对服务器发送请求来衡量。也就是服务器性能可以看它同时处理多少用户发送来的请求来衡量。虚拟用户数可以用进程或线程的方式进行模拟

response time响应时间：从客户端将数据包发出，到接收到服务器端发来的请求。这个过程的总体时间叫response time,这个时间用来衡量的处理请求的速度（抛出网速限制的前提下）

throughput Ti&To:这个表示吞吐量，吞吐量越大表示系统性能越强。1个用户跑100天和10个用户跑1分钟。当然是1一个用户跑100天的吞吐量大。所以，我们要想看系统的性能应该用“吞吐率”，就是单位时间的吞吐量，比如吞吐量/秒。站在服务器端，T-in表示“吞”，T_out表示“吐”

Ti:T-in主要衡量客户端能力，看客户端往服务器发送的请求数据包的吞吐率。

To:T-out主要衡量服务器端的能力，看服务器处理返回请求数据包的吞吐率。

Hits/Request

网页点击数/请求

Response/Succesful Response

响应/成功的响应 请求和响应是对应，一个请求对应一个响应。但当客户端对服务器的压力达到一定程度后，不是每一请求都能得到响应的。

Hits Per Second

每秒中点击次数  和吞吐量一样，单单用点击数来衡量系统也是不合理的，所以用每秒钟的点击数才能衡量出服务器的处理能力

吞吐量：指在一次性能测试过程中网络上传输的数据量的总和

吞吐率：单位时间内网络上传输的数据量，也可以指单位时间内处理客户请求数量

事务：就是用户某一步或几步操作的集合

TPS：每秒钟系统能够处理事务或交易的数量，它是衡量系统处理能力的重要指标

点击率：点击率可以看做是TPS的一种特定情况。点击率更能体现用户端对服务端的压力。TPS更能体现服务器对客户请求的处理能力

Empirix公司提出的快速识别系统性能瓶颈的方法。该方法基于以下事实。

    1. 发现的80%系统的性能瓶颈都由吞吐量制约；

    2. 并发用户数和吞吐量瓶颈之间存在一定的关联；

    3. 采用吞吐量测试可以更快速定位问题。 

通过不断增加并发用户数和吞吐量观察系统的性能瓶颈。然后，从网络、数据库、应用服务器和代码本身4个环节确定系统的的性能瓶颈。

响应时间过程分析

我们需要对这个过程进行分解，才能得到你真正想要的响应时间。我把整个过程分三个部分，呈现时间，数据传输时间和系统处理时间。

呈现时间:其实主要说的浏览器对接收到数据的一个处理展示的过程。

数据传输时间:这个跟网络关系比较大

系统处理时间：系统得到请求后对请求进行处理并将结果返回

响应时间

　　指的是客户发出请求到得到响应的整个过程的时间。在某些工具中，请求响应时间通常会被称为“TTLB”(Time to laster byte) ,意思是从发起一个请求开始，到客户端收到最后一个字节的响应所耗费的时间。

系统响应时间

　　应用系统从发出请求开始到客户端接收到响应所消耗的时间。

合理的响应时间

　　在互联网上对于用户响应时间，有一个普遍的标准。2/5/10秒原则。

在进行性能测试时，“合理的响应时间”取决于用户的需求，而不能依据测试人员自己设想来决定

性能测试的测试类型

根据不同的测试目的，性能测试可以分为多种类型，常见的有如下几类：

Benchmark

基准测试（Standard Testing）

负载测试（Load Testing）

压力测试（Stress Testing）

Benchmark

开发者对性能进行快速验证的方式。比如技术选型时有3种方案，开发者需要对比3种方案的性能，选择性能和资源消耗相对均衡的解决方案。

另外benchmark还可以:

快速感知修改前后性能的变化

对调优的结果进行快速度量

基准测试

基准测试指的是模拟单个用户执行业务场景时，考察系统的性能指标。

严格意义上来讲，基准测试并不能算作性能测试范畴，它跟功能测试并没有太大区别。差异在于，基准测试的目的更多地是关注业务功能的正确性，或者说验证测试脚本的正确性，然后，将基准测试时采集得到的系统性能指标，作为基准测试结果，为后续并发压力测试的性能分析提供参考依据。

关键字：单个用户

负载测试(Load Test)

主要指的是模拟系统在正常负载压力场景下，考察系统的性能指标。这里说的正常负载，主要是指用户对系统能承受的最大业务负载量的期望值，即预计系统最大应该支持多大用户的并发量。通过负载测试，目的是验证系统是否能满足预期的业务压力场景。我们可以把这种测试方法称为容量测试(volume testing)

另外稳定性测试(endurance testing)也是负载测试的一种。稳定性测试的加压策略跟负载测试也很接近，都是对系统模拟出系统能承受的最大业务负载量，差异在于，稳定性测试更关注系统在长时间运行情况下系统性能指标的变化情况，例如，系统在运行一段时间后，是否会出现事务处理失败、响应时间增长、业务吞吐量降低、CPU/内存资源增长等问题。

例子

测试某email服务的性能。已知该应用的用户峰值是1000，这些用户可以进行阅读发送邮件等操作，每个操作都是事务类型的。假设我们对应用的目标是可以撑住每个用户每小时进行10次事务操作，那么我们需要模拟多少并发呢？

1000 * 10 = 10,000transactions/hour

关键字:预期容量 稳定性测试

压力测试(Stress Test)

压力测试是为了发现在多大并发压力下系统的性能会变得不可接受，或者出现性能拐点（崩溃）的情况。在加压策略上，压力测试会对被测系统逐步加压，在加压的过程中考察系统性能指标的走势情况，最终找出系统在出现性能拐点时的并发用户数，也就是系统支持的最大并发用户数。

例子

Writer1.1.0是个文字处理模块，该模块设计的最大处理字符个数是65535。现在我们要测试该模块在处理超过最大处理能力时的表现——起码不能挂——，这时我们可以随机的拷贝一些字符串，逐渐加大字符串的长度，直到超过65535个。如果该模块此时还没有crash，那就证明该模块工作正常，达到了设计预期。

关键字:压垮 逐步加压

 

性能测试工具应该具备什么的特质呢？

1、工具本身占用系统资源少，可扩展性好，可用性强。    

2、能模拟真实业务事务操作，在并发时能真正产生业务压力。（这一点是核心）

3、对压力测试结果能很好地进行性能分析，快速找出被测试系统的瓶颈。

4、测试脚本的重复性强。

 

性能测试点的选取

 

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

*　　关键程度非常高的（产品经理认为绝对不能出现问题的，如登录等）

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

对性能需求点的描述

准确

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

一致

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

特定

性能测试的需求一定是有条件的。

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

 

一般的性能要求包括：

系统容量：系统最大容纳多少个用户注册。

访问数：同时访问系统的用户数。

并发数：一个操作同时执行的并发数目，一个系统中应该有不同操作的并发数的组合（一般是有权限进行操作的用户）。

系统的最大用户数与最佳用户数:系统在承受的最大并发用户数量，系统在最佳状态下承受的并发用户数据。

响应时间：用户提交一个操作到得到响应的时间间隔。

吞吐率：系统每秒钟处理的TPS

　　性能测试关键的一个因素就是压力，性能是在系统设计满足的最大压力下的性能。并发数要不小于系统正常运行的峰值，数据总量不小于系统正常运行3个月的数据量。

　　在描述并发用户数目时，总是会带有相应的时间段限制。系统的性能指标实质上应当使用单位时间内系统处理请求的个数以及请求响应时间描述。单位时间内能处理的请求个数就是系统的业务吞吐量。虚拟并发用户的数量可以使用如下的公式换算： （真实用户数×每个真实用户请求数）/(总请求响应时间+真实用户总思考时间)=(虚拟用户数×每用户请求个数)/(总请求响应时间+虚拟用户总思考时间)=吞吐量。

性能测试环境包含内容

一般web应用系统分为3层架构（在系统架构一章中有介绍）

*表现层（web服务器）

*业务逻辑层（应用服务器）

*数据层（数据库服务器）

 

性能测试环境包含内容：

硬件：服务器、客户端、交换机等。

软件：数据库、中间件、被测系统、操作系统等。

网络：有线/无线/宽带、网络协议等。

如何保证测试环境与真实生产的一致性

1、硬件环境，包括服务器环境、与网络环境

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

 

2、软件环境

版本一致性

　　包括包括操作系统、数据库、中间件的版本，被测系统的版本。

配置一致性

　　系统（操作系统/数据库/中间件/被测试系统）参数的配置一致，这些系统参数的配置有可能对系统造成巨大的影响。所以，除了保证测试环境与真实环境所使用的软件版本一致，也要关注其参数的配置是否一致。

 

3、使用场景的一致性

基础数据的一致性

　　包括预测的业务数据量，以及数据类型的分配。很简单的一个列子，一个系统的数据库只有10条数据和一条数据库里几千万条数据，我们在对其进行性能测试时，得到的性能指标可能会有非常大的差别。

　　为了保证每次测试环境的更加一致性，磁盘的使用情况以及磁盘的碎片情况也会或多或少的影响的性能。

使用模式的一致性

　　尽量模拟真实场景下用户的使用情况，其实，我们在做性能测试前期的需求分析，其主要目的也就是为了更真实的模拟用户的使用情况。

 

总结

性能测试手段的重点在于加压的方式和策略。

 

1、服务端性能的好坏的指标主要是：

访问速度快不快

能不能撑住尽可能多的访问量

并发用户数，能撑多少人？

事物吞吐量

事务平均响应时间：比如登录是否够快，搜索产品会不会卡顿

事务成功率：在一定的负载下，事务有一些可能会失败