04-性能测试过程

1.  软件测试的定义

l  定义1：1983年IEEE（国际电子电气工程师协会）提出的软件工程标准术语中给软件测试下的定义是：

       “使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别”。

l  定义2：软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例，并利用这些测试用例去执行程序，以发现软件故障的过程。该定义强调寻找故障是测试的目的。

l  定义3：软件测试是一种软件质量保证活动，其动机是通过一些经济有效的方法，发现软件中存在的缺陷，从而保证软件质量。

2.  性能测试过程

应用系统的性能测试通常有如下过程：

u 1)分析性能需求：了解系统性能需求，建立性能测试数据模型，分析性能需求，确定合理性能目标；

u 2)制定性能测试计划：规划性能测试所需的测试环境、测试程序，测试的人员组织，测试日程等；

u 3)设计场景：设计性能测试的测试案例；

u 4)根据场景编写程序、编写脚本、修改应用系统等；

u 5)执行性能测试：建立测试环境、执行测试案例，记录测试时的系统的各个可能的参数；

u 6)分析测试结果：根据应用系统表现和测试时的系统记录，分析发生的问题和测试结果；

u 7)优化性能：提高系统的性能，使系统在测试时有更好的表现；

u 8)性能回归测试：验证系统的优化以及对相关功能模块的影响；

u  9) 测试报告：对测试进行总结，记录已改进的问题及相关改进的修改，制定未解决问题的对策，提出系统运行、维护和改进建议。

3.  性能测试目的

3.1.  能力验证

l  比如电信计费软件,众所周知,每月二十日左右是市话交费的高峰期,全市几千个收费网点同时启动。如此众多的交易同时发生,对应用程序本身、操作系统、数据库服务器、中间件服务器、网络设备的承受力都是一个严峻的考验。

l  决策者需要模拟系统负载压力, 预见软件的并发承受力, 这是在测试阶段就应该解决的重要问题。

l  这里我们强调真实环境下检测系统性能，在实施过程中大家认为这样做会遇到很多阻力。那么在条件不允许的情况下，我们可以使用一种“模拟环境”来做测试，这种环境指与实际真实应用环境基本等级保持一致的测试环境。

3.2.  能力规划

l  检测系统性能强调对系统当前性能的评估。通过评估，可以在应用实际部署之前，预见系统负载压力承受力。

l  这种测试的意义在于指导系统总体设计，既可以避免浪费不必要的人力、物力和财力，又避免硬件和软件的设计不匹配，使系统具有更长、更健壮的生命力。

l  对于系统性能检测，有时我们所从事的工作是仅仅是被动监控一些性能指标，而预见系统负载压力承受力则不可避免会借助自动化的负载压力测试工具。

3.3.  应用程序诊断

l  内存泄漏

l  并发死锁

l  程序错误，系统异常等

3.4.  分析瓶颈、优化系统。

l  瓶颈这个术语来源于玻璃瓶与瓶身相比收缩了的部分。收缩的瓶颈将引起流量的下降，从而限制了液体流出瓶外的速度。类似的，在负载压力测试中，“瓶颈”这个术语用来描述那些限制系统负载压力性能的因素，即应用系统中导致系统性能大幅下降的原因。

l  瓶颈可能定位在硬件中，也可能定位在软件中。硬件瓶颈与软件瓶颈相比，我们更建议先解决软件瓶颈。

l  优化调整系统是发现瓶颈，故障定位之后要完成的事情，实现优化之后即可消除瓶颈，提高性能。

l  导致系统性能下降的因素来自许多方面，例如I/O过载、内存不足、数据库资源匮乏、网络速度低、应用程序架构存在缺陷，软硬件配置不恰当等等。比如是磁盘I/O导致了系统瓶颈，那么消除它的方法可能是重新设计数据库或者改进数据库访问方式。

4.  性能测试需求

性能测试需求必须要包含有多少用户（who）在什么时间（when）或者持续多久（when）进行了什么业务（what），最终需要关注怎样的指标（how）。除此以外，需要根据项目性质和性能测试的目标来获得性能测试需求的来源（where），归纳为4W1H。

4.1.  性能需求信息来源（where）

