LoadRunner软件性能测试术语.docx

《LoadRunner软件性能测试术语.docx》由会员分享，可在线阅读，更多相关《LoadRunner软件性能测试术语.docx（11页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、1 性能测试的概念（PerformanceTesting）:狭义的性能测试主要用于描述常规的性能测试，是指通过模拟生产运行的业务压力或用 户使用场景来测试系统的性能是否满足生产性能的要求广义的性能测试则是压力测试、负载测试、强度测试、并发（用户）测试、大数据量测 试、配置测试、可靠性测试等和性能相关的测试统称。下面分别介绍各类测试的主要内容和 特点。1.1压力测试对系统不断施加压力的测试，是通过确定一个系统的瓶颈或不能接收用户请求的性能 点，来获得系统能提供的最大服务级别的测试。例如测试一个Web站点在大量的负荷下， 系统的事务响应时间何时会变得不可接受或事务不能正常执行。压力测试的目的是发现

2、在什么条件下系统的性能变得不可接受，并通过对应用程序施加 越来越大的负载，直到发现应用程序性能下降的拐点。压力测试和负载测试有些类似，但是 通常把负载测试描述成一种特定类型的压力测试例如增加用户数量或延长压力时间以 对应用程序进行压力测试。1.2负载测试对系统不断地增加压力或增加一定压力下的持续时间，直到系统的一些性能指标达到极 限，例如响应时间超过预定指标或某种资源已经达到饱和状态。这种测试可以找到系统的处 理极限，为系统调优提供依据。压力测试侧重压力大小，而负载测试往往强调压力持续的时间。在实际工作中，没有必 要严格区分这两个概念.1.3强度测试强度测试主要是为了检查程序对异常情况的抵抗能

3、力。强度测试总是迫使系统在异常的 资源配置下运行。例如：/ 当正常的用户点击率为1000次/秒时，运行点击率为”2000次/秒的测试用例；/ 运行需要最大存储空间（或其他资源）的测试用例；/ 运行可能导致操作系统崩溃或磁盘数据剧烈抖动的测试用例，等等。3.16 集合点(Rendezvous)为了衡量在加重负载的情况下服务器的性能情况。集合点：用以同步虚拟用户，以便恰 好在同一时刻执行任务。这个从概念上来讲，其实也是比较模糊，正因为模糊，使用才值得 去深入探讨。对于LoadRunner来说，集合点只是一种策略，而这个策略也会有很多规则, 因为实际情况中并非所有用户都会同时到达集合点，上面的那个结

4、构图就能解释这个误解, 因为从客户端发出到网络、中间件、应用层再到数据库，这其中的每一个环节都有延时，也 就是说不可能所有的用户都能到达所谓的集合点，才开始同时执行操作。在以评测为目的的性能测试中，用户更关心的是业务上的并发，其实是真实业务场景的 并发情况，这种情况下就不需要设置集合点了。集合点是一种特殊情况下的并发，通常是在以调优为目的的性能测试中才会用得到，主要是 为了有针对性地进行施压，以便找到性能瓶颈。总处理时间T=t1 + t2 + t3总处理时间T=t1 + t2 + t313:数据库服务器处理时间3.17 事务(transaction)为了衡量服务器的性能而定义事务。就是在脚本定

5、义中定义的某段操作(action),更确 切的说就是一段脚本语言。定义事务时，首先在脚本中找到事务的开始和结束位置，然后分 别插入一个事务的起始标记，当脚本在运行时，Loadrunner会自动在事务的起始点计时，脚 本在运行事务结束点时，计时结束，系统会自动记录这段操作的运行时间等性能数据。3,18系统瓶颈瓶颈主要是指整个软硬件构成的软件系统某一方面或者几个方面能力不能满足用户的 特定业务要求，“特定”是指瓶颈会在某些条件下会出现，因为毕竟大多数系统在投入前。严格的从技术角度讲，所有的系统都会有瓶颈，因为大多数系统的资源配置不是协调的, 例如CPU使用率刚好达到100%时，内存也正好耗尽的系统

