性能测试方法及分析方法

《性能测试方法及分析方法》由会员分享，可在线阅读，更多相关《性能测试方法及分析方法（22页珍藏版）》请在金锄头文库上搜索。

1、性能测试方法及分析方法一、性能测试简介1.1 什么是软件性能一般来说，性能是一种指标，表明软件系统或构件对于其及时性要求的符合程度；其次，性能是软件产品的一种 特性，可以用时间来进行度量。性能的及时性用响应时间或者吞吐量来衡量。响应时间是对请求作出响应所需要的时间。对于单个事务，响应时间就是完成事务所需的时间；对于用户任务，响应时间体现为端到端的时间。比如，“用 户单击OK按钮后2秒内收到结果”就是一个对用户任务响应时间的描述，具体到这个用户任务中，可能有多个具体的 事务需要完成，每个事务都有其单独的响应时间。对交互式的应用（例如典型的 Web 应用）来说，我们一般以用户感受到的响应时间来描述

2、系统的性能，而对非交 互式应用（嵌入式系统或是银行等的业务处理系统）而言，响应时间是指系统对事件产生响应所需要的时间。通常，对软件性能的关注是多个层面的：用户关注软件性能，管理员关注软件性能，产品的开发人员也关注软件 性能，下面将从 3个不同层面来对软件性能进行阐述。1.1.1 用户视角的软件性能从用户的角度来说，软件性能就是软件对用户操作的响应时间。说得更明确一点，对用户来说，当用户单击一个 按钮、发出一条指令或是在Web页面上单击一个链接，从用户单击开始到应用系统把本次操作的结果以用户能察觉的 方式展示出来，这个过程所消耗的时间就是用户对软件性能的直观印象。图1.1以一个Web系统为例，说

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

4、系统的性能首先表现在系统的响应时间上，这一点和用户视角是一样的。但管理员是 一种特殊的用户，和一般用户相比，除了会关注一般用户的体验之外，他还会关心和系统状态相关的信息。例如，管理员已经知道，在并发用户数为100时，A业务的响应时间为8秒，那么此时的系统状态如何呢？服务器的CPU使用是不是已经达到了最大值？是否还有可用的内存？应用服务器的状态如何？我们设置的 JVM 可用内存是否足够？数据 库的状况如何？是否还需要进行一些调整？这些问题普通的用户并不关心，因为这不在他们的体验范围之内；但对管 理员来说，要保证系统的稳定运行和持续的良好性能，就必须关心这些问题。另一方面，管理员还会想要知道系统具

5、有多大的可扩展性，处理并发的能力如何；而且，管理员还会希望知道系 统可能的最大容量是什么，系统可能的性能瓶颈在哪里，通过更换哪些设备或是进行哪些扩展能够提高系统性能，了 解这些情况，管理员才能根据系统的用户状况制定管理措施，在系统出现计划之外的用户增长等紧急情况的时候能够 立即制定相应措施，进行迅速的处理；此外，管理员可能还会关心系统在长时间的运行中是否足够稳定，是否能够不 间断地提供业务服务等。因此，从管理员的视角来看，软件性能绝对不仅仅是应用的响应时间这么一个简单的问题。表 1-1 给出了管理员关注的部分性能相关问题的列表。表 1-1 管理员关注的部分性能相关问题软件性能描述资源利用率管理

6、员关心的问题服务器的资源使用状况合理吗应用服务器和数据库的资源使用状况合理吗资源利用率系统可扩展性系统是否能够实现扩展 系统最多能支持多少用户的访问？系统最大的业务处理量系统容量是多少系统可扩展性系统性能可能的瓶颈在哪里更换哪些设备能够提高系统性能系统可扩展性系统能否支持7X24小时的业务访问系统稳定性从开发人员的角度来说，对软件性能的关注就更加深入了。开发人员会关心主要的用户感受响应时间，因为这毕竟是用户的直接体验；另外，开发人员也会关心系统的扩展性等管理员关心的内容，因为这些也是产品需要面向的用户（特殊的用户）。但对开发人员来说，其最想知道的是“如何通过调整设计和代码实现，或是如何通过调整