（1）开发过程相关文档。这是性能测试需求的主要来源，项目开发计划书、需求规格说明书、设计说明书、测试计划等文档都可能涉及性能测试的要求，通过收集这些资料，可以找到初步的性能需求。相关的项目干系人有客户代表、项目经理、需求分析员、系统架构设计师、产品经理等。

（2）相似项目性能需求。公司的其他产品或项目会累积出一些数据，如：**技术论坛一小时最多能发1000新帖；****博客平均每天新增800篇，以这些数据为确认新项目测试需求的基础。

（3）业界公认标准。如响应时间，根据服务器的不同和项目的具体情况可能有两类标准：

A类标准——

4秒以内，用户可以接受

4-9秒，30%用户离开

8-10秒，60%用户离开

超过10秒，90%用户离开

B类标准——

8秒，用户可接受

16秒，50%用户离开

32秒，90%用户离开

（4）用户使用模型。性能测试要通过一系列场景的执行来完成，分析用户的使用模型是获取性能测试需求的有效手段，即定义系统的典型使用方式，考虑哪些用户使用系统的哪些典型业务，在什么时间段和用户数量的估计值，因此需要和最终的用户有很好的沟通，最好能够实地考察用户的应用情况。如某OA系统的每天早上8：00会有200个用户在10分钟内登录系统；每天查询交易的高峰是在9：00-11：00和下午的14：00-16：00等。

4.2.  80～20原则估算测试强度（how）

80～20原理：每个工作日中80％的业务在20％的时间内完成。

举例：

每年业务量集中在8个月，每个月20个工作日，每个工作日8小时即每天80%的业务在1.6小时完成。去年全年处理业务约100万笔，其中15％的业务处理中每笔业务需对应用服务器提交7次请求；其中70％的业务处理中每笔业务需对应用服务器提交5次请求；其余15％的业务处理中每笔业务需对应用服务器提交3次请求。根据以往统计结果，每年的业务增量为15％，考虑到今后3年业务发展的需要，测试需按现有业务量的两倍进行。

每年总的请求数为：(100x15%x7+100x70%x5+100x15%x3)x2=1000万次/年

每天请求数为：1000/(20x8)=6.25万次/天

每秒请求数为：(62500x80%)/(8x20%x3600)=8.68次/秒

即服务器处理请求的能力应达到9次/秒。

4.2.1.   基于在线用户的性能测试需求

该需求描述方法主要基于Web应用系统的在线用户和响应时间来度量系统性能。当Web应用系统在上线后所支持的在线用户数以及操作习惯（包括操作和请求之间的延迟）很容易获得，如企业的内部应用系统，通常采用基于在线用户的方式来描述性能测试需求。以提供网上购物的Web应用系统为例，基于在线用户的性能测试需求可描述为：10个在线用户按正常操作速度访问网上购物系统的下定单功能，下定单交易的成功率是100%，而且90%的下定单请求响应时间不大于8秒；当90%的请求响应时间不大于用户的最大容忍时间20秒时，系统能支持50个在线用户。

4.2.2.   基于吞吐量的性能测试需求

该需求描述方法主要基于Web应用系统的吞吐量和响应时间来度量系统性能。当Web应用在上线后所支持的在线用户无法确定，如基于Internet的网上购物系统，可通过每天下定单的业务量直接计算其吞吐量，从而采取基于吞吐量的方式来描述性能测试需求。以网上购物系统为例，基于吞吐量的性能测试需求可描述为：网上购物系统在每分钟内需处理10笔下定单操作，交易成功率为100%，而且90%的请求响应时间不大于8秒。

 

确定性能测试需求是整个性能测试的起点和成功的重要因素。性能测试需求定义得过高，虽然确保系统上线后能满足性能需求，但可能会造成硬件资源的浪费；性能测试需求定义得过低，系统上线后可能会出现性能问题。如何通过分析系统上线后可能的用户访问行为，来获得合理的性能测试需求指标呢？

假设现有一个基于Web的办公自动化系统（简称OA系统），该系统提供公文收发和查询功能。在部署该系统前，将对该系统进行性能测试。下面将详细介绍如何分析该OA系统的使用情况，定义合理的性能测试需求。

