性能测试方法及分析方法.docx

性能测试方法及分析方法.docx

《性能测试方法及分析方法.docx》由会员分享，可在线阅读，更多相关《性能测试方法及分析方法.docx（29页珍藏版）》请在冰豆网上搜索。

性能测试方法及分析方法

性能测试方法及分析方法

一、性能测试简介

1.1什么是软件性能

一般来说，性能是一种指标，表明软件系统或构件对于其及时性要求的符合程度；其次，性能是软件产品的一种特性，可以用时间来进行度量。

性能的及时性用响应时间或者吞吐量来衡量。

响应时间是对请求作出响应所需要的时间。

对于单个事务，响应时间就是完成事务所需的时间；对于用户任务，响应时间体现为端到端的时间。

比如，“用户单击OK按钮后2秒内收到结果”就是一个对用户任务响应时间的描述，具体到这个用户任务中，可能有多个具体的事务需要完成，每个事务都有其单独的响应时间。

对交互式的应用（例如典型的Web应用）来说，我们一般以用户感受到的响应时间来描述系统的性能，而对非交互式应用（嵌入式系统或是银行等的业务处理系统）而言，响应时间是指系统对事件产生响应所需要的时间。

通常，对软件性能的关注是多个层面的：

用户关注软件性能，管理员关注软件性能，产品的开发人员也关注软件性能，下面将从3个不同层面来对软件性能进行阐述。

1.1.1用户视角的软件性能

从用户的角度来说，软件性能就是软件对用户操作的响应时间。

说得更明确一点，对用户来说，当用户单击一个按钮、发出一条指令或是在Web页面上单击一个链接，从用户单击开始到应用系统把本次操作的结果以用户能察觉的方式展示出来，这个过程所消耗的时间就是用户对软件性能的直观印象。

图1.1以一个Web系统为例，说明了用户的这种印象。

图1.1Web系统的响应

必须要说明的是，用户所体会到的“响应时间”既有客观的成分，也有主观的成分。

例如，用户执行了某个操作，该操作返回大量数据，从客观的角度来说，事务的结束应该是系统返回所有的数据，响应时间应该是从用户操作开始到所有数据返回完成的整个耗时；但从用户的主观感知来说，如果采用一种优化的数据呈现策略，当少部分数据返回之后就立刻将数据呈现在用户面前，则用户感受到的响应时间就会远远小于实际的事务响应时间（顺便说一下，这种技巧是在C/S结构的管理系统中开发人员常用的一种技巧）。

“响应时间”的解释。

1.1.2管理员视角的软件性能

从管理员的角度来看，软件系统的性能首先表现在系统的响应时间上，这一点和用户视角是一样的。

但管理员是一种特殊的用户，和一般用户相比，除了会关注一般用户的体验之外，他还会关心和系统状态相关的信息。

例如，管理员已经知道，在并发用户数为100时，A业务的响应时间为8秒，那么此时的系统状态如何呢？

服务器的CPU使用是不是已经达到了最大值？

是否还有可用的内存？

应用服务器的状态如何？

我们设置的JVM可用内存是否足够？

数据库的状况如何？

是否还需要进行一些调整？

这些问题普通的用户并不关心，因为这不在他们的体验范围之内；但对管理员来说，要保证系统的稳定运行和持续的良好性能，就必须关心这些问题。

另一方面，管理员还会想要知道系统具有多大的可扩展性，处理并发的能力如何；而且，管理员还会希望知道系统可能的最大容量是什么，系统可能的性能瓶颈在哪里，通过更换哪些设备或是进行哪些扩展能够提高系统性能，了解这些情况，管理员才能根据系统的用户状况制定管理措施，在系统出现计划之外的用户增长等紧急情况的时候能够立即制定相应措施，进行迅速的处理；此外，管理员可能还会关心系统在长时间的运行中是否足够稳定，是否能够不间断地提供业务服务等。

因此，从管理员的视角来看，软件性能绝对不仅仅是应用的响应时间这么一个简单的问题。

表1-1给出了管理员关注的部分性能相关问题的列表。

表1-1管理员关注的部分性能相关问题

管理员关心的问题

软件性能描述

服务器的资源使用状况合理吗

资源利用率

应用服务器和数据库的资源使用状况合理吗

