性能测试的概念

性能测试

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常

负载条件来对系统的各项性能指标进行测试。负载测试和压力测试

都属于性能测试，两者可以结合进行。通过负载测试，确定在各种

工作负载下系统的性能，目标是测试当负载逐渐增加时一，系统各项

性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不

能接收的性能点，来获得系统能提供的最大服务级别的测试。

一、概述

性能测试在软件的质量保证中起着重要的作用，它包括的测试

内容丰富多样。中国软件评测中心将性能测试概括为三个方面：应

用在客户端性能的测试、应用在网络上性能的测试和应用在服务器

端性能的测试。通常情况下，三方面有效、合理的结合，可以达到

对系统性能全面的分析和瓶颈的预测。

・应用在客户端性能的测试

应用在客户端性能测试的目的是考察客户端应用的性能，测试

的入口是客户端。它主要包括并发性能测试、疲劳强度测试、大数

据量测试和速度测试等，其中并发性能测试是重点。

并发性能测试是重点

并发性能测试的过程是一个负载测试和压力测试的过程，即逐

渐增加负载，直到系统的瓶颈或者不能接收的性能点，通过综合分

析交易执行指标和资源监控指标来确定系统并发性能的过程。负载

测试(LoadTesting)是确定在各种工作负载下系统的性能，目标

是测试当负载逐渐增加时.，系统组成部分的相应输出项，例如通过

量、响应时间、CPU负载、内存使用等来决定系统的性能。负载

测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用，

从而来确定能够接收的性能过程。压力测试(StressTesting)是

通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提

供的最大服务级别的测试。

并发性能测试的目的主要体现在三个方面：以真实的业务为依

据，选择有代表性的、关键的业务操作设计测试案例，以评价系统

的当前性能；当扩展应用程序的功能或者新的应用程序将要被部署

时一，负载测试会帮助确定系统是否还能够处理期望的用户负载，以

预测系统的未来性能；通过模拟成百上千个用户，重复执行和运行

测试，可以确认性能瓶颈并优化和调整应用，目的在于寻找到瓶颈

问题。

当一家企业自己组织力量或委托软件公司代为开发一套应用

系统的时候，尤其是以后在生产环境中实际使用起来，用户往往会产

生疑问，这套系统能不能承受大量的并发用户同时访问？这类问题

最常见于采用联机事务处理(OLTP)方式数据库应用、Web浏览和

视频点播等系统。这种问题的解决要借助于科学的软件测试手段和

先进的测试工具。

举例说明：电信计费软件

众所周知，每月20日左右是市话交费的高峰期，全市儿千个收

费网点同时启动。收费过程一般分为两步，首先要根据用户提出的

电话号码来查询出其当月产生费用，然后收取现金并将此用户修改

为已交费状态。一个用户看起来简单的两个步骤，但当成百上千的

终端，同时执行这样的操作时，情况就大不一样了，如此众多的交

易同时发生，对应用程序本身、操作系统、中心数据库服务器、中

间件服务器、网络设备的承受力都是一个严峻的考验。决策者不可

能在发生问题后才考虑系统的承受力，预见软件的并发承受力，这

是在软件测试阶段就应该解决的问题。

目前，大多数公司企业需要支持成百上千名用户，各类应用环

境以及由不同供应商提供的元件组装起来的复杂产品，难以预知的

用户负载和愈来愈复杂的应用程序，使公司担忧会发生投放性能

差、用户遭受反应慢、系统失灵等问题。其结果就是导致公司收益

的损失。

如何模拟实际情况呢？找若干台电脑和同样数目的操作人员

在同一时刻进行操作，然后拿秒表记录下反应时间？这样的手工

作坊式的测试方法不切实际，且无法捕捉程序内部变化情况，这样

就需要压力测试工具的辅助。

测试的基本策略是自动负载测试，通过在一台或儿台PC机上

模拟成百或上千的虚拟用户同时执行业务的情景，对应用程序进行

测试，同时记录下每一事务处理的时间、中间件服务器峰值数据、