7、系 统设置等方法提高软件的性能表现”，和“如何发现并解决软件设计和开发过程中产生的由于多用户访问引起的缺陷”， 因此，其最关注的是使性能表现不佳的因素和由于大量用户访问引发的软件故障，也就是我们通常所说的“性能瓶颈” 和系统中存在的在大量用户访问时表现出来的缺陷。举例来说，对于一个没有达到预期性能规划的应用，开发人员最想知道的是，这个糟糕的性能表现究竟是由于系 统架构选择的不合理还是由于代码实现的问题引起？由于数据库设计的问题引起？抑或是由于系统的运行环境引发？或者，对于一个即将发布到现场给用户使用的应用，开发人员可能会想要知道当大量用户访问这个系统时，系统会不会出现某些故障，例如，是否存在由

8、于资源竞争引起的挂起？是否存在由于内存处理等问题引起的系统故障？因此，对开发人员来说，单纯获知系统性能“好”或者“不好”的评价并没有太大的意义，他们更想知道的是“哪 些地方是引起不好的性能表现的根源”或是“哪里可能存在故障发生的可能”。表 1-2 给出了开发视角的软件性能关注内容。表 1-2 开发人员关注的性能问题开发人员关心的问题问题所属层次架构设计是否合理系统架构数据库设计是否存在问题数据库设计代码是否存在性能方面的问题代码系统中是否有不合理的内存使用方式代码系统中是否存在不合理的线程冋步方式设计与代码系统中是否存在不合理的资源竞争设计与代码以上我们描述了3 个不同层面上的软件性能关注点，

9、由此可见，不同的对象对软件系统性能的关注是有着显着的 差异的。从项目管理的角度，以我们的系统干系人来分析，大部分用户对性能的理解属于“用户视角”，项目的维护 人员或是用户方的项目经理一般会从“管理员视角”来看待软件性能的问题，而项目的创建者开发人员（包括设 计人员）自然就是从“开发视角”来关注软件性能了。因此，对软件性能测试来说，在不同的层面上要求我们关注不同的内容：从直接体验的用户的角度来说，表现为 软件系统对用户操作的响应时间；在系统或是管理员的关注层面，我们还需要从软件的性能表现分析系统的可扩展性 并发能力等指标；最后，从最贴近软件的创建者开发人员的角度来说，还需要为软件性能问题进行定位

10、，了解性 能的制约因素和引起性能问题的关键原因。1.2 软件性能的几个术语接触过软件性能测试的人，会经常听到这样一些词汇：响应时间、并发用户数、吞吐量、性能计数器，在使用性能测试工具进行测试时，还会接触到“思考时间（Think Time） ”的概念，那么，这些术语的确切含义究竟是什么呢?本节重点介绍以上的各个术语。1.2.1 响应时间“响应时间”的概念，响应时间是“对请求作出响应所需要的时间”，而且，我们把响应时间作为用户视角的软 件性能的主要体现。图 1.1 将用户所感受到的软件性能（响应时间）划分为“呈现时间”和“系统响应时间”两个部分，其中“呈现 时间”取决于数据在被客户端收到响应数据后

11、呈现页面所消耗的时间，例如，对一个Web应用，呈现时间就是浏览器 接收到数据后用户把数据呈现出来的时间；而“系统响应时间”指应用系统从请求发出开始到客户端接收到数据所消 耗的时间。在一般的性能测试中，我们并不关注“呈现时间”，这是因为呈现时间在很大程度上取决于客户端的表现 例如，一台内存不足的客户端机器在处理复杂页面的时候，其呈现时间可能就很长，而这并不能说明整个系统的性能。在后续的软件性能测试的讨论中，我们不会区分“系统响应时间”和“响应时间”，直接把这里的“系统响应时间” 等同于“响应时间”。响应时间可以被进一步分解。图 1.2 描述了一个 Web 应用的页面响应时间的构成。从图中可以看到