资源利用率

系统是否能够实现扩展

系统可扩展性

系统最多能支持多少用户的访问？

系统最大的业务处理量是多少

系统容量

系统性能可能的瓶颈在哪里

系统可扩展性

更换哪些设备能够提高系统性能

系统可扩展性

系统能否支持7×24小时的业务访问

系统稳定性

从开发人员的角度来说，对软件性能的关注就更加深入了。

开发人员会关心主要的用户感受——响应时间，因为这毕竟是用户的直接体验；另外，开发人员也会关心系统的扩展性等管理员关心的内容，因为这些也是产品需要面向的用户（特殊的用户）。

但对开发人员来说，其最想知道的是“如何通过调整设计和代码实现，或是如何通过调整系统设置等方法提高软件的性能表现”，和“如何发现并解决软件设计和开发过程中产生的由于多用户访问引起的缺陷”，因此，其最关注的是使性能表现不佳的因素和由于大量用户访问引发的软件故障，也就是我们通常所说的“性能瓶颈”和系统中存在的在大量用户访问时表现出来的缺陷。

举例来说，对于一个没有达到预期性能规划的应用，开发人员最想知道的是，这个糟糕的性能表现究竟是由于系统架构选择的不合理还是由于代码实现的问题引起？

由于数据库设计的问题引起？

抑或是由于系统的运行环境引发？

或者，对于一个即将发布到现场给用户使用的应用，开发人员可能会想要知道当大量用户访问这个系统时，系统会不会出现某些故障，例如，是否存在由于资源竞争引起的挂起？

是否存在由于内存处理等问题引起的系统故障？

因此，对开发人员来说，单纯获知系统性能“好”或者“不好”的评价并没有太大的意义，他们更想知道的是“哪些地方是引起不好的性能表现的根源”或是“哪里可能存在故障发生的可能”。

表1-2给出了开发视角的软件性能关注内容。

表1-2开发人员关注的性能问题

开发人员关心的问题

问题所属层次

架构设计是否合理

系统架构

数据库设计是否存在问题

数据库设计

代码是否存在性能方面的问题

代码

系统中是否有不合理的内存使用方式

代码

系统中是否存在不合理的线程同步方式

设计与代码

系统中是否存在不合理的资源竞争

设计与代码

以上我们描述了3个不同层面上的软件性能关注点，由此可见，不同的对象对软件系统性能的关注是有着显着的差异的。

从项目管理的角度，以我们的系统干系人来分析，大部分用户对性能的理解属于“用户视角”，项目的维护人员或是用户方的项目经理一般会从“管理员视角”来看待软件性能的问题，而项目的创建者——开发人员（包括设计人员）自然就是从“开发视角”来关注软件性能了。

因此，对软件性能测试来说，在不同的层面上要求我们关注不同的内容：

从直接体验的用户的角度来说，表现为软件系统对用户操作的响应时间；在系统或是管理员的关注层面，我们还需要从软件的性能表现分析系统的可扩展性、并发能力等指标；最后，从最贴近软件的创建者——开发人员的角度来说，还需要为软件性能问题进行定位，了解性能的制约因素和引起性能问题的关键原因。

1.2软件性能的几个术语

接触过软件性能测试的人，会经常听到这样一些词汇：

响应时间、并发用户数、吞吐量、性能计数器，在使用性能测试工具进行测试时，还会接触到“思考时间（ThinkTime）”的概念，那么，这些术语的确切含义究竟是什么呢？

本节重点介绍以上的各个术语。

1.2.1响应时间

“响应时间”的概念，响应时间是“对请求作出响应所需要的时间”，而且，我们把响应时间作为用户视角的软件性能的主要体现。

图1.1将用户所感受到的软件性能（响应时间）划分为“呈现时间”和“系统响应时间”两个部分，其中“呈现时间”取决于数据在被客户端收到响应数据后呈现页面所消耗的时间，例如，对一个Web应用，呈现时间就是浏览器接收到数据后用户把数据呈现出来的时间；而“系统响应时间”指应用系统从请求发出开始到客户端接收到数据所消耗的时间。