l  如何获得OA系统的在线用户数量

在线用户数量是指在特定时间区间内，有多少用户访问Web应用系统（对应到Web服务器的Session数），根据系统可能访问用户数以及每个用户访问系统的时间长短来确定。

对于将要部署的OA系统，通过分析获得该系统有8000个注册用户，基本上所有的用户每天（8小时工作时间）都会访问OA系统，平均在线时间（从登录OA系统到退出OA系统之间的时间间隔，也可以是多次在线时间的合计）为12分钟，那么该OA系统的平均在线数（也就是Web应用Session变量数）为200个（8000 * 0.2 / 8），假设峰值在线用户数是平均在线用户数的3倍（该倍数可根据实际情况调整），则性能测试需求的在线用户数为600。

l  如何确定OA系统的性能测试用例

由于时间和资源限制，不可能对Web应用系统的所有功能进行性能测试，而是从业务的角度（如某一功能操作的用户多）和技术的角度（如某一功能虽然访问用户不多，但内部处理逻辑复杂或处理数据量大）来选择Web应用系统的特定功能作为性能测试用例。

以OA系统为例，由于所有用户都经常公文查询功能，因此确定的性能测试用例为公文查询。

l  如何确定OA系统的响应时间

响应时间的快慢直接影响了系统使用用户的满意度，采用平均响应时间来描述系统系统性能测试需求是不科学的，因为无法直接和客户的满意度挂钩。而且，在做性能测试，如果某一请求的响应时间过长或过短，将导致平均响应时间和实际情况偏离。

以OA系统为例，定义的响应时间需求为：90%（该百分比和要求的系统用户满意度相关）的查询请求响应时间不超过8秒（该时间可根据实际情况确定）。

l  如何确定OA系统的交易吞吐量

单位时间内Web应用系统需处理多少笔特定的交易可通过统计获得。以OA系统为例，假设每个用户每天（一天按8小时计算）平均会查询公文4次，那OA应用的Web服务器平均每分钟要能处理8000 * 4 / ( 60 * 8 ) =66.67笔查询公文交易，考虑到峰值因素，要求每分钟能处理66.7 * 3=200笔查询公文交易。

l  OA系统性能测试需求描述

通过前面的分析，能明确定义合理的性能测试需求。OA系统性能测试需求定义如下：

基于在线用户数的性能测试需求：600个在线用户按正常操作速度访问OA系统的查询公文功能，所有查询请求的成功率是100%，而且90%的查询请求响应时间不大于8秒。

基于吞吐量的性能测试需求：OA系统在每分钟内需处理200笔查询公文操作，交易成功率为100%，而且90%的请求响应时间不大于8秒。

 

4.3.  任务分布图（what+ when + who）

任务分布图是以一种直观的方式展示性能测试需求，描述一些交易任务在24小时内的交易情况，重点关注并发用户的数量以及典型的业务操作。如表1是某网上书店的任务分布图，从中可见：12：00~16：00的交易混合程度较高，“预定图书”任务的并发用户在14：00达到最大。如果需要进一步了解典型任务的平均值、峰值以及对web服务器、数据库服务器的压力等信息，可以建立交易混合表。

4.4.  web服务器访问日志

一般的web server有两部分日志：一是运行中的日志，它主要记录运行的一些信息，尤其是一些异常错误日志信息；二是访问日志信息，它记录访问的时间、IP、访问的资料等相关信息。为了获取系统性能测试的需求，可以分析webserver的访问日志以了解系统更多真实负载和主要的业务场景。下面介绍一下利用tomcat产生的访问日志数据所做的有效分析。

首先是配置tomcat访问日志数据，默认情况下访问日志没有打开，配置的方式如下：

编辑 $ { c a t a l i n a } / c o n f /s e r v e r . x m l 文件：(注:${catalina}是tomcat的安装目录)把以下的注释(<!-- -->)去掉即可。

<!--

<Valve className="org.apache.catalina.valves.

AccessLogValve"

directory="logs"

prefix="localhost_access_log." suffix=".txt"

pattern="common" resolveHosts="false"/>

-->

