性能测试--中文百科全书

内容

性能测试在软体的质量保证中起着重要的作用，它包括的测试内容丰富多样。中国软体评测中心将性能测试概括为三个方面：套用在客户端性能的测试、套用在网路上性能的测试和套用在伺服器端性能的测试。通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。

客户端

套用在客户端性能测试的目的是考察客户端套用的性能，测试的入口是客户端。它主要包括并发性能测试、疲劳强度测试、大资料量测试和速度测试等，其中并发性能性能测尝试像

测试是重点。

并发性能测试是重点

并发性能测试的过程是一个负载测试和压力测试的过程，即逐渐增加负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。负载测试（Load Testing）是确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统组成部分的相应输出项，例如通过量、回响时间、CPU负载、记忆体使用等来决定系统的性能。负载测试是一个分析软体应用程式和支撑架构、模拟真实环境的使用，从而来确定能够接收的性能过程。压力测试（Stress Testing）是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

并发性能测试的目的主要体现在三个方面：以真实的业务为依据，选择有代表性的、关键的业务操作设计测试案例，以评价系统的当前性能；当扩展应用程式的功能或者新的应用程式将要被部署时，负载测试会帮助确定系统是否还能够处理期望的使用者负载，以预测系统的未来性能；通过模拟成百上千个使用者，重复执行和运行测试，可以确认性能瓶颈并最佳化和调整套用，目的在于寻找到瓶颈问题。

当一家企业自己组织力量或委托软体公司代为开发一套套用系统的时候，尤其是以后在生产环境中实际使用起来，使用者往往会产生疑问，这套系统能不能承受大量的并发使用者同时访问? 这类问题最常见于採用在线上事务处理(OLTP)方式资料库套用、Web流览和影片点播等系统。这种问题的解决要借助于科学的软体测试手段和先进的测试工具。

举例说明：电信计费软体

众所周知，每月20日左右是市话交费的高峰期，全市几千个收费网点同时啓动。收费过程一般分为两步，首先要根据使用者提出的电话号码来查询出其当月产生费用，然后收取现金并将此使用者修改为已交费状态。一个使用者看起来简单的两个步骤，但当成百上千的终端，同时执行这样的操作时，情况就大不一样了，如此众多的交易同时发生，对应用程式本身、作业系统、中心资料库伺服器、中间件伺服器、网路设备的承受力都是一个严峻的考验。决策者不可能在发生问题后才考虑系统的承受力，预见软体的并发承受力，这是在软体测试阶段就应该解决的问题。

目前，大多数公司企业需要支持成百上千名使用者，各类套用环境以及由不同供性能测尝试像

应商提供的元件组装起来的复杂产品，难以预知的使用者负载和愈来愈复杂的应用程式，使公司担忧会发生投放性能差、使用者遭受反应慢、系统失灵等问题。其结果就是导致公司收益的损失。

如何模拟实际情况呢? 找若干台电脑和同样数目的操作人员在同一时刻进行操作，然后拿秒表记录下反应时间？这样的手工作坊式的测试方法不切实际，且无法捕捉程式内部变化情况，这样就需要压力测试工具的辅助。

测试的基本策略是自动负载测试，通过在一台或几台PC机上模拟成百或上千的虚拟使用者同时执行业务的情景，对应用程式进行测试，同时记录下每一事务处理的时间、中间件伺服器峰值资料、资料库状态等。通过可重复的、真实的测试能够彻底地度量套用的可扩展性和性能，确定问题所在以及最佳化系统性能。预先知道了系统的承受力，就为最终使用者规划整个运行环境的配置提供了有力的依据。

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

测试环境：配置测试环境是测试实施的一个重要阶段，测试环境的适合与否会严重影响测试结果的真实性和正确性。测试环境包括硬体环境和软体环境，硬体环境指测试必需的伺服器、客户端、网路连线设备以及印表机/扫瞄器等辅助硬体设备所构成的环境；软体环境指被测软体运行时的作业系统、资料库及其他套用软体构成的环境。

一个充分準备好的测试环境有三个优点：一个稳定、可重复的测试环境，能够保证测试结果的正确；保证达到测试执行的技术需求；保证得到正确的、可重复的以及易理解的测试结果。

测试工具：并发性能测试是在客户端执行的黑盒测试，一般不採用手工方式，而是利用工具採用自动化方式进行。目前，成熟的并发性能测试工具有很多，选择的依据主要是测试需求和性能价格比。着名的并发性能测试工具有QALoad、LoadRunner、Benchmark Factory和Webstress等。这些测试工具都是自动化负载测试工具，通过可重复的、真实的测试，能够彻底地度量套用的可扩展性和性能，可以在整个开发生命周期、跨越多种平台、自动执行测试任务，可以模拟成百上千的使用者并发执行关键业务而完成对应用程式的测试。