在一般的性能测试中，我们并不关注“呈现时间”，这是因为呈现时间在很大程度上取决于客户端的表现，例如，一台内存不足的客户端机器在处理复杂页面的时候，其呈现时间可能就很长，而这并不能说明整个系统的性能。

在后续的软件性能测试的讨论中，我们不会区分“系统响应时间”和“响应时间”，直接把这里的“系统响应时间”等同于“响应时间”。

响应时间可以被进一步分解。

图1.2描述了一个Web应用的页面响应时间的构成。

从图中可以看到，页面的响应时间可被分解为“网络传输时间”（N1+N2+N3+N4）和“应用延迟时间”（A1+A2+A3），而“应用延迟时间”又可以分解为“数据库延迟时间”（A2）和“应用服务器延迟时间”（A1+A3）。

之所以要对响应时间进行这些分解，主要目的是为了能更好定位性能瓶颈的所在。

在后续的实例讨论中，读者将会看到如何应用这些响应时间的分解进行性能问题的定位。

图1.2Web应用的页面响应时间分解

关于响应时间，要特别说明的一点是，对客户来说，该值是否能够被接受是带有一定的用户主观色彩，也就是说，响应时间的“长”和“短”没有绝对的区别。

例如，对一个电子商务网站来说，在美国和欧洲，一个普遍被接受的响应时间标准为2/5/10秒，也就是说，在2秒之内给客户响应被用户认为是“非常有吸引力的”，在5秒之内响应客户被认为是“比较不错的”，而10秒是客户能接受的响应的上限。

但考虑一个税务报账系统，该系统的用户每月使用一次该系统，一次花费2小时以上进行数据的录入，当用户单击“提交”按钮后，即使系统在20分钟后才给出“处理成功”的消息，用户仍然不会认为该系统的响应时间不能接受——毕竟，相对于一个月才进行一次的操作来说，20分钟确实是一个可以接受的等待时间。

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

1.2.2并发用户数

在阐述这个术语之前，先来看看为什么在性能测试中需要关注这个“并发用户数”。

首先，如果性能测试的目标是验证当前系统能否支持现有用户的访问，最好的办法就是弄清楚会有多少用户会在同一个时间段内访问被测试的系统，如果使用性能测试工具模拟出与系统的访问用户数相同的用户，并模拟用户的行为，那得到的测试结果就能够真实反映实际用户访问时的系统性能表现，这样一来，也就能够通过性能测试了解到当系统处于实际用户访问时，会具有怎样的性能表现。

这里提到的在同一个时间段内访问系统的用户数量，也就是我们说的并发用户数的一个概念，这种并发的概念通常在性能测试（PerformanceTesting）方法中使用，用于从业务的角度模拟真实的用户访问，体现的是业务并发用户数。

如果抛开业务的层面，仅从服务器端承受的压力来考虑，那么，对C/S或是B/S结构的应用来说，系统的性能表现毫无疑问地主要由“服务端”决定。

在什么时候“服务端”会承受最大的压力，或者说，在什么时候“服务端”表现为最差的性能呢？

毫无疑问，肯定是在大量用户同时对这个系统进行访问的时候。

为了说明这个“同时”，参见图1.3。

图1.3用排球击打墙面

图1.3用“排球击打墙面”说明这种“同时”，毫无疑问，越多的球同时击打到墙面，墙面承受的压力也就越大。

如果把击打排球的人看成是系统的使用者，墙壁代表了我们可怜的服务端，显然，当越多的用户同时使用系统，系统承受的压力越大，系统的性能表现也就越差，而且，此时很可能出现由于用户的同时访问导致的资源争用等问题。

我们在这里提到了“并发用户数”的另一个概念，该概念不从业务角度出发，而是从服务端承受的压力出发，描述的是同时向客户端发出请求的客户，该概念一般结合并发测试（ConcurrencyTesting）使用，体现的是服务端承受的最大并发访问数。

下面我们用一个更接近实际的例子来说明这两个并发概念之间的不同。

图1.4所示是实际应用系统的演示。

图1.4实际应用系统

对服务端来说，每个用户和服务端的交互都是离散的。

如果仅考虑一个单独的用户对系统的使用，过程大致如下：

用户每隔一段时间向服务端发送一个请求或是命令，服务端按照用户的请求执行某些操作，然后将结果返回给用户。