数据库状态等。通过可重复的、真实的测试能够彻底地度量应用的

可扩展性和性能，确定问题所在以及优化系统性能。预先知道了系

统的承受力，就为最终用户规划整个运行环境的配置提供了有力的

依据。

并发性能测试前的准备工作

测试环境：配置测试环境是测试实施的一个重要阶段，测试环

境的适合与否会严重影响测试结果的真实性和正确性。测试环境包

括硬件环境和软件环境，硬件环境指测试必需的服务器、客户端、

网络连接设备以及打印机/扫描仪等辅助硬件设备所构成的环境；

软件环境指被测软件运行时的操作系统、数据库及其他应用软件构

成的环境。

一个充分准备好的测试环境有三个优点：一个稳定、可重复的

测试环境，能够保证测试结果的正确；保证达到测试执行的技术需

求；保证得到正确的、可重复的以及易理解的测试结果。

测试工具：并发性能测试是在客户端执行的黑盒测试，一般不

采用手工方式，而是利用工具采用自动化方式进行。目前，成熟的

并发性能测试工具有很多，选择的依据主要是测试需求和性能价格

比。著名的并发性能测试工具有QALoad、LoadRunner、

BenchmarkFactory和Webstress等。这些测试工具都是自动化负

载测试工具，通过可重复的、真实的测试，能够彻底地度量应用的

可扩展性和性能，可以在整个开发生命周期、跨越多种平台、自动

执行测试任务，可以模拟成百上千的用户并发执行关键业务而完成

对应用程序的测试。

测试数据：在初始的测试环境中需要输入一些适当的测试数

据，目的是识别数据状态并且验证用于测试的测试案例，在正式的

测试开始以前对测试案例进行调试，将正式测试开始时的错误降到

最低。在测试进行到关键过程环节时，非常有必要进行数据状态的

备份。制造初始数据意味着将合适的数据存储下来，需要的时候恢

复它，初始数据提供了一个基线用来评估测试执行的结果。

在测试正式执行时，还需要准备业务测试数据，比如测试并发

查询业务，那么要求对应的数据库和表中有相当的数据量以及数据

的种类应能覆盖全部业务。

模拟真实环境测试，有些软件,特别是面向大众的商品化软件,

在测试时常常需要考察在真实环境中的表现。如测试杀毒软件的扫

描速度时一，硬盘上布置的不同类型文件的比例要尽量接近真实环

境，这样测试出来的数据才有实际意义。

并发性能测试的种类与指标

并发性能测试的种类取决于并发性能测试工具监控的对象，以

QALoad自动化负载测试工具为例。软件针对各种测试目标提供了

DB2、DCOM、ODBC、ORACLE、NETLoad、Corba.QARun、

SAP、SQLServer、Sybase>Telnet、TUXEDO、UNIFACE、

WinSock、WWW>JavaScript等不同的监控对象，支持Windows

和UNIX测试环境。

最关键的仍然是测试过程中对监控对象的灵活应用，例如目前

三层结构的运行模式广泛使用，对中间件的并发性能测试作为问题

被提到议事日程上来，许多系统都采用了国产中间件，选择Java

Script监控对象，手工编写脚本，可以达到测试目的。

采用自动化负载测试工具执行的并发性能测试，基本遵循的测

试过程有：测试需求与测试内容，测试案例制定，测试环境准备，

测试脚本录制、编写与调试，脚本分配、回放配置与加载策略，测

试执行跟踪，结果分析与定位问题所在，测试报告与测试评估。

并发性能测试监控的对象不同，测试的主要指标也不相同，主

要的测试指标包括交易处理性能指标和UNIX资源监控。其中，交

易处理性能指标包括交易结果、每分钟交易数、交易响应时间（Min：

最小服务器响应时间；Mean：平均服务器响应时间；Max：最大

服务器响应时间；StdDev：事务处理服务器响应的偏差，值越大,

偏差越大；Median：中值响应时间；90%：90%事务处理的服务

器响应时间）、虚拟并发用户数。

应用实例：“新华社多媒体数据库V1.0”性能测试