测试资料：在初始的测试环境中需要输入一些适当的测试资料，目的是识别资料状态并且验证用于测试的测试案例，在正式的测试开始以前对测试案例进行调试，将正式测试开始时的错误降到最低。在测试进行到关键过程环节时，非常有必要进行资料状态的备份。製造初始资料意味着将合适的资料存储下来，需要的时候恢复它，初始资料提供了一个基线用来评估测试执行的结果。

在测试正式执行时，还需要準备业务测试资料，比如测试并发查询业务，那麽要求对应的资料库和表中有相当的资料量以及资料的种类应能覆盖全部业务。

模拟真实环境测试，有些软体，特别是面向大众的商品化软体，在测试时常常需要考察在真实环境中的表现。如测试防毒软体的扫描速度时，硬碟上布置的不同类型档案的比例要尽量接近真实环境，这样测试出来的资料才有实际意义。

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

并发性能测试的种类取决于并发性能测试工具监控的对象，以QALoad自动化负载测试工具为例。软体针对各种测试目标提供了DB2、DCOM、ODBC、ORACLE、NETLoad、Corba、QARun、SAP、SQLServer、Sybase、Telnet、TUXEDO、UNIFACE、WinSock、WWW、Java Script等不同的监控对象，支持Windows和UNIX测试环境。

最关键的仍然是测试过程中对监控对象的灵活套用，例如目前三层结构的运行模式广泛使用，对中间件的并发性能测试作为问题被提到议事日程上来，许多系统都採用了国产中间件，选择Java Script监控对象，手工编写脚本，可以达到测试目的。

採用自动化负载测试工具执行的并发性能测试，基本遵循的测试过程有：测试需求与测试内容，测试案例製定，测试环境準备，测试脚本录製、编写与调试，脚本分配、回放配置性能测尝试像

与载入策略，测试执行跟蹤，结果分析与定位问题所在，测试报告与测试评估。

并发性能测试监控的对象不同，测试的主要指标也不相同，主要的测试指标包括交易处理性能指标和UNIX资源监控。其中，交易处理性能指标包括交易结果、每分锺交易数、交易回响时间（Min：最小伺服器回响时间；Mean：平均伺服器回响时间；Max：最大伺服器回响时间；StdDev：事务处理伺服器回响的偏差，值越大，偏差越大；Median：中值回响时间；90%：90%事务处理的伺服器回响时间）、虚拟并发使用者数。

套用实例：“新华社多媒体资料库 V1.0”性能测试

中国软体评测中心（CSTC）根据新华社技术局提出的《多媒体资料库（一期）性能测试需求》和GB/T 17544《软体包质量要求和测试》的国家标準，使用工业标準级负载测试工具对新华社使用的“新华社多媒体资料库 V1.0”进行了性能测试。

性能测试的目的是模拟多使用者并发访问新华社多媒体资料库，执行关键检索业务，分析系统性能。

性能测试的重点是针对系统并发压力负载较大的主要检索业务，进行并发测试和疲劳测试，系统採用B/S运行模式。并发测试设计了特定时间段内分别在中文库、英文库、图片库中进行单检索词、多检索词以及变检索式、混合检索业务等并发测试案例。疲劳测试案例为在中文库中并发使用者数200，进行测试周期约8小时的单检索词检索。在进行并发和疲劳测试的同时，监测的测试指标包括交易处理性能以及UNIX（Linux）、Oracle、Apache资源等。

测试结论：在新华社机房测试环境和区域网路测试环境中，100M频宽情况下，针对规定的各并发测试案例，系统能够承受并发使用者数为200的负载压力，最大交易数/分锺达到78.73，运行基本稳定，但随着负载压力增大，系统性能有所衰减。

系统能够承受200并发使用者数持续周期约8小时的疲劳压力，基本能够稳定运行。

通过对系统UNIX（Linux）、Oracle和Apache资源的监控，系统资源能够满足上述并发和疲劳性能需求，且系统硬体资源尚有较大利用余地。

当并发使用者数超过200时，监控到HTTP 500、connect和逾时错误，且Web伺服器报记忆体溢出错误，系统应进一步提高性能，以支持更大并发使用者数。

建议进一步最佳化软体系统，充分利用硬体资源，缩短交易回响时间。

疲劳强度与大资料量测试

疲劳测试是採用系统稳定运行情况下能够支持的最大并发使用者数，持续执行一段时间业务，通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。

疲劳强度测试可以採用工具自动化的方式进行测试，也可以手性能测尝试像

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

一般情况下以伺服器能够正常稳定回响请求的最大并发使用者数进行一定时间的疲劳测试，获取交易执行指标资料和系统资源监控资料。如出现错误导致测试不能成功执行，则及时调整测试指标，例如降低使用者数、缩短测试周期等。还有一种情况的疲劳测试是对当前系统性能的评估，用系统正常业务情况下并发使用者数为基础，进行一定时间的疲劳测试。