从用户的角度来看，在一个相当长的时间段内（例如1天），都会有基本固定数量的使用者使用该系统，虽然每个使用者的行为不同，但从业务的角度来说，如果所有这些用户的操作都没有遇到性能障碍，则可以说该系统能够承受该数量的并发用户访问，这里的并发概念就是前面讨论的业务并发用户数。

然而，如果考虑整个系统运行过程中服务器所承受的压力，情况就会不同了：

在该系统的运行过程中，把整个运行过程划分为离散的时间点，在每个点上，都有一个“同时向服务端发送请求的客户数”，这个就是所称的服务端承受的最大并发访问数。

如果能找到运行过程中可能出现的最大可能的服务端承受的最大并发访问数，则在该用户数下，服务器承受的压力最大，资源承受的压力也最大，在这种状态下，可以考虑通过并发测试（ConcurrencyTesting）发现系统中存在的并发引起的资源争用等问题。

在实际的性能测试中，经常接触到的与并发用户数相关的概念还包括“并发用户数”、“系统用户数”和“同时在线用户人数”，下面用一个实际的例子来说明它们之间的差别。

假设有一个OA系统，该系统有2000个使用用户——这就是说，可能使用该OA系统的用户总数是2000名，这个概念就是“系统用户数”，该系统有一个“在线统计”功能（系统用一个全局变量计数所有已登录的用户），从在线统计功能中可以得到，最高峰时有500人在线（这个500就是一般所说的“同时在线人数”），那么，系统的并发用户数是多少呢？

根据我们对业务并发用户数的定义，这500就是整个系统使用时最大的业务并发用户数。

当然，500这个数值只是表明在最高峰时刻有500个用户登录了系统，并不表示实际服务器承受的压力。

因为服务器承受的压力还与具体的用户访问模式相关。

例如，在这500个“同时使用系统”的用户中，考察某一个时间点，在这个时间上，假设其中40%的用户在饶有兴致地看系统公告（注意：

“看”这个动作是不会对服务端产生任何负担的），20%的用户在填写复杂的表格（对用户填写的表格来说，只有在“提交”的时刻才会向服务端发送请求，填写过程是不对服务端构成压力的），20%部分用户在发呆（也就是什么也没有做），剩下的20%用户在不停地从一个页面跳转到另一个页面——在这种场景下，可以说，只有20%的用户真正对服务器构成了压力。

因此，从上面的例子中可以看出，服务器实际承受的压力不只取决于业务并发用户数，还取决于用户的业务场景。

那么，该系统的服务端承受的最大并发访问数是多少呢？

这个取决于业务并发用户数和业务场景，一般可以通过对服务器日志的分析得到。

在实际的性能测试工作中，测试人员一般比较关心的是业务并发用户数，也就是从业务角度关注究竟应该设置多少个并发数比较合理，因此，在后面的讨论中，也是主要针对业务并发用户数进行讨论，而且，为了方便，直接将业务并发用户数称为并发用户数。

那么，究竟应该如何获得测试人员关心的并发用户数的具体数值呢？

下面给出了一些用于估算并发用户数的公式。

（1）

（2）

在公式

（1）中，C是平均的并发用户数；n是loginsession的数量；L是loginsession的平均长度；T指考察的时间段长度。

例如，对一个典型的OA应用，考察的时间段长度应该为8小时的工作时间。

公式

（2）则给出了并发用户数峰值的计算方式，其中，

指并发用户数的峰值，C就是公式

（1）中得到的平均的并发用户数。

该公式的得出是假设用户的loginsession产生符合泊松分布而估算得到的。

下面根据上述给出的方法进行实例计算。

实例：

假设有一个OA系统，该系统有3000个用户，平均每天大约有400个用户要访问该系统，对一个典型用户来说，一天之内用户从登录到退出该系统的平均时间为4小时，在一天的时间内，用户只在8小时内使用该系统。

则根据公式

（1）和公式

（2），可以得到：

C=400×4/8=200

200+3×

=242

当然，这是种可行的方法，但仔细考究起来，其并不是惟一，甚至说不上是最精确的方法，因为在公式中仍然需要估算“平均用户数”和“loginsession的长度”，而要精确估算这两个值并不容易。