12、，页面的响应 时间可被分解为“网络传输时间”（N1+N2+N3+N4）和“应用延迟时间” （A1+A2+A3），而“应用延迟时间”又可以分 解为“数据库延迟时间”（A2）和“应用服务器延迟时间”（A1+A3）。之所以要对响应时间进行这些分解，主要目的 是为了能更好定位性能瓶颈的所在。在后续的实例讨论中，读者将会看到如何应用这些响应时间的分解进行性能问题 的定位。图 1.2 Web 应用的页面响应时间分解关于响应时间，要特别说明的一点是，对客户来说，该值是否能够被接受是带有一定的用户主观色彩，也就是说， 响应时间的“长”和“短”没有绝对的区别。例如，对一个电子商务网站来说，在美国和欧洲，一个普遍

13、被接受的响应时间标准为2/5/10秒，也就是说，在2 秒之内给客户响应被用户认为是“非常有吸引力的”，在5 秒之内响应客户被认为是“比较不错的”，而10 秒是客户 能接受的响应的上限。但考虑一个税务报账系统，该系统的用户每月使用一次该系统，一次花费 2小时以上进行数据的录入，当用户单 击“提交”按钮后，即使系统在20 分钟后才给出“处理成功”的消息，用户仍然不会认为该系统的响应时间不能接受 毕竟，相对于一个月才进行一次的操作来说， 20 分钟确实是一个可以接受的等待时间。因此，在进行性能测试时，“合理的响应时间”取决于实际的用户需求，而不能依据测试人员自己的设想来决定。1.2.2 并发用户数在

14、阐述这个术语之前，先来看看为什么在性能测试中需要关注这个“并发用户数”。首先，如果性能测试的目标是验证当前系统能否支持现有用户的访问，最好的办法就是弄清楚会有多少用户会在 同一个时间段内访问被测试的系统，如果使用性能测试工具模拟出与系统的访问用户数相同的用户，并模拟用户的行 为，那得到的测试结果就能够真实反映实际用户访问时的系统性能表现，这样一来，也就能够通过性能测试了解到当 系统处于实际用户访问时，会具有怎样的性能表现。这里提到的在同一个时间段内访问系统的用户数量，也就是我们 说的并发用户数的一个概念，这种并发的概念通常在性能测试（Performance Testing）方法中使用，用于从业

15、务的角 度模拟真实的用户访问，体现的是业务并发用户数。如果抛开业务的层面，仅从服务器端承受的压力来考虑，那么，对C/S或是B/S结构的应用来说，系统的性能表 现毫无疑问地主要由“服务端”决定。在什么时候“服务端”会承受最大的压力，或者说，在什么时候“服务端”表 现为最差的性能呢？毫无疑问，肯定是在大量用户同时对这个系统进行访问的时候。为了说明这个“同时”，参见图 1.3。图 1.3 用排球击打墙面图 1.3 用“排球击打墙面”说明这种“同时”，毫无疑问，越多的球同时击打到墙面，墙面承受的压力也就越大。 如果把击打排球的人看成是系统的使用者，墙壁代表了我们可怜的服务端，显然，当越多的用户同时使用

16、系统，系统 承受的压力越大，系统的性能表现也就越差，而且，此时很可能出现由于用户的同时访问导致的资源争用等问题。我 们在这里提到了“并发用户数”的另一个概念，该概念不从业务角度出发，而是从服务端承受的压力出发，描述的是 同时向客户端发出请求的客户，该概念一般结合并发测试（Concurrency Testing）使用，体现的是服务端承受的最大 并发访问数。下面我们用一个更接近实际的例子来说明这两个并发概念之间的不同。图 1.4 所示是实际应用系统的演示。图 1.4 实际应用系统对服务端来说，每个用户和服务端的交互都是离散的。如果仅考虑一个单独的用户对系统的使用，过程大致如下： 用户每隔一段时间向服务端发送一个请求或是命令