大资料量测试可以分为两种类型：针对某些系统存储、传输、统计、查询等业务进行大资料量的独立资料量测试；与压力性能测试、负载性能测试、疲劳性能测试相结合的综合资料量测试方案。大资料量测试的关键是测试资料的準备，可以依靠工具準备测试资料。

速度测试目前主要是针对关键有速度要求的业务进行手工测速度，可以在多次测试的基础上求平均值，可以和工具测得的回响时间等指标做对比分析。

网路端

套用在网路上性能的测试重点是利用成熟先进的自动化技术进行网路套用性能监控、网路套用性能分析和网路预测。

网路套用性能分析

网路套用性能分析的目的是準确展示网路频宽、延迟、负载和TCP连线埠的变化是如何影响使用者的回响时间的。利用网路套用性能分析工具，例如Application Expert，能够发现套用的瓶颈，我们可知套用在网路上运行时在每个阶段发生的套用行为，在套用执行绪级分析套用的问题。可以解决多种问题：客户端是否对资料库伺服器运行了不必要的请求？当伺服器从客户端接受了一个查询，套用伺服器是否花费了不可接受的时间联系资料库伺服器？在投产前预测套用的回响时间；利用Application Expert调整套用在广域网上的性能；Application Expert能够让你快速、容易地仿真套用性能，根据最终使用者在不同网路配置环境下的回响时间，使用者可以根据自己的条件决定套用投产的网路环境。

网路套用性能监控

在系统试运行之后，需要及时準确地了解网路上正在发生什麽事情；什麽套用在运行，如何运行；多少PC正在访问LAN或WAN；哪些应用程式导致系统瓶颈或资源竞争，这时网路套用性能监控以及网路资源管理对系统的正常稳定运行是非常关键的。利用网路套用性能监控工具，可以达到事半功倍的效果，在这方面我们可以提供的工具是Network Vantage。通俗地讲，它主要用来分析关键应用程式的性能，定位问题的根源是在客户端、伺服器、应用程式还是网路。在大多数情况下使用者较关心的问题还有哪些应用程式佔用大量频宽，哪些使用者产生了最大的网路流量，这个工具同样能满足要求。

网路预测

考虑到系统未来发展的扩展性，预测网路流量的变化、网路结构的变化对使用者系统的影响非常重要。根据规划资料进行预测并及时提供网路性能预测资料。我们利用网路预测分析容量规划工具PREDICTOR可以作到：设定服务水準、完成日网路容量规划、离线测试网路、网路失效和容量极限分析、完成日常故障诊断、预测网路设备迁移和网路设备升级对整个网路的影响。

从网路管理软体获取网路拓扑结构、从现有的流量监控软体获取流量信息（若没有这类软体可人工生成流量资料），这样可以得到现有网路的基本结构。在基本结构的基础上，可根据网路结构的变化、网路流量的变化生成报告和图表，说明这些变化是如何影响网路性能的。PREDICTOR提供如下信息：根据预测的结果帮助使用者及时升级网路，避免因关键设备超过利用阀值导致系统性能下降；哪个网路设备需要升级，这样可减少网路延迟、避免网路瓶颈；根据预测的结果避免不必要的网路升级。

服务端

对于套用在伺服器上性能的测试，可以採用工具监控，也可以使用系统本身的监控命令，例如Tuxedo中可以使用Top命令监控资源使用情况。实施测试的目的是实现伺服器性能测尝试像

设备、伺服器作业系统、资料库系统、套用在伺服器上性能的全面监控，测试原理如下图。

UNIX资源监控指标和描述

监控指标描述

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

沖突率在乙太网上监测到的每秒沖突数

进程/执行绪交换率进程和执行绪之间每秒交换次数

CPU利用率 CPU佔用率（%）

磁碟交换率磁碟交换速率

接收包错误率接收乙太网封包时每秒错误数

包输入率每秒输入的乙太网封包数目

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

输出糗错误率传送乙太网封包时每秒错误数

包输入率每秒输出的乙太网封包数目

读入记忆体页速率物理记忆体中每秒读入记忆体页的数目

写出记忆体页速率每秒从物理记忆体中写到页档案中的记忆体页数

目或者从物理记忆体中删掉的记忆体页数目

记忆体页交换速率每秒写入记忆体页和从物理记忆体中读出页的个数

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

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

系统CPU利用率系统的CPU佔用率（%）

使用者CPU利用率使用者模式下的CPU佔用率（%）

磁碟阻塞磁碟每秒阻塞的位元组数

目的

目的是验证软体系统是否能够达到使用者提出的性能指标，同时发现软体系统中存在的性能瓶颈，最佳化软体，最后起到最佳化系统的目的。

包括以下几个方面

1．评估系统的能力，测试中得到的负荷和回响时间资料可以被用于验证所计画的模型的能力，并帮助作出决策。