其中 d i r e c t o r y 是产生的目录 t o m c a t 安装${catalina}作为当前目录；pattern表示日志生产的格式，common是tomcat提供的一个标准设置格式。其具体的表达式为 %h %l %u %t"%r" %s %b。通过这个配置能得到的数据有：

%h 访问的用户IP地址

%l 访问逻辑用户名，通常返回'-'

%u 访问验证用户名，通常返回'-'

%t 访问日时

%r 访问的方式(post或者是get)，访问的资源和使用的http协议版本

%s 访问返回的http状态

%b 访问资源返回的流量

%T 访问所使用的时间

有了这些数据，可以根据时间段做以下的分析处理：

（1）独立IP数统计

（2）访问请求数统计

（3）访问资料文件数统计

（4）访问流量统计

（5）访问处理响应时间统计

（6）统计所有404错误页面

（7）统计所有500错误的页面

（8）统计访问最频繁页面

（9）统计访问处理时间最久页面

（10）统计并发访问频率最高的页面

如图将系统运行一段时间后获取的数据分析汇总后形成的图示，为性能测试工程师提供了非常有价值的数据，从图中可见，并发用户数在7：00-11：00之间明显增大，平均值在40左右。

4.5.  UCMLTM

U C M L T M （ U s e r C o m m u n it y M o d e l i n g Language）是一个符号集合，这些符号可以创建虚拟系统用法模型，以及描述相关参数。当把它应用到负载压力性能测试时，这些符号可用于表示工作量分配、操作流程、重点工作表、矩阵和马尔可夫链等。

负载压力性能测试工程师在决定测试中用到什么活动，以及它们发生的频率时，经常用到这些参量。通常应用SmartDraw 或者 Microsoft visio 绘制UCML，进行负载压力测试需求分析。

UCML的数据来源有两种方式：一是通过与最终用户的沟通，详细询问应用情景，根据一定的常识推理得到；二是通过分析已有的数据，如数据库的日志，web server的访问日志等获得。UCML的好处在于提供了一种易于理解、便于沟通的表现形式，尤其在应用自动化性能测试工具时，方便性能测试计划、分析、设计和实施人员的沟通。图2是一个在线书店的UCMLTM 图表，为负载压力测试提供了需求。

5.  性能测试方法

性能测试（PerformanceTesting）

负载测试（LoadTesting）

压力测试（StressTesting）

配置测试（ConfigurationTesting）

并发测试（ConcurrencyTesting）

可靠性测试（ReliabilityTesting）

失效恢复测试（FailoverTesting）

5.1.  性能测试

1.思想：通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求。且其是一种最常见的测试方法，通俗地说，这种测试方法就是要在特定的运行条件下验证系统的能力状况。

2.特点：

a. 这种方法的主要目的是验证系统是否具有系统宣称的能力。

     （该方法包括确定用户场景、给出需要关注的性能指标、测试执行和测试分析这几个步骤，这是一种完全确定了系统运行环境和测试行为的测试方法，其目的只能是依据事先的性能规划，验证系统有没有达到其宣称具有的能力。）

b.这种方法需要事先了解被测试系统典型场景，并具有确定的性能目标。

 典型场景：具有代表性的用户业务操作

 性能目标的描述方式（一般情况）：

     “要求系统在100个并发用户的条件下进行某业务操作，响应时间不超过5秒”。

c.这种方法要求在已确定的环境下运行。

（该方法的运行环境必须是确定的。软件系统的性能表现与非常多的因素相关，无法根据系统在一个环境上的表现去推断其在另一个不同环境中的表现，因此对这种验证性的测试，必须要求测试时的环境（硬件设备、软件环境、网络条件、基础数据等）都已经确定）

5.2.  负载测试

1.思想：通过在被测系统上不断增加压力，直到性能指标，例如“响应时间”超过预定指标或者某种资源使用已经达到饱和状态。

     这种测试方法可以找到系统处理的极限，为系统调优提供依据。在某些情况下，该方法也称为可量性测试。