中国软件评测中心（CSTC）根据新华社技术局提出的《多媒

体数据库（一期）性能测试需求》和GB/T17544《软件包质量要

求和测试》的国家标准，使用工业标准级负载测试工具对新华社使

用的“新华社多媒体数据库V1.0”进行了性能测试。

性能测试的目的是模拟多用户并发访问新华社多媒体数据库，

执行关键检索业务，分析系统性能。

性能测试的重点是针对系统并发压力负载较大的主要检索业

务，进行并发测试和疲劳测试，系统采用B/S运行模式。并发测试

设计了特定时间段内分别在中文库、英文库、图片库中进行单检索

词、多检索词以及变检索式、混合检索业务等并发测试案例。疲劳

测试案例为在中文库中并发用户数200,进行测试周期约8小时的

单检索词检索。在进行并发和疲劳测试的同时，监测的测试指标包

括交易处理性能以及UNIX（Linux）、Oracle>Apache资源等。

测试结论：在新华社机房测试环境和内网测试环境中，100M

带宽情况下，针对规定的各并发测试案例，系统能够承受并发用户

数为200的负载压力，最大交易数/分钟达到78.73,运行基本稳

定，但随着负载压力增大，系统性能有所衰减。

系统能够承受200并发用户数持续周期约8小时的疲劳压力,

基本能够稳定运行。

通过对系统UNIX(Linux)、Oracle和Apache资源的监控，

系统资源能够满足上述并发和疲劳性能需求，且系统硬件资源尚有

较大利用余地。

当并发用户数超过200时-，监控至I」HTTP500、connect和超

时错误，且Web服务器报内存溢出错误，系统应进一步提高性能,

以支持更大并发用户数。

建议进一步优化软件系统，充分利用硬件资源，缩短交易响应

时间。

疲劳强度与大数据量测试

疲劳测试是采用系统稳定运行情况下能够支持的最大并发用

户数，持续执行一段时间业务，通过综合分析交易执行指标和资源

监控指标来确定系统处理最大工作量强度性能的过程。

疲劳强度测试可以采用工具自动化的方式进行测试，也可以手

工编写程序测试，其中后者占的比例较大。

一般情况下以服务器能够正常稳定响应请求的最大并发用户

数进行一定时间的疲劳测试，获取交易执行指标数据和系统资源监

控数据。如出现错误导致测试不能成功执行，则及时调整测试指标,

例如降低用户数、缩短测试周期等。还有一种情况的疲劳测试是对

当前系统性能的评估，用系统正常业务情况下并发用户数为基础，

进行一定时间的疲劳测试。

大数据量测试可以分为两种类型：针对某些系统存储、传输、

统计、查询等业务进行大数据量的独立数据量测试；与压力性能测

试、负载性能测试、疲劳性能测试相结合的综合数据量测试方案。

大数据量测试的关键是测试数据的准备，可以依靠工具准备测试数

据。

速度测试目前主要是针对关键有速度要求的业务进行手工测

速度，可以在多次测试的基础上求平均值，可以和工具测得的响应

时间等指标做对比分析。

•应用在网络上性能的测试

应用在网络上性能的测试重点是利用成熟先进的自动化技术

进行网络应用性能监控、网络应用性能分析和网络预测。

网络应用性能分析

网络应用性能分析的目的是准确展示网络带宽、延迟、负载和

TCP端口的变化是如何影响用户的响应时间的。利用网络应用性

能分析工具，例如ApplicationExpert,能够发现应用的瓶颈，我

们可知应用在网络上运行时在每个阶段发生的应用行为，在应用线

程级分析应用的问题。可以解决多种问题：客户端是否对数据库服

务器运行了不必要的请求？当服务器从客户端接受了一个查询，应

用服务器是否花费了不可接受的时间联系数据库服务器？在投产

前预测应用的响应时间；利用ApplicationExpert调整应用在广域

网上的性能；ApplicationExpert能够让你快速、容易地仿真应用

性能，根据最终用户在不同网络配置环境下的响应时间，用户可以