2．识别体系中的弱点：受控的负荷可以被增加到一个极端的水準，并突破它，从而修复体系的瓶颈或薄弱的地方。

3．系统调优：重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能。

检测软体中的问题：长时间的测试执行可导致程式发生由于记忆体泄露引起的失败，揭示程式中的隐含的问题或沖突。

4．验证稳定性（resilience）可靠性（reliability）：在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法。

性能测试类型

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

负载测试（Load Testing）：负载测试是一种主要为了测试软体系统是否达到需求文档设计的目标，譬如软体在一定时期内，最大支持多少并发使用者数，软体请求出错率等，测试的主要是软体系统的性能。

强度测试（Stress Testing）：强度测试也就是压力测试，压力测试主要是为了测试硬体系统是否达到需求文档设计的性能目标，譬如在一定时期内，系统的cpu利用率，记忆体使用率，磁碟I/O吞吐率，网路吞吐量等，压力测试和负载测试最大的差别在于测试目的不同。

容量测试（Volume Testing）：确定系统最大承受量，譬如系统最大使用者数，最大存储量，最多处理的资料流量等。

指标

性能测试主要是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

在实际中作中我们经常会对两种类型软体进行测试：bs和cs，这两方面的性能指标一般需要哪些内容呢？

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

Web伺服器指标指标：

* Avg Rps: 平均每秒锺回响次数=总请求时间 / 秒数；

* Avg time to last byte per terstion （mstes）：平均每秒业务脚本的迭代次数，有人会把这两者混淆；

* Successful Rounds：成功的请求；

* Failed Rounds ：失败的请求；

* Successful Hits ：成功的点击次数；

* Failed Hits ：失败的点击次数；

* Hits Per Second ：每秒点击次数；

* Successful Hits Per Second ：每秒成功的点击次数；

* Failed Hits Per Second ：每秒失败的点击次数；

* Attempted Connections ：尝试连结数；

CS结构程式，由于一般软体后台通常为资料库，所以我们更注重资料库的测试指标：

* User 0 Connections ：使用者连线数，也就是资料库的连线数量；

* Number of deadlocks：资料库死锁；

* Buffer Cache hit ：资料库Cache的命中情况

当然，在实际中我们还会察看多使用者测试情况下的记忆体，CPU，系统资源调用情况。这些指标其实是引申出来性能测试中的一种：竞争测试。什麽是竞争测试，软体竞争性能测尝试像

使用各种资源（资料纪录，记忆体等），看他与其他相关系统对资源的争夺能力。

我们知道软体架构在实际测试中製约着测试策略和工具的选择。如何选择性能测试策略是我们在实际工作中需要了解的。一般软体可以按照系统架构分成几种类型：

c/s

client/Server 客户端/伺服器架构

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

基于客户端/伺服器的分散式架构

b/s

基于流览器/Web伺服器的三层架构

基于中间件套用伺服器的三层架构l

基于Web伺服器和中间件的多层架构l

步骤

在每种不同的系统架构的实施中，开发人员可能选择不同的实现方式，造成实际情况纷繁复杂。我们不可能对每种技术都详细解说，这裏只是介绍一种方法提供给你如何选择测试策略，从而帮助分析软体不同部分的性能指标，进而分析出整体架构的性能指标和性能瓶颈。

由于工程和项目的不同，所选用的度量，评估方法也有不同之处。不过仍然有一些通用的步骤帮助我们完成一个性能测试项目。步骤如下

1．製定目标和分析系统

2．选择测试度量的方法

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

4．製定评估标準

5．设计测试用例

6．运行测试用例

7．分析测试结果

製定目标和分析系统

每一个性能测试计画中第一步都会製定目标和分析系统构成。只有明确目标和了解系统构成才会澄清测试範围，知道在测试中要掌握什麽样的技术。

目标：

1．确定客户需求和期望

2．实际业务需求

3．系统需求

系统组成

系统组成这裏包含几方面含义：系统类别，系统构成，系统功能等。了解这些内容的本质其实是帮助我们明确测试的範围，选择适当的测试方法来进行测试。

系统类别：厘清系统类别是我们掌握什麽样的技术的前提，掌握相应技术做性能测试才可能成功。例如：系统类别是bs结构，需要掌握 http协定，java，html等技术。或者是cs结构，可能要了解作业系统，winsock，com等。所以甄别系统类别对于我们来说很重要。

系统构成：硬体设定，作业系统设定是性能测试的製约条件，一般性能测试都是利用测试工具模仿大量的实际使用者操作，系统在超负荷情形下运作。不同的系统构成性能测试就会得到不同的结果。

系统功能：系统功能指系统提供的不同子系统，办公管理系统中的公文子系统，会议子系统等，系统工能是性能测试中要模拟的环节，了解这些是必要的。

选择测试度量的方法

经过第一步，将会对系统有清醒的认识。接下来我们将把精力放在软体度量上，收集系统相关的资料。