6、不是很多见。因此我们讨论系统 瓶颈要从应用的角度讨论:关键是看系统能否满足用户需求。在用户极限使用系统的情况下, 系统的响应仍然正常，我们可以认为改系统没有瓶颈或者瓶颈不会影响用户工作。因此我们测试系统瓶颈主要是实现下面两个目的：-发现“表面”的瓶颈。主要是模拟用户的操作，找出用户极限使用系统时的瓶颈，然 后解决瓶颈，这是性能测试的基本目标。-发现潜在的瓶颈并解决，保证系统的长期稳定性。主要是考虑用户在将来扩展系统或 者业务发生变化时，系统能够适应变化。满足用户目前需求的系统不是最好的，我们设计系 统的目标是在保证系统整个软件生命周期能够不断适应用户的变化，或者通过简单扩展系统 就可以适应新的

7、变化。强度测试是一种特别重要的测试，对测试系统的稳定性，以及系统未来的扩展空间均具 有重要的意义。在这种异常条件下进行的测试，更容易发现系统是否稳定以及性能方面是否 容易扩展。疲劳强度测试是一类特殊的强度测试，主要测试系统长时间运行后的性能表现，例如 7x24小时的压力测试。1.4并发（用户）测试主要指当测试多个用户并同时访问同一个应用程序、同一个模块或数据记录时是否存在 死锁或其他性能问题，几乎所有的性能测试都会涉及并发测试。在具体的性能测试工作中, 并发用户往往都是借助工具来进行模拟的，LoadRunner中称之为并发虚拟用户。1.5大数据量测试irt大数据量测试分为两种：一种是针对某些系

8、统存储、传输、统计查询等业务进行大数据 量的测试；另一种是与并发测试相结合的极限状态下的综合数据测试。如专项的大数据量测 试主要针对前者，后者尽量放在并发测试中。此外，也可以把大数据量测试分为运行时大 数据量测试与历史大数据量测试来进行测试用例设计。1-6配置测试配置测试主要指通过测试找到系统各项资源的最优分配原则。配置测试是系统调优的重 要依据。例如，可以通过不停地调整Oracle的内存参数来进行测试，使之达到一个较好的 性能。可以看出，配置测试本质上是前面提到的某些种类的性能测试组合在一起而进行的测 试。1-7可靠性测试在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否

9、稳定。 例如，可以施加让CPU资源保持70%90%使用率的压力，连续对系统加压8个小时，然 后根据结果分析系统是否稳定。这么多类型的性能测试看起来很吓人，实际上它们大多是密切相关的。例如，运行8 个小时来测试系统是否可靠，而这个测试极有可能包含了可靠性测试、强度测试、并发（用 户）测试、负载测试，等等。2性能测试应用领域性能测试往往是为了实现下面的一个或几个目标：/ 判定软件是否满足预期的性能需求；/根据测试结果判定软件的性能表现；/ 查找系统可能存在的性能问题，如果有，则找出并加以解决；/ 发现一些应用程序在功能实现方面的缺陷；, 对一些存在性能问题的系统，找出瓶颈并加以解决；/为用户部署系

10、统提供性能参考；性能测试应用领域：2.1系统的性能瓶颈定位系统的性能瓶颈定位是性能测试最常见的应用领域。借助LoadRunner等工具，可以在 测试场景运行过程中监控系统资源、Web服务器资源等运行数据，与响应时间进行同步分 析，可以在一定程度上进行性能瓶颈的分析与定位。2.2系统的参数配置通过性能测试可以测试系统在不同参数配置下的性能表现,进而找出令系统表现更优的 系统配置参数，为应用系统投产提供最佳配置建议。实际上，操作系统、数据库、中间件服务器等的参数配置是应用系统发生性能问题的重 要原因。例如分配给Oracle的内存大小与系统自身的业务特点有极大关系，配置不同的数据库, 性能表现就会不