根据自己的条件决定应用投产的网络环境。

网络应用性能监控

在系统试运行之后，需要及时准确地了解网络上正在发生什么

事情;什么应用在运行，如何运行;多少PC正在访问LAN或WAN；

哪些应用程序导致系统瓶颈或资源竞争，这时网络应用性能监控以

及网络资源管理对系统的正常稳定运行是非常关键的。利用网络应

用性能监控工具，可以达到事半功倍的效果，在这方面我们可以提

供的工具是NetworkVantage。通俗地讲，它主要用来分析关键应

用程序的性能，定位问题的根源是在客户端、服务器、应用程序还

是网络。在大多数情况下用户较关心的问题还有哪些应用程序占用

大量带宽，哪些用户产生了最大的网络流量，这个工具同样能满足

要求。

网络预测

考虑到系统未来发展的扩展性，预测网络流量的变化、网络结

构的变化对用户系统的影响非常重要。根据规划数据进行预测并及

时提供网络性能预测数据。我们利用网络预测分析容量规划工具

PREDICTOR可以作到：设置服务水平、完成日网络容量规划、离

线测试网络、网络失效和容量极限分析、完成日常故障诊断、预测

网络设备迁移和网络设备升级对整个网络的影响。

从网络管理软件获取网络拓扑结构、从现有的流量监控软件获

取流量信息（若没有这类软件可人工生成流量数据），这样可以得

到现有网络的基本结构。在基本结构的基础上，可根据网络结构的

变化、网络流量的变化生成报告和图表，说明这些变化是如何影响

网络性能的。PREDICTOR提供如下信息：根据预测的结果帮助

用户及时升级网络，避免因关键设备超过利用阀值导致系统性能下

降；哪个网络设备需要升级，这样可减少网络延迟、避免网络瓶颈;

根据预测的结果避免不必要的网络升级。

・应用在服务器上性能的测试

对于应用在服务器上性能的测试，可以采用工具监控，也可以

使用系统本身的监控命令，例如Tuxedo中可以使用Top命令监控

资源使用情况。实施测试的目的是实现服务器设备、服务器操作系

统、数据库系统、应用在服务器上性能的全面监控，测试原理如下

图。

UNIX资源监控指标和描述

监控指标描述

平均负载系统正常状态下，最后60秒同步进程的平均个数

冲突率在以太网上监测到的每秒冲突数

进程/线程交换率进程和线程之间每秒交换次数

CPU利用率CPU占用率（％）

磁盘交换率磁盘交换速率

接收包错误率接收以太网数据包时每秒错误数

包输入率每秒输入的以太网数据包数目

中断速率CPU每秒处理的中断数

输出包错误率发送以太网数据包时每秒错误数

包输入率每秒输出的以太网数据包数目

读入内存页速率物理内存中每秒读入内存页的数目

写出内存页速率每秒从物理内存中写到页文件中的内存页数

目或者从物理内存中删掉的内存页数目

内存页交换速率每秒写入内存页和从物理内存中读出页的个

数

进程入交换率交换区输入的进程数目

进程出交换率交换区输出的进程数目

系统CPU利用率系统的CPU占用率（％）

用户CPU利用率用户模式下的CPU占用率（％）

磁盘阻塞磁盘每秒阻塞的字节数

二、为什么进行性能测试？

目的是验证软件系统是否能够达到用户提出的性能指标（需求

规格说明书），同时发现软件系统中存在的性能瓶颈，优化软件，

最后起到优化系统的目的。

包括以下儿个方面

1.评估系统的能力，测试中得到的负荷和响应时间数据可以被用

于验证所计划的模型的能力，并帮助作出决策。

2.识别体系中的弱点：受控的负荷可以被增加到一个极端的水平

（峰值）,并突破它，从而修复体系的瓶颈或薄弱的地方。

3.系统调优：重复运行测试，验证调整系统的活动得到了预期的

结果，从而改进性能。

检测软件中的问题：长时间的测试执行可导致程序发生由于内存泄

露引起的失败，揭示程序中的隐含的问题或冲突。