度量的相关方面：

* 製定规範

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

* 製定改进策略

* 製定结果对比标準

学习的相关技术和工具

性能测试是通过工具，模拟大量使用者操作，对系统增加负载。所以需要掌握一定的工具知识才能进行性能测试。大家都知道性能测试工具一般通过winsock,http等协定记录使用者操作。而协定选择是基于软体的系统架构实现（web一般选择http协定，cs选择winsock协定），不同的性能测试工具，脚本语言也不同，比如rational robot中vu脚本用类c语言实现。

开展性能测试需要对各种性能测试工具进行评估，因为每一种性能测试工具都有自身的特点，只有经过工具评估，才能选择符合现有软体架构的性能测试工具。确定测试工具后，需要组织测试人员进行工具的学习，培训相关技术。

製定评估标準

任何测试的目的都是确保软体符合预先规定的目标和要求。性能测试也不例外。所以必须製定一套标準。

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

*线性投射：用大量的过去的，扩展的或者将来可能发生的资料组成性能测尝试像

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

*分析模型：用排队论公式和演算法预测回响时间，利用描述工作量的资料和系统本质关联起来

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

*基準：定义测试和你最初的测试作为标準，利用它和所有后来进行的测试结果进行对比

设计测试用例

设计测试用例是在了解软体业务流程的基础上。设计测试用例的原则是受最小的影响提供最多的测试信息，设计测试用例的目标是一次尽可能的包含多个测试要素。这些测试用例必须是测试工具可以实现的，不同的测试场景将测试不同的功能。因为性能测试不同于平时的测试用例，尽可能把性能测试用例设计的复杂，才有可能发现软体的性能瓶颈。

运行测试用例

通过性能测试工具运行测试用例。同一环境下作的性能测试得到的测试结果是不準确的，所以在运行这些测试用例的时候，需要用不同的测试环境，不同的机器配置上运行。

分析测试结果

运行测试用例后，收集相关信息，进行资料统计分析，找到性能瓶颈。通过排除误差和其他因素，让测试结果体现接近真实情况。不同的体系结构分析测试结果的方法也不同，bs结构我们会分析网路频宽，流量对使用者操作回响的影响，而cs结构我们可能更关心会系统整体配置对使用者操作的影响。

方法

对于企业应用程式，有许多进行性能测试的方法，其中一些方法实行起来要比其他方法困难。所要进行的性能测试的类型取决于想要达到的结果。例如，对于可再现性，基準测试是最好的方法。而要从当前使用者负载的角度测试系统的上限，则应该使用容量规划测试。本文将介绍几种设定和运行性能测试的方法，并讨论这些方法的区别。

如果不进行合理的规划，对J2EE应用程式进行性能测试将会是一项令人望而生畏且有些混乱的任务。因为对于任何的软体开发流程，都必须收集需求、理解业务需要，并在进行实际测试之前设计出正式的进度表。性能测试的需求由业务需要驱动，并由一组用例阐明。这些用例可以基于历史资料（例如，伺服器一周的负载模式）或预测的近似值。弄清楚需要测试的内容之后，就需要知道如何进行测试了。

在开发阶段前期，应该使用基準测试来确定应用程式中是否出现性能倒退。基準测试可以在一个相对短的时间内收集可重复的结果。进行基準测试的最好方法是，每次测试改变一个且只改变一个参数。例如，如果想知道增加JVM记忆体是否会影回响用程式的性能，就逐次递增JVM记忆体（例如，从1024 MB增至1224 MB，然后是1524 MB，最后是2024 MB），在每个阶段收集结果和环境资料，记录信息，然后转到下一阶段。这样在分析测试结果时就有迹可循。下一小节我将介绍什麽是基準测试，以及运行基準测试的最佳参数。

开发阶段后期，在应用程式中的bug已经被解决，应用程式达到一种稳定状态之后，可以运行更为复杂的测试，确定系统在不同的负载模式下的表现。这些测试被称为容量规划测试、渗入测试(soak test)、峰谷测试（peak-rest test)，它们旨在通过测试应用程式的可靠性、健壮性和可伸缩性来测试接近于现实世界的场景。对于下面的描述应该从抽象的意义上理解，因为每个应用程式的使用模式都是不同的。例如，容量规划测试通常都使用较缓慢的ramp-up（下文有定义），但是如果应用程式在一天之中的某个时段中有快速突发的流量，那麽自然应该修改测试以反映这种情况。但是，要记住，因为变更了测试参数（比如ramp-up周期或使用者的考虑时间（think-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%，那麽在设计负载测试时，就要确保请求间的时间为5×（1 /- 20%）秒。此外，可以利用“调步”的理念向负载场景中引入更多的随机性。它是这样的：在一个虚拟使用者完成一整套的请求后，该使用者暂停一个设定的时间段，或者一个小的随机时间段（例如，2×（1 /- 25%）秒），然后再继续执行下一套请求。将这两种随机化方法运用到测试中，可以提供更接近于现实世界的场景。