2.目标：

     测试在一定负载情况下系统性能。

 【注：不关注稳定性，也就是说不关注长时间运行，只是得到不同负载下相关性能指标即可】

     实际中我们常从比较小的负载开始，逐渐增加模拟用户的数量（增加负载），观察不同负载下应用程序响应时间、所耗资源，直到超时或关键资源耗尽，这就是所说的负载测试，它是测试系统在不同负载情况下的性能指标。

3.特点：

a.这种性能测试方法的目的是找到系统处理能力的极限。

实现方式：通过“检测-加压-直到性能指标超过预期”的手段，其主要目的是找到系统处理能力的极限。

极限描述方式： “在给定条件下最多允许120个并发用户访问”或是“在给定条件下最多能够在1小时内处理2100笔业务”。

预期性能指标描述方式： ”响应时间不超过10秒“、”服务器平均CPU利用率低于65%等指标“。）

b.这种性能测试方法需要在给定的测试环境下进行，通常也需要考虑被测系统的业务压力量和典型场景，使得测试结果具有业务上的意义。

（该方法由于涉及到”预定的性能指标“等需要进行比较的数据，也必须在给定的测试环境下进行。另外，该方法在”加压“的时候，必须选择典型的场景，在增加压力时保证这种压力具有业务上的意义。）

c.这种性能测试方法一般用来了解系统的性能容量，或是配合性能调优来使用。

性能容量：系统在保证一定响应时间的情况下能够允许多少并发用户的访问。

配合性能调优来使用：比较调优前后的性能差异。

5.3.  压力测试

1.思想：该方法是在一定饱和状态下，例如CPU、内存等在饱和使用情况下，系统能够处理的会话能力，以及系统是否会出现错误。目的是找到系统在哪里失效以及如何失效。

2.目标：是测试在一定的负载下系统长时间运行的稳定性，尤其关注大业务量情况下长时间运行系统性能的变化（例如是否反应变慢、是否会内存泄漏导致系统逐渐崩溃、是否能恢复）

3.特点：

a.该测试方法的主要目的是检查系统处于压力情况下，应用的表现。

实现方式：通过增加访问压力（例如：增加并发的用户数量等），使应用系统的资源使用保持在一定的水平，检验此时的应用表现。

重点：检查有无出错信息产生，系统对应用的响应时间等。

b. 该性能测试一般通过模拟负载等方法使得系统的资源使用达到较高的水平。

实现方式：一般情况下，会把压力设定为“CPU使用率达75%以上、内存使用率达到70%以上”这样的描述，在这种情况下测试系统响应时间、系统有无产生错误。

以下这些都可以作为压力的依据：

 JVM（Java Virtual Machine, Java虚拟机—一个虚构的操作平台）的可用内存

 数据库的连接数

 数据库服务器利用率等

c.这种性能测试方法一般用于测试系统的稳定性

  该方法考察系统的稳定性体现在：

      如果一个系统能够在压力环境下稳定运行一段时间，那么这个系统在通常的运行条件下应该可以达到令人满意的稳定程度。

  在压力测试中，会考察系统在压力下是否会出现错误，测试中是否有内存等方面的问题。

负载测试与压力测试的区别：

Ø  负载测试：在一定的工作负荷下，给系统造成的负荷及系统响应的时间。是测试软件本身所能承受的最大负荷的性能测试；

Ø  压力测试：在一定的负荷条件下，长时间连续运行系统给系统性能造成的影响。是一种破坏性的性能测试。

性能测试、负载测试和压力测试三者的关系和区别：

     负载测试和压力测试，都属于性能测试的子集。下面举个跑步的例子进行解释。

性能测试，表示在一个给定的基准下，能执行的最好情况。例如，在没有负重的情况下，你跑100米需要花多少时间？（这里，没有负重是基准）

负载测试，也是性能测试，但是他是在不同的负载下的。对于刚才那个例子，如果扩展为：在50公斤、100公斤……等负载的情况下，你跑100米需要花多少时间？

压力测试，是在强度情况下的性能测试。对于刚才那个例子，如果改为：在一阵强风的情况下，你在负重或没有负重的情况下，跑100米需要花多少时间？

 性能测试是动力，负载测试是载重，压力测试是强度

5.4.  配置测试

1.思想：通过对被测系统的软/硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到系统各项资源的最优分配原则。