11、同；而即使在内存一定的情况下，SGA的分配也会对性能产生很大的影响。 因此，要通过测试，以确定内存的最佳配置。2.3发现一些软件算法方面的缺陷一些多线程、同步并发算法在单用户模式下测试是很难发现问题的，只有通过模拟多用 户的并发操作，才能验证其运行是否正常与稳定。例如作者就经历过在一次性能测试过程中，测试人员模拟多个用户并发时发现的一个明 显的缺陷：测试对象是一个随机分配任务的模块，只要有用户申请，就会给用户分配任务。 这个算法在单用户情况下调试没有任何问题，但是当多个用户同时申请任务时，就发生了把同一任务分配给多个不同用户的现象。经证实，这个缺陷就是同步算法发生了问题而引起 的。2.4系统的

12、验收测试系统验收测试经常会验证一些预期的性能指标，或者验证系统中一些事务指标是否符合 用户期望，这时就需要借助性能测试来完成验证工作。随着用户对性能的重视，现在性能测试几乎是系统验收测试中必不可少的内容之一。用 户甚至自己进行专门的性能测试来验证系统上线前的性能，以保证运行时的性能稳定。因此, 性能测试在用户验收测试中越来越重要。2,5系统容量规划i=ii=i通过总结系统在不同硬件环境下的性能表现，可以为系统部署时提供非常好的参考。对 于一些性能要求较高的系统，性能测试可以为硬件规划提供很好的参考数据，使用户在购买 硬件时有据可依。例如同一系列机型：两颗CPU系统支持500用户并发、四颗CPU

13、支持 800用户并发，这些都是用户根据自身需求来规划硬件的重要依据。2.6产品评估/选型产品评估/选型是性能测试的又一应用领域。通过性能测试，可以对产品的软硬件性能 进行更全面的评估，选出更适合自己的产品类型。性能测试的应用领域越来越广，因此在实际工作中，性能测试往往会一次应用在一个或 多个领域。对于软件性能测试设计人员，应该根据测试的具体应用领域、测试原则和目标来 进行性能测试的规划与设计。3性能测试术语3.1吞吐量是指单位时间内系统处理的客户请求的数量。说明：F表示吞吐量，Nvu表示VU （虚拟 用户的）个数;R表示每个VU发出请求的数量;T表示性能测试所用的时间。如果出现了性能 瓶颈，上

14、面给的公式将不再成立。指在一次性能测试过程中网络上传输的据量的总和.吞吐 量/传输时间，就是吞吐率。正常情况下，吞吐量随点击率的增加，吞吐量也增加。（对于吞 吐量，单位时间内吞吐量越大，说明服务器的处理能力越好，而请求数仅表示客户端向服务 器发出的请求数，与吞吐量一般是成正比关系。)吞吐量：指在一次性能测试过程中网络上传输的数据量的总和。吞吐量/传输时间，就 是吞吐率。3.2 吞吐率(Throughput)通常用来指单位时间内网络上传输的数据量，也可以指单位时间内处理的客户端请求数 量。它是衡量网络性能的重要指标。但是从用户或业务角度来看，吞吐率也可以用请求数/秒或页面数/秒、业务数/小 时或

15、天、访问人数/天、页面访问量/天来衡量。例如在银行卡审批系统中，可以用千 件/每小时来衡量系统的业务处理能力。3.3 TPS (Transaction per second)每秒事务数是估算应用系统性能的重要依据。其意义是应用系统每秒钟处理完成的交易数量。一 般的，评价系统性能均以每秒钟完成的技术交易的数量来衡量。系统整体处理能力取决于 处理能力最低模块的TPS值。依据经验，应用系统的处理能力一般要求在10100左右。不 同应用系统的TPS有着十分大的差别，一般需要通过性能测试进行准确估算。每秒钟系统能够处理的交易或事务的数量。它是衡量系统处理能力的重要指标。TPS是 LoadRunner中重

16、要的性能参数指标。3.4性能计数器：性能计数器(counter)是描述服务器或操作系统性能的一些数据指标。例如:对windows操作系统，使用的内存数(memory in usage),进程时间(Total process Time)等都是常见的计数器。性能计数器在性能测试中发挥着“监控和分析的关键 作用，特别是在系统的可扩展性、进行性能瓶颈的定位时，对计数器取值的分析非常关键。3-5 响应时间(Responsetime):常与吞吐量、每秒点击数3个图结合起来分析对单个事务，响应时间就是完成事务所需的时间；对于用户任务，响应时间体现为端到 端的时间。响应时间就是用户感受软件系统为其服务所耗费的