现在该进行实际的容量规划测试了。接下来的问题是：如何载入使用者以模拟负载状态？最好的方法是模拟高峰时间使用者与伺服器通信的状况。这种使用者负载状态是在一段时间内逐步达到的吗？如果是，应该使用ramp-up类型的测试，每隔几秒增加x个使用者。或者，所有使用者是在一个非常短的时间内同时与系统通信？如果是这样，就应该使用flat类型的测试，将所有的使用者同时载入到伺服器。两种不同类型的测试会产生没有可比性的不同测试。例如，如果进行ramp-up类型的测试，系统可以以4秒或更短的回响时间支持5,000个使用者。而执行flat测试，您会发现，对于5,000个使用者，系统的平均回响时间要大于4秒。这是由于ramp-up测试固有的不準确性使其不能显示系统可以支持的并发使用者的精确数位。以门户应用程式为例，随着门户规模的扩大和集群规模的扩大，这种不确定性就会随之显现。

这不是说不应该使用ramp-up测试。对于系统负载在一段比较长的时间内缓慢增加的情况，ramp-up测试效果还是不错的。这是因为系统能够随着时间不断调整。如果使用快速ramp-up测试，系统就会滞后，从而报告一个较相同使用者负载的flat测试低的回响时间。那麽，什麽是确定容量的最好方法？结合两种负载类型的优点，并运行一系列的测试，就会产生最好的结果。例如，首先使用ramp-up测试确定系统可以支持的使用者範围。确定了範围之后，以该範围内不同的并发使用者负载进行一系列的flat测试，更精确地确定系统的容量。

渗入测试

渗入测试是一种比较简单的性能测试。渗入测试所需时间较长，它使用固定数目的并发使用者测试系统的整体健壮性。这些测试将会通过记忆体泄漏、增加的垃圾收集（GC)或系统的其他问题，显示因长时间运行而出现的任何性能降低。测试运行的时间越久，您对系统就越了解。运行两次测试是一个好主意——一次使用较低的使用者负载（要在系统容量之下，以便不会出现执行伫列），一次使用较高的负载（以便出现积极的执行伫列）。

测试应该运行几天的时间，以便真正了解应用程式的长期健康状况。要确保测试的应用程式尽可能接近现实世界的情况，使用者场景也要逼真（虚拟使用者通过应用程式导航的方式要与现实世界一致），从而测试应用程式的全部特徵。确保运行了所有必需的监控工具，以便精确地监测并跟蹤问题。

峰谷测试

峰谷测试兼有容量规划ramp-up类型测试和渗入测试的特征。其目标是确定从高负载（例如系统高峰时间的负载）恢复、转为几乎空闲、然后再攀升到高负载、再降低的能力。

实现这种测试的最好方法就是，进行一系列的快速ramp-up测试，继之以一段时间的平稳状态（取决于业务需求），然后急剧降低负载，此时可以令系统平息一下，然后再进行快速的ramp-up；反复重复这个过程。这样可以确定以下事项：第二次高峰是否重现第一次的峰值？其后的每次高峰是等于还是大于第一次的峰值？在测试过程中，系统是否显示了记忆体或GC性能降低的有关迹象？测试运行（不停地重复“峰值/空闲”周期）的时间越长，您对系统的长期健康状况就越了解。

工具

自动化测试工具介绍LR篇

HPloadrunner啓动介面

LoadRunner 是一种预测系统行为和性能的负载测试工具。通过以模拟上千万使用者实施并发负载及即时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner ，企业能最大限度地缩短测试时间，最佳化性能和加速套用系统的发布周期。

目前企业的网路套用环境都必须支持大量使用者，网路体系架构中含各类套用环境且由不同供应商提供软体和硬体产品。难以预知的使用者负载和愈来愈复杂的套用环境使公司时时担心会发生使用者回响速度过慢，系统崩溃等问题。这些都不可避免地导致公司收益的损失。LoadRunner 能让企业保护自己的收入来源，无需购置额外硬体而最大限度地利用现有的IT 资源，并确保终端使用者在套用系统的各个环节中对其测试套用的质量，可靠性和可扩展性都有良好的评价。

LoadRunner 是一种适用于各种体系架构的自动负载测试工具，它能预测系统行为并最佳化系统性能。LoadRunner 的测试对象是整个企业的系统，它通过模拟实际使用者的操作行为和实行即时性能监测，来帮助您更快的查找和发现问题。此外，LoadRunner 能支持广泛的协定和技术，为您的特殊环境提供特殊的解决方案。

轻松建立虚拟使用者