另外，考虑到用户的业务操作存在一定的时间集中性（也就是说，用户对系统业务的访问往往不是平均分布在整个考察时间段内，而是相对集中地分布在某几个时间段内），采用公式

（1）和公式

（2）进行计算仍然存在一定的偏差。

我们给出对该公式使用的一些建议，遵循这些建议，可以更精确地计算得到并发用户数：

（1）以更细的时间粒度进行考察：

例如，可以设定1个小时为考察时间的粒度，对一个典型的OA系统，将一天的上班时间划分为8个区间，这样可以解决前面提到的业务操作存在的时间集中性的问题。

（2）考虑典型的业务模式：

不同的应用有不同的业务模式，例如，一个内部系统一般在上班开始后的30分钟至1个小时集中出现用户的登录；一个账务系统在每月的结账日前几天会比较繁忙；一个门户网站在重大消息发布的前后会有访问高峰；一个旅游的网站在节假日前夕会有大量用户的访问……因此，在考虑计算并发用户数时，可以结合应用的业务模式，多考虑一些可能发生的场景，基于这些场景进行估算。

除了这种介绍的方法之外，对于企业内部使用的Web系统来说，一个更一般的（当然精度更差）经验公式是：

（3）

（4）

也就是说，用每天访问系统用户数的10%作为平均的并发用户数，并发用户数的最大值由并发用户数乘上一个调整因子r得到，r的取值一般为2～3。

公式（3）和公式（4）可以在要求不太严格的性能测试，或是只有很少数据支持分析的性能测试中使用。

在本节的前面部分提到了“日志分析”方法。

所谓“日志分析”方法是指通过对应用服务器的日志进行分析，从而了解系统用户的使用状态，从日志中计算出“服务器承受的最大并发用户访问数”数据。

这种方式得到的数据准确度和可信度都比较高，对于Internet应用等无法估计用户数量和用户行为模式的应用，这种方式最为可信。

1.2.3吞吐量

吞吐量是指“单位时间内系统处理的客户请求的数量”，直接体现软件系统的性能承载能力。

一般来说，吞吐量用请求数/秒或是页面数/秒来衡量，从业务的角度，吞吐量也可以用访问人数/天或是处理的业务数/小时等单位来衡量。

当然，从网络的角度来说，也可以用字节数/天来考察网络流量。

例如，对一个Web应用系统来说，从系统的处理能力考虑，可以以页面数/秒作为吞吐量的标准；对一个银行的业务前台系统来说，可以以其处理的业务数/小时作为吞吐量的标准。

在本章的开始部分，已经讨论过，对于交互式应用，用户直接的体验是“响应时间”，通过“并发用户数”和“响应时间”可以确定系统的性能规划；但对于非交互式应用，用“吞吐量”来描述我们对系统性能的期望可能更加合理。

对于交互式应用来说，吞吐量指标反映的是服务器承受的压力。

在容量规划的测试中，吞吐量是一个重点关注的指标，因为它能够说明系统级别的负载能力；另外，在性能调优的过程中，吞吐量指标也有重要的价值，例如，Empirix公司在报告中声称，在他们所发现的性能问题中，有80%是因为吞吐量的限制导致的。

在对Web系统的性能测试过程中，吞吐量主要以请求数（单击数）/秒、页面数/秒或是字节数/秒来体现，吞吐量指标可以在两个方面发挥作用：

（1）用于协助设计性能测试场景，以及衡量性能测试场景是否达到了预期的设计目标：

在设计性能测试场景时，吞吐量可被用于协助设计性能测试场景，根据估算的吞吐量数据，可以对应到测试场景的事务发生频率、事务发生次数等；另外，在测试完成后，根据实际的吞吐量可以衡量测试是否达到了预期的目标。

（2）用于协助分析性能瓶颈：

吞吐量的限制是性能瓶颈的一种重要表现形式，因此，有针对性地对吞吐量设计测试，可以协助尽快定位到性能瓶颈所在位置。

例如，RBI（RapidBottleneckIdentify）方法就主要通过吞吐量测试发现性能

瓶颈。

以不同方式表达的吞吐量可以说明不同层次的问题。

例如，以字节数/秒方式表示的吞吐量主要受网络基础设施、服务器架构、应用服务器制约；以单击数/秒方式表示的吞吐量主要受应用服务器和应用代码的制约。