2.目标：主要用于性能调优，在经过测试获得了基准测试数据后进行环境调整（包括硬件资源，网络，应用服务器等），再将测试结果与基准测试数据进行对比，判断是否达到最佳状态。

3.特点：

a.这种性能测试方法的主要目的是了解各种不同因素对系统性能影响的程度，从而判断出最值得进行调优的操作。

配置测试（功能测试）：是针对软件而言，其主要目的是验证软件能否在不同的软硬件环境中正常运行，其主要是功能上的验证。

配置测试（性能测试）：是在性能测试领域内的配置测试方法，其主要目的是了解各种因素对系统性能的影响程度，从而判断出对性能影响最大的因素。

b.这种性能测试方法一般在对系统性能状况有初步了解后进行。

实现条件：在确定的环境和操作步骤、确定的压力条件下进行。

实现方式：在每次执行测试时更换、扩充硬件设备，调整网络环境，调整应用服务器和数据库服务器的参数设置，比较每次测试结果，从而确定各个因素对系统性能的影响，找出影响最大的因素。

c.这种性能测试方法一般用于性能调优和规划能力。

性能调优领域：该方法可以实现调优的持续进行。

规划能力领域：该方法也常被用来评估“该如何调整才能实现系统的扩展性”。

5.5.  并发测试

1.思想：通过模拟用户的并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。

2.特点：

a.这种性能测试方法的主要目的是发现系统中可能隐藏的并发访问时的问题。

  eg：我们的应用在实验室一切正常，但一交付给用户，在用户量增大以后，就经常会出现各种莫名其妙的问题。

  解决这类问题的方法：在实验室进行仔细的并发模拟测试。

b.这种性能测试方法主要关注系统可能存在的并发问题，例如系统中的内存泄漏、线程锁和资源争用方面的问题。

（该测试在测试过程中主要关注系统中的内存泄漏、死锁等问题。下表给出了并发测试主要关注的问题。）

c.这种性能测试方法可以在开发的各个阶段使用，需要相关的测试工具的配合和支持。

     该方法可以针对整个系统进行，也可以仅仅为了验证某种架构或是设计的合理性进行，因此其可以在开发的各个阶段使用。

      一般来说，并发测试除了需要性能测试工具进行并发负载的产生外，还需要一些其他工具进行代码级别的检查和定位。Compuware公司的DevPartner工具，ej-technologie公司的JProfile工具，Quest公司的JProbe工具等可以在这方面发挥作用。）

5.6.  可靠性测试

1.思想：通过给系统加载一定的业务能力（例如：资源在70%-90%的使用率）的情况下，让应用持续运行一段时间，测试系统在这种条件下是否能够稳定运行。

  注：这里所说的“可靠性测试”并不等同于“获得软件的可靠性”。软件的可靠性是一个很大的课题，我们不能也不打算在这里展开讲解，总而言之，这里的“可靠性测试”仅仅是让软件在大压力环境下运行较长的时间，从而估算系统是否能在平均压力下持续正常工作。

2.特点：

a.这种性能测试方法的主要目的是验证系统是否支持长期稳定的运行。

     从直观上来说，在大的压力下进行一个较长时间的测试，如果系统在测试中不出现问题或是不好的征兆，基本上可以说明系统具备长期稳定运行的条件。

b.这种性能测试方法需要在压力下持续一段时间的运行。

     既然是稳定性测试，肯定需要至少让系统在压力下运行一段时间。这段时间的具体数值需要根据系统的稳定性要求确定。对一般的非关键的大型应用来说，一般让系统处于可能的峰值压力下，进行2-3天的稳定性测试基本上就已经够了。

c.测试过程中需要关注系统的运行状况。

     在运行过程中，一般需要关注系统的内存使用状况，系统的其他资源使用有无明显的变化，以及系统响应时间有无明显变化。如果测试过程中发现，随着时间的推移，响应时间有明显的变化，或是系统资源使用率有明显波动，都可能是系统不稳定的征兆，需要重点关注。

5.7.  失效恢复测试