4.验证稳定性（resilience）可靠性（reliability）：在一个生产

负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足

要求的唯一方法。

性能测试类型包括负载测试，强度测试，容量测试等

负载测试：负载测试是一种性能测试指数据在超负荷环境中运

行，程序是否能够承担。

强度测试：强度测试是一种性能测试，他在系统资源特别低

的情况下软件系统运行情况。

容量测试：确定系统可处理同时在线的最大用户数（对服务器

有请求和无请求）

观察指标：

性能测试主要是通过自动化的测试工具模拟多种正常、峰值以

及异常负载条件来对系统的各项性能指标进行测试。负载测试和压

力测试都属于性能测试，两者可以结合进行。通过负载测试，确定

在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系

统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈

或者不能接收的性能点，来获得系统能提供的最大服务级别的测

试。

在实际中作中我们经常会对两种类型软件进行测试:bs和cs,

这两方面的性能指标一般需要哪些内容呢？

Bs结构程序一般会关注的通用指标如下（简）：

Web服务器指标：

*AvgRps:平均每秒钟响应次数=总请求时间/秒数；

*Avgtimetolastbyteperterstion（mstes）:平均每秒业务角本

的迭代次数，有人会把这两者混淆;

*SuccessfulRounds：成功的请求；

*FailedRounds：失败的请求；

*SuccessfulHits：成功的点击次数；

*FailedHits：失败的点击次数；

*HitsPerSecond：每秒点击次数；

*SuccessfulHitsPerSecond：每秒成功的点击次数；

*FailedHitsPerSecond：每秒失败的点击次数；

*AttemptedConnections：尝试链接数；

CS结构程序，由于一般软件后台通常为数据库，所以我们更注重

数据库的测试指标：

*User0Connections：用户连接数，也就是数据库的连接数量；

*Numberofdeadlocks：数据库死锁；

*ButterCachehit：数据库Cache的命中情况

当然，在实际中我们还会察看多用户测试情况下的内存，

CPU,系统资源调用情况。这些指标其实是引申出来性能测试中的

一种：竞争测试。什么是竞争测试，软件竞争使用各种资源（数据

纪录，内存等），看他与其他相关系统对资源的争夺能力。

我们知道软件架构在实际测试中制约着测试策略和工具的选

择。如何选择性能测试策略是我们在实际工作中需要了解的。一般

软件可以按照系统架构分成儿种类型：

c/s

client/server客户端/服务器架构

基于客户端/服务器的三层架构

基于客户端/服务器的分布式架构

b/s

基于浏览器/Web服务器的三层架构

基于中间件应用服务器的三层架构I

基于Web服务器和中间件的多层架构I

三、性能测试的步骤

在每种不同的系统架构的实施中，开发人员可能选择不同的实

现方式，造成实际情况纷繁复杂。我们不可能对每种技术都详细解

说，这里只是介绍一种方法提供给你如何选择测试策略，从而帮助

分析软件不同部分的性能指标，进而分析出整体架构的性能指标和

性能瓶颈。

由于工程和项目的不同，所选用的度量，评估方法也有不同之

处。不过仍然有一些通用的步骤帮助我们完成一个性能测试项目。

步骤如下

1.制定目标和分析系统（用户访问量大、数据量比较大、,重点

功能模块）

2.选择测试度量的方法

3.学习的相关技术和工具

4.制定评估标准

5.设计测试用例

6.运行测试用例

7.分析测试结果

•制定目标和分析系统

每一个性能测试计划中第一步都会制定目标和分析系统构成。

只有明确目标和了解系统构成才会澄清测试范围，知道在测试中要

掌握什么样的技术。

目标:

1.确定客户需求和期望

2.实际业务需求

3.系统需求

系统组成

系统组成这里包含儿方面含义：系统类别，系统构成，系统功

能等。了解这些内容的本质其实是帮助我们明确测试的范围，选者

适当的测试方法来进行测试。

系统类别：分清系统类别是我们掌握什么样的技术的前提，掌

握相应技术做性能测试才可能成功。例如：系统类别是bs结构，