17、时间，对于网站系统来说，响应时间 就是从点击了一个页面计时开始，到这个页面完全在浏览器里展现计时结束的这一段时间间 隔，看起来很简单，但其实在这段响应时间内，软件系统在幕后经过了一系列的处理工作, 贯穿了整个系统节点。根据“管辖区域”不同，响应时间可以细分为：(1) 服务器端响应时间，这个时间指的是服务器完成交易请求执行的时间，不包括客 户端到服务器端的反应(请求和耗费在网络上的通信时间)，这个服务器端响应时间可以度 量服务器的处理能力。(2) 网络响应时间，这是网络硬件传输交易请求和交易结果所耗费的时间。(3) 客户端响应时间，这是客户端在构建请求和展现交易结果时所耗费的时间，对于 普通的瘦

18、客户端Web应用来说，这个时间很短，通常可以忽略不计；但是对于胖客户端Web 应用来说，比如Java applet. AJAX,由于客户端内嵌了大量的逻辑处理，耗费的时间有可能 很长，从而成为系统的瓶颈，这是要注意的一个地方。如下图：请求响应时间是指从客户端发出请求到得到响应的整个过程的时间。这个过程从客户端 发送一个请求开始计时，到客户端接到从服务器端返回的响应结果计时结束。在某些工具中, 请求响应时间通常会被称为、TTLB，即Time to last byte,意思是从发送一个请求开始， 到客户端收到最后一个字节的响应为止所耗费的时间。请求响应时间的单位一般为秒或 毫秒。请求响应时间的分解

19、如图所示。图11 Web请求过程分解图从图可以看出，请求响应时间为网络响应时间和应用程序与系统响应时间之和, 具体由7个部分组成，即(N1+N2+N3+N4)+(A1+A2+A3)。3-6事务响应时间事务可能由一系列请求组成，事务的响应时间主要针对用户而言，属于宏观上的概念, 是为了向用户说明业务响应时间而提出的。例如：跨行取款事务的响应时间就是由一系列的 请求组成的。事务响应时间和后面的业务吞吐率都是直接衡量系统性能的参数。3.7点击数是衡量Web Server处理能力的一个很有用的指标。需要明确的是：点击数不是我们通 常理解的用户鼠标点击次数，而是按照客户端向Web Server发起了多少

20、次http请求计算的, 一次鼠标可能触发多个http请求，这需要结合具体的Web系统实现来计算。3.8 点击率(Hit Per Second)每秒钟用户向Web服务器提交的HTTP请求数。这个指标是Web应用特有的一个指标:Web应用是请求响应模式，用户发出一次申请，服务器就要处理一次，所以点击是Web 应用能够处理交易的最小单位。如果把每次点击定义为一次交易，点击率和TPS就是一个 概念。不难看出，点击率越大，对服务器的压力也越大。点击率只是一个性能参考指标，重 要的是分析点击时产生的影响。需要注意的是，这里的点击不是指鼠标的一次单击操作，因为在一次单击”操作中， 客户端可能向服务器发出多个

21、HTTP请求。3.9 思考时间(Think time)也称为休眠时间，从业务角度来说，这个时间指的是用户在进行操作时，每个请求之间 的时间的间隔时间。3.10资源利用率指的是对不同系统资源的使用程度，比如服务器的CPU利用率、磁盘利用率等资源利 用率是分析系统性能指标而改善性能的主要依据，因此，它是web性能测试工作重点.资源 利用率主要针对web服务器、操作系统、数据库服务器、网络等，是测试和分析瓶颈的主 要参数.在性能测试中，要根据需求采集具体的资源利用率参数进行分析.3.11并发：所有用户在同一时刻做同一件事情或操作，这种操作一般针对同一型的业务.狭义的并发一般分两种情况。一种是严格意义