使用LoadRunner 的Virtual User Generator，您能很简便地创立起系统负载。该引擎能够生成虚拟使用者，以虚拟使用者的方式模拟真实使用者的业务操作行为。它先记录下业务流程（如下订单或机票预定），然后将其转化为测试脚本。利用虚拟使用者，您可以在Windows ，UNIX 或Linux 机器上同时产生成千上万个使用者访问。所以LoadRunner能极大的减少负载测试所需的硬体和人力资源。另外，LoadRunner 的TurboLoad 专利技术能。

提供很高的适应性。TurboLoad 使您可以产生每天几十万名线上使用者和数以百万计的点击数的负载。

用Virtual User Generator 建立测试脚本后，您可以对其进行参数化操作，这一操作能让您利用几套不同的实际发生资料来测试您的应用程式，从而反映出本系统的负载能力。以一个订单输入过程为例，参数化操作可将记录中的固定资料，如订单号和客户名称，由可变值来代替。在这些变数内随意输入可能的订单号和客户名，来匹配多个实际使用者的操作行为。

LoadRunner 通过它的Data Wizard 来自动实现其测试资料的参数化。Data Wizard 直接连于资料库伺服器，从中您可以获取所需的资料（如定单号和使用者名称）并直接将其输入到测试脚本。这样避免了人工处理资料的需要，Data Wizard 为您节省了大量的时间。

为了进一步确定您的Virtual user 能够模拟真实使用者，您可利用LoadRunner 控製某些行为特徵。例如，只需要点击一下滑鼠，您就能轻易控製交易的数量，交易频率，使用者的思考时间和连线速度等。

建立真实的负载

Virtual users 建立起后，您需要设定您的负载方案，业务流程组合和虚拟使用者数量。用LoadRunner 的Controller，您能很快组织起多使用者的测试方案。Controller 的Rendezvous 功能提供一个互动的环境，在其中您既能建立起持续且迴圈的负载，又能管理和驱动负载测试方案。

而且，您可以利用它的日程计画服务来定义使用者在什麽时候访问系统以产生负载。这样，您就能将测试过程自动化。同样您还可以用Controller 来限定您的负载方案，在这个方案中所有的使用者同时执行一个动作---如登入到一个库存应用程式——---来模拟峰值负载的情况。另外，您还能监测系统架构中各个组件的性能——--- 包括伺服器，资料库，网路设备等——---来帮助客户决定系统的配置。

LoadRunner 通过它的AutoLoad 技术，为您提供更多的测试弹性。使用AutoLoad ，您可以根据目前的使用者人数事先设定测试目标，最佳化测试流程。例如，您的目标可以是确定您的套用系统承受的每秒点击数或每秒的交易量。

定位性能问题

LoadRunner 内含集成的即时监测器，在负载测试过程的任何时候，您都可以观察到套用系统的运行性能。这些性能监测器为您即时显示交易性能资料（如回响时间）和其它系统组件包括application server,web server，网路设备和资料库等的即时性能。这样，您就可以在测试过程中从客户和伺服器的双方面评估这些系统组件的运行性能，从而更快地发现问题。

再者，利用LoadRunner 的ContentCheck TM ，您可以判断负载下的应用程式功能正常与否。ContentCheck 在Virtual users 运行时，检测应用程式的网路封包内容，从中确定是否有错误内容传送出去。它的即时流览器帮助您从终端使用者角度观察程式性能状况。

分析结果以精确定位问题所在

一旦测试完毕后，LoadRunner 收集汇总所有的测试资料，并为您提供高级的分析和报告工具，以便迅速查找到性能问题并追溯原由。使用LoadRunner 的Web 交易细节监测器，您可以了解到将所有的图象、架构和文本下载到每一网页上所需的时间。例如，这个交易细节分析机製能

够分析是否因为一个大尺寸的图形档案或是第三方的资料组件造成套用系统运行速度减慢。另外，Web 交易细节监测器分解用于客户端、网路和伺服器上端到端的反应时间，便于确认问题，定位查找真正出错的组件。例如，您可以将网路延时进行分解，以判断DNS 解析时间，连线伺服器或SSL 识别所花费的时间。通过使用LoadRunner 的分析工具，您能很快地查找到出错的位置和原因并作出相应的调整。

重复测试保证系统发布的高性能

负载测试是一个重复过程。每次处理完一个出错情况，您都需要对您的应用程式在相同的方案下，再进行一次负载测试。以此检验您所做的修正是否改善了运行性能。

Enterprise Java Beans的测试

LoadRunner 完全支持EJB 的负载测试。这些基于Java 的组件运行在套用伺服器上，提供广泛的套用服务。通过测试这些组件，您可以在应用程式开发的早期就确认并解决可能产生的问题。

利用LoadRunner,您可以很方便地了解系统的性能。它的Controller 允许您重复执行与出错修改前相同的测试方案。它的基于HTML 的报告为您提供一个比较性能结果所需的基準，以此衡量在一段时间内，有多大程度的改进并确保套用成功。由于这些报告是基于HTML 的文本，您可以将其公布于您公司的内部网上，便于随时查阅。