需要掌握http协议，java,html等技术。或者是cs结构，可能

要了解操作系统，winsock,com等。所以甄别系统类别对于我们

来说很重要。

系统构成：硬件设置，操作系统设置是性能测试的制约条件，

一般性能测试都是利用测试工具模仿大量的实际用户操作，系统在

超负荷情形下运作。不同的系统构成性能测试就会得到不同的结

果。

系统功能：系统功能指系统提供的不同子系统，办公管理系统

中的公文子系统，会议子系统等，系统工能是性能测试中要模拟的

环节，了解这些是必要的。

・选择测试度量的方法

经过第一步，将会对系统有清醒的认识。接下来我们将把精力放在

软件度量上，收集系统相关的数据。

度量的相关方面：

*制定规范

*制定相关流程，角色，职责

*制定改进策略

*制定结果对比标准

•学习的相关技术和工具

性能测试是通过工具，模拟大量用户操作，对系统增加负载。

所以需要掌握一定的工具知识才能进行性能测试。大家都知道性能

测试工具一般通过winsock,http等协议纪录用户操作。而协议选择

是基于软件的系统架构实现（web一般选择http协议,cs选择

winsock协议），不同的性能测试工具，脚本语言也不同，比如

rationalrobot中vu脚本用类c语言实现。

开展性能测试需要对各种性能测试工具进行评估，因为每一种

性能测试工具都有自身的特点，只有经过工具评估，才能选择符合

现有软件架构的性能测试工具。确定测试工具后，需要组织测试人

员进行工具的学习，培训相关技术。

・制定评估标准

任何测试的目的都是确保软件符合预先规定的目标和要求。

性能测试也不例外。所以必须制定一套标准。

通常性能测试有四种模型技术可用于评估:

*线性投射：用大量的过去的，扩展的或者将来可能发生的

数据组成散布图，利用这个图表不断和系统的当前状况对比。

*分析模型：用排队论公式和算法预测响应时间，利用描述

工作量的数据和系统本质关联起来

*模仿：模仿实际用户的使用方法测试你的系统

*基准：定义测试和你最初的测试作为标准，利用它和所有

后来进行的测试结果进行对比

•设计测试用例

设计测试用例是在了解软件业务流程的基础上。设计测试用例

的原则是受最小的影响提供最多的测试信息，设计测试用例的目标

是一次尽可能的包含多个测试要素。这些测试用例必须是测试工具

可以实现的，不同的测试场景将测试不同的功能。因为性能测试不

同于平时的测试用例，尽可能把性能测试用例设计的复杂，才有可

能发现软件的性能瓶颈。

・运行测试用例

通过性能测试工具运行测试用例。同一环境下作的性能测试得

到的测试结果是不准确的，所以在运行这些测试用例的时候，需要

用不同的测试环境，不同的机器配置上运行。

・分析测试结果

运行测试用例后，收集相关信息，进行数据统计分析，找到性

能瓶颈。通过排除误差和其他因素，让测试结果体现接近真实情况。

不同的体系结构分析测试结果的方法也不同，bs结构我们会分析

网络带宽，流量对用户操作响应的影响，而CS结构我们可能更关

心会系统整体配置对用户操作的影响。

四、性能测试方法

对于企业应用程序，有许多进行性能测试的方法，其中一些方

法实行起来要比其他方法困难。所要进行的性能测试的类型取决于

想要达到的结果。例如，对于可再现性，基准测试是最好的方法。

而要从当前用户负载的角度测试系统的上限，则应该使用容量规划

测试。本文将介绍儿种设置和运行性能测试的方法，并讨论这些方

法的区别。

如果不进行合理的规划，对J2EE应用程序进行性能测试将会

是一项令人望而生畏且有些混乱的任务。因为对于任何的软件开发

流程，都必须收集需求、理解业务需要，并在进行实际测试之前设

计出正式的进度表。性能测试的需求由业务需要驱动，并由一组用

例阐明。这些用例可以基于历史数据（例如，服务器一周的负载模