作为性能测试时的主要关注指标，吞吐量和并发用户数之间存在一定的联系。

在没有遇到性能瓶颈的时候，吞吐量可以采用如下公式计算：

（5）

其中，F表示吞吐量；Nvu表示VU（VirtuaeUser，虚拟用户）的个数；R表示每个VU发出的请求（单击）数量；T表示性能测试所用的时间。

但如果遇到了性能瓶颈，此时吞吐量和VU数量之间就不再符合公式（5）给出的关系。

常用于分析吞吐量的图形是“吞吐量——VU数量”的关联图。

图1.5给出了两个“吞吐量——VU数量”关联图的示例。

从图中可以看到，吞吐量在VU数量增长到一定程度的时候产生了性能瓶颈。

最后，必须要说明的是，虽然吞吐量指标可被看作是系统承受压力的体现，但在不同并发用户数量的情况下，对同一个系统施加相同的吞吐量压力，很可能会得到不同的测试结果。

本文给出了一个示例。

图1.5“吞吐量——VU数量”关联图示例

对同一个应用进行两次不同的性能测试，测试A采用100个并发，每个VU间隔1秒发出一个请求；测试B采用1000个并发，每个VU间隔10秒发出一个请求；对测试A，测试时的吞吐量（页/秒）为100×1/1=100；对测试B来说，吞吐量（页/秒）为1000×1/10=100，仍然是100。

但从测试结果来看，执行测试A时，应用在50页/秒出现性能瓶颈，而测试B在25页/秒出现性能瓶颈。

1.2.4性能计数器

性能计数器（Counter）是描述服务器或操作系统性能的一些数据指标。

例如，对Windows系统来说，使用内存数（MemoryInUsage），进程时间（TotalProcessTime）等都是常见的计数器。

计数器在性能测试中发挥着“监控和分析”的关键作用，尤其是在分析系统的可扩展性、进行性能瓶颈的定位时，对计数器取值的分析非常关键。

但必须说明的是，单一的性能计数器只能体现系统性能的某一个方面，对性能测试结果的分析必须基于多个不同的计数器。

与性能计数器相关的另一个术语是“资源利用率”。

该术语指的是系统各种资源的使用状况。

为了方便比较，一般用“资源的实际使用/总的资源可用量”形成资源利用率的数据，用以进行各种资源使用的比较。

例如，我们会说到，“某某系统在承受10000用户的并发访问时，Web服务器的CPU占用率为68%，平均的内存占用率为55%”，这其中，68%和55%就是典型的资源利用率的数值。

在性能测试中常用资源利用率进行横向的对比，例如，在进行测试时会发现，资源A的使用率达到了接近100%的数值，而其他的资源利用率都处于比较低的水平，则可以很清楚地知道，资源A就很有可能是系统的一个性能瓶颈。

当然，资源利用率在通常的情况下需要结合响应时间变化曲线、系统负载曲线等各种指标进行分析。

性能计数器是性能测试分析的主要参考值，本书的第3章对其进行了详细的解释说明，并说明了如何利用这些计数器分析系统性能瓶颈。

1.2.5思考时间

思考时间（ThinkTime），也被称为“休眠时间”，从业务的角度来说，这个时间指的是用户在进行操作时，每个请求之间的间隔时间。

前面已经讨论过，对交互式应用来说，用户在使用系统时，不大可能持续不断地发出请求，更一般的模式应该是用户在发出一个请求后，等待一段时间，再发出下一个请求。

因此，从自动化测试实现的角度来说，要真实地模拟用户操作，就必须在测试脚本中让各个操作之间等待一段时间，体现在脚本中，具体而言，就是在操作之间放置一个Think的函数，使得脚本在执行两个操作之间等待一段时间。

在测试脚本中，思考时间体现为脚本中两个请求语句之间的间隔时间。

不同的测试工具提供了不同的函数或者方法来实现思考时间，本书附录A中对思考时间进行了的详细描述，另外，本书实践篇也有一些使用思考时间的实际例子。

在实际的测试中，设置多长的思考时间最为合理是许多性能测试工程师关心的问题。

其实，思考时间与迭代次数、并发用户数和吞吐量之间存在一定的关