最大化投资回报

所有Mercury Interactive 的产品和服务都是集成设计的，能完全相容地一起运作。由于它们具有相同的核心技术，来自于LoadRunner和ActiveTest TM 的测试脚本，在Mercury Interactive 的负载测试服务项目中，可以被重复用于性能监测。借助Mercury Interactive的监测功能－－Topaz TM 和ActiveWatch TM ，测试脚本可重复使用从而平衡投资收益。更重要的是，您能为测试的前期部署和生产系统的监测提供一个完整的套用性能管理解决方案。

支持无线套用协定

随着无线设备数量和种类的增多，您的测试计画需要同时满足传统的基于流览器的使用者和无线网际网路设备，如手机和PDA。LoadRunner 支持2 项最广泛使用的协定：WAP和I-mode。此外，通过负载测试系统整体架构，LoadRunner 能让您只需要通过记录一次脚本，就可完全检测上述这些无线网际网路系统。

支持Media Stream套用

LoadRunner 还能支持Media Stream套用。为了保证终端使用者得到良好的操作体验和高质量Media Stream，您需要检测您的Media Stream应用程式。使用LoadRunner ，您可以记录和重放任何流行的多媒体资料流格式来诊断系统的性能问题，查找原由，分析资料的质量。

完整的企业套用环境的支持。

LoadRunner 支持广泛的协定，可以测试各种IT 基础架构。

结束

本文介绍了进行性能测试的几种方法。取决于业务需求、开发周期和应用程式的生命周期，对于特定的企业，某些测试会比其他的更适合。但是，对于任何情况，在决定进行某一种测试前，都应该问自己一些基本问题。这些问题的答案将会决定哪种测试方法是最好的。

这些问题包括：

结果的可重复性需要有多高？

测试需要运行和重新运行几次？

您处于开发周期的哪个阶段？

您的业务需求是什麽？

您的使用者需求是什麽？

您希望生产中的系统在维护停机时间中可以持续多久？

在一个正常的业务日，预期的使用者负载是多少？

将这些问题的答案与上述性能测试类型相对照，应该就可以製定出测试应用程式的整体性能的完美计画。

性能测试是为描述测试对象与性能相关的特征并对其进行评价，而实施和执行的一类测试，如描述和评价计时配置档案、执行流、回响时间以及操作的可靠性和限製等特征。不同类型的性能测试侧重于不同的测试目标，这些性能测试的实施贯穿于整个软体开发生命周期 (Software Development Life Cycle,SDLC)。起初，在构架迭代中，性能测试侧重于确定和消除与构架有关的性能瓶颈。在构建迭代中还将实施和执行其他类型的性能测试，以调整软体和环境（最佳化回响时间和资源），并核实应用程式和系统是否能够处理高负载和高强度的情况，如有大量事务、客户机和/或资料的情况。

类型

性能测试中包含以下测试类型：

基準测试 - 比较新的或未知测试对象与已知参照标準（如现有软体或评测标準）的性能。

争用测试：- 核实测试对象对于多个主角对相同资源（资料记录、记忆体等）的请求的处理是否可以接受。

性能配置 - 核实在操作条件保持不变的情况下，测试对象在使用不同配置时其性能行为的可接受性。

负载测试 - 核实在保持配置不变的情况下，测试对象在不同操作条件（如不同使用者数、事务数等）下性能行为的可接受性。

强度测试 - 核实测试对象性能行为在异常或极端条件（如资源减少或使用者数过多）之下的可接受性。

容量测试 - 核实测试使用者同时使用软体程式的最大数量。

性能评价通常是和使用者代表一起协作并且以多级方法执行的。

性能分析的第一级涉及单一主角/用例实例的结果评价和多个测试执行的结果比较。例如，在测试对象上没有其他活动的情况下，记录单一主角执行单一用例的性能行为，并将结果与相同主角/用例的其他几个测试执行进行比较。第一级分析有助于确定可以表明系统资源中存在争用的趋势，该趋势将影响从其他性能测试结果所得出的结论的有效性。

分析的第二级检查特定主角/用例执行的摘要统计信息和实际资料值，以及测试对象的性能行为。摘要统计信息包括回响时间的标準偏差和百分位分布，这些信息显示了系统回响的变动情况，正如每个主角所见到的一样。

分析的第三级有助于理解性能问题的起因和加权值。该详细分析採用低级资料并且使用统计方法，帮助测试员从资料中得出正确的结论。详细分析为决策提供客观和定量的标準，但是它耗时较长，并且要求对统计学有基本的理解。

当性能行为差异确实存在，或是由于某些与测试资料收集相关的随机事件引起时，详细分析使用统计加权值的概念来帮助理解。即认为在基本级上，任何事件都具有随机性。统计测试确定是否存在无法用随机事件解释的系统差异。