式）或预测的近似值。弄清楚需要测试的内容之后，就需要知道如

何进行测试了。

在开发阶段前期，应该使用基准测试来确定应用程序中是否出

现性能倒退。基准测试可以在一个相对短的时间内收集可重复的结

果。进行基准测试的最好方法是，每次测试改变一个且只改变一个

参数。例如，如果想知道增加JVM内存是否会影响应用程序的性

能，就逐次递增JVM内存（例如，从1024MB增至1224MB,

然后是1524MB,最后是2024MB）,在每个阶段收集结果和环

境数据，记录信息，然后转到下一阶段。这样在分析测试结果时就

有迹可循.。下一小节我将介绍什么是基准测试，以及运行基准测试

的最佳参数。

开发阶段后期，在应用程序中的bug已经被解决，应用程序达

到一种稳定状态之后，可以运行更为复杂的测试，确定系统在不同

的负载模式下的表现。这些测试被称为容量规划测试、渗入测试

（soaktest）＞峰谷测试（peak-resttest）,它们旨在通过测试应用程

序的可靠性、健壮性和可伸缩性来测试接近于现实世界的场景。对

于下面的描述应该从抽象的意义上理解，因为每个应用程序的使用

模式都是不同的。例如，容量规划测试通常都使用较缓慢的

ramp-up（下文有定义），但是如果应用程序在一天之中的某个时

段中有快速突发的流量，那么自然应该修改测试以反映这种情况。

但是，要记住，因为更改了测试参数（比如ramp-up周期或用户

的考虑时间-hink-time））,测试的结果肯定也会改变。一个不错的

方法是，运行一系列的基准测试，确立一个已知的可控环境，然后

再对变化进行比较。

基准测试

基准测试的关键是要获得一致的、可再现的结果。可再现的结

果有两个好处：减少重新运行测试的次数；对测试的产品和产生的

数字更为确信。使用的性能测试工具可能会对测试结果产生很大影

响。假定测试的两个指标是服务器的响应时间和吞吐量，它们会受

到服务器上的负载的影响。服务器上的负载受两个因素影响：同时

与服务器通信的连接（或虚拟用户）的数目，以及每个虚拟用户请

求之间的考虑时间的长短。很明显，与服务器通信的用户越多，负

载就越大。同样，请求之间的考虑时间越短，负载也越大。这两个

因素的不同组合会产生不同的服务器负载等级。记住，随着服务器

上负载的增加，吞吐量会不断攀升，直到到达一个点。

注意，吞吐量以稳定的速度增长，然后在某一个点上稳定下来。

在某一点上，执行队列开始增长，因为服务器上所有的线程都

已投入使用，传入的请求不再被立即处理，而是放入队列中，当线

程空闲时再处理。

注意，最初的一段时间，执行队列的长度为零，然后就开始以

稳定的速度增长。这是因为系统中的负载在稳定增长，虽然最初系

统有足够的空闲线程去处理增加的负载，最终它还是不能承受，而

必须将其排入队列。

当系统达到饱和点，服务器吞吐量保持稳定后，就达到了给定

条件下的系统上限。但是，随着服务器负载的继续增长，系统的响

应时间也随之延长，虽然吞吐量保持稳定。

注意，在执行队列（图2）开始增长的同时，响应时间也开始

以递增的速度增长。这是因为请求不能被及时处理。

为了获得真正可再现的结果，应该将系统置于相同的高负载

下。为此，与服务器通信的虚拟用户应该将请求之间的考虑时间设

为零。这样服务器会立即超载，并开始构建执行队列。如果请求（虚

拟用户）数保持一致，基准测试的结果应该会非常精确，完全可以

再现。

您可能要问的一个问题是：“如何度量结果？”对于一次给定的

测试，应该取响应时间和吞吐量的平均值。精确地获得这些值的唯

一方法是一次加载所有的用户，然后在预定的时间段内持续运行。

这称为“flat”测试。

与此相对应的是“ramp-up”测试。

ramp-up测试中的用户是交错上升的（每儿秒增加一些新用

户）。ramp-up测试不能产生精确和可重现的平均值，这是因为由