1.思想：针对有冗余备份和负载均衡的系统设计的，这种测试方法可以用来检验如果系统局部发生故障，用户是否能够继续使用系统；以及如果这种情况发生，用户将受到多大程度的影响。

2.特点：

a.这种性能测试方法的主要目的是验证在局部故障情况下，系统能否继续使用。

（一般的关键业务系统都会采用热备份或是负载均衡的方式来实现。这种业务系统一般要求即使有一台或几台服务器出现问题，应用系统仍然能够正常执行业务。该方法可以在测试中模拟一台或几台设备故障，验证预期的恢复技术是否能够发挥作用。）

b.这种性能测试方法还需要指出，当问题发生时“能支持多少用户访问”的结论和“采取何种应急措施”的方案。

（当一台或多台服务器出现问题后，系统一定会受到性能甚至是功能上的部分损失。因此，必须在测试中明确得出“当问题发生时，系统还能支持多少用户的并发访问？是否要采取某些必要措施？”这种问题的明确答案。）

c.一般来说，只有对系统持续运行指标有明确要求的系统才需要进行这种类型的测试。

（不是所有的系统都需要进行这种类型的测试，尤其是并没有明确给出系统持续运行指标的系统。）

6.  负载压力测试指标

我们可以选择的指标包括以下几类：

客户端交易处理性能指标；

服务器资源监控指标，例如：UNIX；

数据库资源监控指标，例如：Oracle；

Web服务器监控指标，例如：Apache；

中间件监控指标，例如：Websphere等等。

 

       这里要说的是：指标的选择并非越多越好。选取什么样的指标要以测试需求为准，想得到什么类型的性能值就选择相应的指标。过多的无用指标会大量占用各种资源，并对测试结果产生影响。

6.1.  交易处理性能指标

Ø  并发用户数

Ø  平均事务响应时间

Ø  每秒事务数

Ø  每秒事务总数

Ø  每秒点击次数

Ø  吞吐量

Ø  HTTP 状态代码摘要

Ø  每秒HTTP 响应数

Ø  每秒下载页面数

6.2.  UNIX操作系统资源监控

6.3. 
Windows操作系统资源监控

6.4.  Oracle资源监控

6.5.  Web服务器监控

Apache

IIS

6.6.  中间件服务器监控 -WebSphere

Run Time Resources

 

TransactionData

 

7.  开发性能测试脚本

    在确定Web应用系统性能测试需求后，就要根据性能测试需求中确定的功能开发性能测试脚本。比如，针对前面定义的网上购物系统的性能测试需求，将开发下定单功能的性能测试脚本。　
　　性能测试脚本是描述单个浏览器向Web服务器发送的HTTP请求序列。每个性能测试工具（如IBM Rational Performance Tester， LoadRunner）所提供的测试脚本语法是不同的。测试人员利用性能测试工具可从头手工编写测试脚本，也可以通过录制浏览器和Web服务器之间的网络通信数据而自动形成测试脚本。　
　　任何性能测试工具都不能保证录制形成的性能测试脚本的正确性，测试人员应通过在单用户下运行性能测试脚本对其正确性进行验证。测试脚本不正确的一个重要原因就是脚本的数据关联不正确，也就是并没完全建立一个测试请求和前面的响应内容之间的关联。测试脚本HTTP请求和响应之间的数据关联是否正确的一个重要标准是单用户运行脚本，脚本能完成期望的功能。　
　　在完成性能测试脚本的数据关联后，需要对脚本进行参数化，也就是把脚本中的某些请求数据替换成变量，变量的值来于一个独立的数据文件，从而保证在多虚拟用户运行脚本的情况下，每个虚拟用户所提交的数据是不同的。　
　　此外，为了测试Web应用的可靠性，还需要对请求所收到的响应进行验证（比如验证响应的HTTP返回码或验证响应的内容），便于性能测试完成后统计请求成功率。

8.  建立性能测试负载模型

性能测试负载模型定义了测试工具如何向Web应用系统提交请求，包括向Web应用系统发送请求的虚拟用户数，每个虚拟用户发送请求的速度和频率。针对前面介绍的网上购物系统的性能测试需求，在性能测试工具中定义的性能测试负载模型应包括如下信息：