22、上的并发，即所有的用户在同一时刻做同 一件事情或操作，这种操作一般针对同一类型的业务。例如在信用卡审批业务中，一定数目 的用户在同一时刻对已经完成的审批业务进行提交（操作的不是同一记录）；还有一种是特 例，即所有用户进行完全一样的操作，目的是测试数据库和程序对并发操作的处理。例如在 信用卡审批业务中，所有的用户可以一起申请业务，或者修改同一条记录。另外一种并发是广义的并发。这种并发与狭义的并发的区别是尽管多个用户对系统发出 了请求或进行了操作，但是这些请求或操作可以是相同的，也可以是不同的。对整个系统而 言，仍然有很多用户同时对系统进行操作，因此，仍然属于并发的范畴。可以看出，广义的并发是包含

23、狭义的并发的，而且广义的并发更接近用户的实际使用情 况，因为对大多数系统而言，只有数量很少的用户进行严格意义上的并发。对于性能测试 而言，这两种并发一般都需要进行测试，通常做法是先进行严格意义上的并发测试。严格意 义上的并发一般发生在使用比较频繁的模块中，尽管发生的概率不是特别高，但是一旦发生 性能问题，后果很可能是致命的。严格意义上的并发测试往往和功能测试关联起来，因为只 要并发功能遇到异常通常都是程序的问题，这种测试也是健壮性和稳定性测试的一部分。3.12并发用户数量：RunningVusers （运行的并发数）是指一次性提交的用户数量.并发用户数用来度量服务器并发容量和同步协调能力。在

24、客户端指一批用户同时执行一个操作。并发数反映了软件系统的并发处理能力，和吞吐量不 同的是，它大多是占用套接字、句柄等操作系统资源。并发用户：通俗意义上讲就是同时操作的用户，当然这个同时可以理解为同一时间段, 还可以理解为同一时间点，当然如果说并发就是同一时间点上同时操作的用户，这样理解没 有错误，但对于实际情况来讲，是没有严格意义上的并发执行的，就如同进程和线程关系一 样，在某一个点严格上讲就只有一个人得到执行的权利。3.13并发用户数量(Concurrent users； The number of concurrent users, Concurrency Level)并发用户数用来度量服

25、务器并发容量和同步协调能力。在客户端指一批用户同时执行一 个操作。并发数反映了软件系统的并发处理能力，和吞吐量不同的是，它大多是占用套接字、 句柄等操作系统资源。关于并发用户的数量，有两种常见的错误观点。一种错误观点是把并发用户数量理解为 使用系统的全部用户的数量，理由是这些用户可能同时使用系统；还有一种比较接近正确的 观点是把用户在线数量理解为并发用户数量。实际上，在线用户不一定会和其他用户发生并 发，例如正在浏览网页信息的用户，对服务器是没有任何影响的。但是，用户在线数量是统 计并发用户数量的主要依据之一。并发主要针对服务器而言，是否并发的关键是看用户的操作是否对服务器产生了影响。 因此，

26、并发用户数量的正确理解是，在同一时刻与服务器进行交互的在线用户数量。这些用 户的最大特征是和服务器发生了交互，这种交互既可以是单向传送数据的，也可以是双向传 送数据的。并发用户数量的统计方法目前还没有准确的公式，因为不同的系统会有不同的并发特 点。例如0A系统统计并发用户数量的经验公式为：使用系统的用户数量x (5%20%) o 对于这个公式，没有必要拘泥于计算出的结果，因为为了保证系统的扩展空间，测试时的并 发用户数量都会稍稍大一些，除非要测试系统能承受的最大并发用户数量。举例说明：如果 一个OA系统的期望用户为1 000个，只要测试出系统能支持200个并发用户就可以了。3.14场景：用例场景是通过描述流经用例的路径来确定的过程,这个流经过程要从用例开始到结束 遍历其中所有基本流和备选流。场景用于模拟用户实际业务操作。3.15 并发连接数 (The number of concurrent connections)并发连接数指的是某个时刻服务器所接受的请求数目，简单的讲，就是一个会话。