于用户的增加是每次一部分，系统的负载在不断地变化。因此，flat

运行是获得基准测试数据的理想模式。

这不是在贬低ramp-up测试的价值。实际上，ramp-up测试

对找出以后要运行的flat测试的范围非常有用。ramp-up测试的优

点是，可以看出随着系统负载的改变，测量值是如何改变的。然后

可以据此选择以后要运行的flat测试的范围。

Flat测试的问题是系统会遇到“波动”效果。

）

注意波动的出现，吞吐量不再是平滑的。

这在系统的各个方面都有所体现，包括CPU的使用量。

注意，每隔一段时间就会出现一个波形。CPU使用量不再是

平滑的，而是有了像吞吐量图那样的尖峰。

此外，执行队列也承受着不稳定的负载，因此可以看到，随着

系统负载的增加和减少，执行队列也在增长和缩减。

注意，每隔一段时间就会出现一个波形。执行队列曲线与上面

的CPU使用量图非常相似。

最后，系统中事务的响应时间也遵循着这个波动模式。

注意，每隔一段时间就会出现一个波形。事务的响应时间也与

上面的图类似，只不过其效果随着时间的推移逐渐减弱。

当测试中所有的用户都同时执行儿乎相同的操作时，就会发生

这种现象。这将会产生非常不可靠和不精确的结果，所以必须采取

一些措施防止这种情况的出现。有两种方法可以从这种类型的结果

中获得精确的测量值。如果测试可以运行相当长的时间（有时是儿

个小时，取决于用户的操作持续的时间），最后由于随机事件的本

性使然，服务器的吞吐量会被“拉平”。或者，可以只选取波形中两

个平息点之间的测量值。该方法的缺点是可以捕获数据的时间非常

短。

性能规划测试

对于性能规划类型的测试来说，其目标是找出，在特定的环境

下，给定应用程序的性能可以达到何种程度。此时可重现性就不如

在基准测试中那么重要了，因为测试中通常都会有随机因子。引入

随机因子的目的是为了尽量模拟具有真实用户负载的现实世界应

用程序。通常，具体的目标是找出系统在特定的服务器响应时间下

支持的当前用户的最大数。例如，您可能想知道：如果要以5秒或

更少的响应时间支持8,000个当前用户，需要多少个服务器？要回

答这个问题，需要知道系统的更多信息。

要确定系统的容量，需要考虑儿个因素。通常，服务器的用户

总数非常大（以十万计），但是实际上，这个数字并不能说明什么。

真正需要知道的是，这些用户中有多少是并发与服务器通信的。其

次要知道的是，每个用户的“考虑时间”即请求间时间是多少。这非

常重要，因为考虑时间越短，系统所能支持的并发用户越少。例如,

如果用户的考虑时间是1秒，那么系统可能只能支持数百个这样的

并发用户。但是，如果用户的考虑时间是30秒，那么系统则可能

支持数万个这样的并发用户（假定硬件和应用程序都是相同的）。

在现实世界中，通常难以确定用户的确切考虑时间。还要注意，在

现实世界中，用户不会精确地按照间隔时间发出请求。

于是就引入了随机性。如果知道普通用户的考虑时间是5秒，

误差为20%,那么在设计负载测试时，就要确保请求间的时间为5x

(1+/-20%)秒。此外，可以利用“调步”的理念向负载场景中引入

更多的随机性。它是这样的：在一个虚拟用户完成一整套的请求后,

该用户暂停一个设定的时间段，或者一个小的随机时间段(例如，

2x(1+/-25%)秒)，然后再继续执行下一套请求。将这两种随

机化方法运用到测试中，可以提供更接近于现实世界的场景。

现在该进行实际的容量规划测试了。接下来的问题是：如何加

载用户以模拟负载状态？最好的方法是模拟高峰时间用户与服务

器通信的状况。这种用户负载状态是在一段时间内逐步达到的吗？

如果是，应该使用ramp-up类型的测试，每隔儿秒增加x个用户。

或者，所有用户是在一个非