虚拟用户数：性能测试不仅仅是执行一次，而且每次执行时虚拟用户数也不固定，因此在性能测试负载模型中定义的虚拟用户数将在测试执行时进行设置。

虚拟用户发送请求的思考时间和迭代次数：虚拟用户发送请求的思考时间长短是决定Web应用系统负载量的重要因素之一，而迭代次数将决定性能测试的执行持续时间。对基于在线用户的性能测试需求，将基于录制脚本时记录的思考时间，而且由于现实中不同用户访问系统的思考时间不同，可把思考时间设置为在一定范围内的随机值。对于基于吞吐量的性能测试需求，将把思考时间设置为零，此时Web应用系统的在线用户数量将等于并发用户数。同时，为了避免性能测试压力的随机性，将增加请求的迭代次数来增加测试执行持续时间，从而获得系统在稳定压力下的性能数据。

虚拟用户启动模式：在现实中，Web应用系统的用户不太可能同时做相同的操作，因此为了让Web应用系统所承担的压力随时间均匀分布，建议虚拟用户依次启动，同时也避免大量用户同时登录造成系统阻塞。以10个虚拟用户模拟下定单为例，可设置每个虚拟用户间隔30秒启动，这样10个虚拟用户可在5分钟后完成启动，并保证10个虚拟用户不会在同一时刻下定单，从而更符合实际情况。

9.  性能测试环境

9.1.  性能测试环境包含内容：

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

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

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

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

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

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

l  软件环境

Ø  版本一致性

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

Ø  配置一致性

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

l  使用场景的一致性

Ø  基础数据的一致性

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

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

Ø  使用模式的一致性

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

9.3.  性能测试环境的实施策略  

l  通过建模的方式实现低端硬件对高端硬件的模拟

　　通过配置测试来计算不同配置下的硬件性能和系统处理能力的关系，从而推导出满足系统性能的真实配置情况，这种模拟需要精确的建模，模型的采样点越多，那么得到的结果越精确，从而将在低端配置下的性能指标通过该模型转化为高端配置下的最终预计性能指标。

　　例如：搭建一个低端环境，首先需要对这个环境的CPU和内存进行单独的性能基准测试，同过在不同的配置的性能测试，得到一个基准信息列表，当然，在进行这个性能测试的过程中，我们要确定硬件是系统的瓶颈。如果只用一个CUP，在性能测试过程中，其使用率很低，但得到的性能数据都非常底，这起码说明CUP不是系统的平静，这种情况下就无法得到想要的基准值。

如上图，在一颗CPU情况下，运行100个用户且CUP使用率接近饱和（100%）。在增加至两颗CUP的情况下，可以运行190个用户且UPU使用率接近饱和（100%），以此做记录，那么我们就可以推算出运行800个用户需要多少颗CUP。

如果你在实际应用中使用的CUP型号及其频率并非完全一样，这个时候可以使用EVEREST工具计算每种CUP的得分，对其性能进行评估。

内存也可以使用此方法进行测试推导，这里需要我们多进行试验，对硬件的性能以及对整个项目的结构都要做深入的了解，以便尽量减少误差。

l  通过集群的方式计算

　　对于较大的系统来说，单台服务器的处理能力是有限的，通常都会采用集群的方式来进行负载均衡，完成对海量请求的处理。虽然无法获得整体集群的测试环境，但是可以对集群上的一个节点进行性能测试，得出该节点的处理能力，再计算每增加一个节点的性能损失，同样也可以能过建模的方式得到大型负载均衡情况下的预计性能指标。

　　例如:首先在单台服务器上获得具体的性能指标，每台服务器能够承受500用户并发，平均TPS为60，响应时间为2秒，接着，添加负载均衡策略，再次测试负载策略下的数据损耗。得出数据后添加1台负载均衡服务器，测试在两台服务器下每台服务器的性能指标，以此类推，可以得到下表：

随着负载均衡服务器的添加，平均每台服务器的处理能力会逐渐稳定，从而了解在什么情况下需要多少台负载均衡服务器。

对于测试环境的搭建，建议生成专门的文档进行管理，并进行配置管理，确保对测试环境做到基线控制。