负载测试与性能测试.docx

负载测试与性能测试.docx

《负载测试与性能测试.docx》由会员分享，可在线阅读，更多相关《负载测试与性能测试.docx（34页珍藏版）》请在冰豆网上搜索。

负载测试与性能测试

1.什么是负载测试？

什么是性能测试？

性能测试（或称多用户并发性能测试）、负载测试、强度测试、容量测试是性能测试领域里的几个方面，但是概念很容易混淆。

下面将几个概念进行介绍。

性能测试（PerformanceTest）：

通常收集所有和测试有关的所有性能，通常被不同人在不同场合下进行使用。

关注点：

howmuch和howfast

负载测试（LoadTest）：

负载测试是一种性能测试，指数据在超负荷环境中运行，程序是否能够承担。

关注点：

howmuch

强度测试（StressTest）：

强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况，目的是找到系统在哪里失效以及如何失效的地方。

包括

Spiketesting：

短时间的极端负载测试

Extremetesting：

在过量用户下的负载测试

Hammertesting：

连续执行所有能做的操作

容量测试（VolumeTest）：

确定系统可处理同时在线的最大用户数

关注点：

howmuch（而不是howfast）

容量测试，通常和数据库有关，容量和负载的区别在于：

容量关注的是大容量，而不需要表现实际的使用。

其中，容量测试、负载测试、强度测试的英文解释为：

VolumeTesting=Largeamountsofdata

LoadTesting=Largeamountofusers

StressTesting=Toomanyusers,toomuchdata,toolittletimeandtoolittleroom

2.性能测试包含了哪些测试（至少举出3种）

包含以下测试类型：

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

                    争用测试：

-核实测试对象对于多个主角对相同资源（数据记录、内存等）的请求的处理是否可以接受。

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

                    负载测试（LoadTest）-是一种性能测试，指数据在超负荷环境中运行，程序是否能够承担。

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

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

性能测试的过程应该为六个阶段，分别是[b]发现、探究、提案、执行、复查、收尾[/b]。

原文如下：

1，    Discovertheproblem：

发现问题。

这个步骤最重要的就是发现（Discover）问题，详述问题（Discribe）,并且正确而详细地记录（Document）下来。

在进入下一步骤前，我们测试人员应该问问自已以下这些问题：

  [b]·对于问题是否已经有简明的描述

    ·用户的基线与期待在哪[/b]    

2，    Exploretheconditions：

探究原因，为问题提供明确的定义与定位。

这个步骤的主要任务：

是广泛搜集相关数据，尽量了解系统的每一个方面，避免深入分析时，漏了某个关键的现象而误入歧途；重点：

是探索（Explore），寻找证据（Evidence）,建立（Establish）整个问题的来龙去脉的假设。

有的时候在这个阶段就可以发现重大问题，一眼就看出关键点，例如硬件毁损，某个硬盘区块或内存块不稳，或某个其他程序吃掉所有的内存，让SQLServer无内存可用，或是该程序常常死当，拖垮CPU等等。

3，    Trackdownpossibleapproaches：

提供可能的解决方案。

这个步骤的主要任务：

深入分析数据间的关联性，并对整个问题的前因后果提出假设，最后拟定出相应的策略（计划）。

如果前一个步骤做得不够详实，在这个步骤我们可能就会误判，导致努力的半天，但就是找不到瓶颈点。

这个步骤的最重要的动作：

是拟定计划。

一个好的计划，你才能知道方向与步骤。

4，    Executethemostlikelyapproach：

执行最有可能的解决方案。

这是DETECT方法中最简单的一步，因为只要执行上一步中所拟定的计划就行了。

但是在执行计划时，仍然要注意系统的反应（随时都可能会要放弃当前的计划，因为新的证据可能证明你先前的判断错误，因而要修正计划，甚至是退回到上一步以重新拟定计划。

这时切勿躁，因为整个性能测试的过程就是在考验团队的细心与耐力、知识的广度与深度！

），同时还要小心观察会不会有新的问题出现并严重影响当前系统的执行，不要原来系统迟缓，而你的测试却成为压垮骆驼的最后一根稻草。

5，    Checkforsuccess（如果需要的话，重复之前的步骤）：

确认解决方案成功与否。

这一步骤主要任务是：

重新收集数据，以验证该计划的成功与否。

如果证实假设是对的，则继续搜集相关数据，以确立接下来的步骤；如果到这一步发现执行的结果不如预期，证明我们的假设错误。

这会非常让人气tuo,进而放弃这个性能测试的方法，因为无法忍受整个时间的流失。

其实，定错性能的目标是常有的事，这个方法论就是要你在错误的当前，停下来好好思考，重新理出头绪，最重要的是要清楚知道这一回是错在哪，如此新的步骤就能更逼近目标。

有系统的犯错，是整个计划的一部分，踩着错误走向成功是性能测试的常态。

6，    Tieuplooseends：

完成收尾工作。

重复前五个步骤直到达到目标。

但当我们完成目标后，依然要注意以下的问题：

    [b]·解决的方式是否有边际效应，造成其他的问题[/b]  例如：

为了某类的查询工作建立了大量的索引，事后原本正常的新建、修改、删除都出现了性能问题。

    [b]·是否真正根除了问题，还是仅表象地头痛医头，脚痛医脚[/b]建立问题的假设时，很容易将问题特殊化，仅局部地解决该现象。

例如：

加了某个索引或稍稍改变查询语法，舒缓了当前的瓶颈，但当用户稍微增加，或是采用了不同的查询方式，就老问题复发。

    [b]  ·是否要建立持续跟踪的计划[/b]

1、用户确定需要进行性能测试的业务或交易，通过用户操作和VuserGenerator的录制功能来记录并生成虚拟用户脚本。

2、手工修改虚拟用户脚本，确定脚本能够回放成功。

3、在Controller中对场景进行培植后，就可以启动测试了。

在测试过程中，Controller控制LoadGernerator对被测系统的加压方式和行为。

4、Controller同时负责搜集被测系统各个环节的性能数据。

各个LoadGeneratro会记录最终用户响应时间和脚本执行的日志。

5、压力运行结束以后，LoadGenerator将数据传到Controller中，由Controller对测试结果进行汇总。

6、测试人员借助数据分析工具Analysis对性能测试数据进行分析，进而确定瓶颈和调优方法。

7、针对性地对系统进行调优，重复进行压力测试，确定性能是否有所提高。

5.什么时候可以开始执行性能测试？

6.LoadRunner由哪些部件组成？

VirtualUserGenerator：

捕捉终端用户事务处理过程，自动生成可以被Virtualuser识别的性能测试脚本；

Controller：

组织、驱动、管理和监视负载测试；

LoadGenerators：

执行virtualuser创建附负载；

Analysis：

帮助用户观看、剖析比较性能测试结果；

Launcher：

提供访问LoadRunner所有部件的唯一接口。

7.你使用LoadRunner的哪个部件来录制脚本？

8.LoadRunner的哪个部件可以模拟多用户并发下回放脚本？

9.什么是集合点？

设置集合点有什么意义?

Loadrunner中设置集合点的函数是哪个?

插入集合点是为了衡量在加重负载的情况下服务器的性能情况。

在测试计划中，可能会要求系统能够承受1000人同时提交数据，在LoadRunner中可以通过在提交数据操作前面加入集合点，这样当虚拟用户运行到提交数据的集合点时，LoadRunner就会检查同时有多少用户运行到集合点，如果不到1000人，LoadRunner就会命令已经到集合点的用户在此等待，当在集合点等待的用户达到1000人时，LoadRunner命令1000人同时去提交数据，从而达到测试计划中的需求。

说明：

在脚本中设置了“集合点”后，当运行场景时可以对集合点进行设置，可以设置当百分之多少用户到达时，系统开始执行操作

设置集合点的函数：

lr_think_time

10.什么是场景？

场景的重要性有哪些?

如何设置场景?

运行场景描述在测试活动中发生的各种事件，一个运行场景包括一个运行虚拟用户活动的LoadGenerator机器列表，一个测试脚本的列表以及大量的虚拟用户和虚拟用户组

创建场景使用Controller-NewScenario

场景重要性？

？

？

？

？

11.请解释一下如何录制web脚本？

这需要你自己总结

12.为什么要创建参数?

如何创建参数?

参数可以让你在建立试脚本后，利用几套不同的实际发生数据来测试应用程序，从而反映出系统的负载能力。

以一个订单输入过程为例，参数化操作可将记录中的固定数据，如订单号和客户名称，由可变值来代替。

（绿色部分是举例说明）

LoadRunner通过DataWizard来自动实现其测试数据的参数化

13.什么是关联？

请解释一下自动关联和手动关联的不同。

如何在LoadRunner脚本中做关联（Correlation）

当录制脚本时，VuGen会拦截client端（浏览器）与server端（网站服务器）之间的对话，并且通通记录下来，产生脚本。

在VuGen的RecordingLog中，您可以找到浏览器与服务器之间所有的对话，包含通讯内容、日期、时间、浏览器的请求、服务器的响应内容等等。

脚本和RecordingLog最大的差别在于，脚本只记录了client端要对server端所说的话，而RecordingLog则是完整纪录二者的对话。

当执行脚本时，您可以把VuGen想象成是一个演员，它伪装成浏览器，然后根据脚本，把当初真的浏览器所说过的话，再对网站伺服器重新说一遍，VuGen企图骗过服务器，让服务器以为它就是当初的浏览器，然后把网站内容传送给VuGen。

所以纪录在脚本中要跟服务器所说的话，完全与当初录制时所说的一样，是写死的（hard-coded）。

这样的作法在遇到有些比较聪明的服务器时，还是会失效。

这时就需要透过「关联（correlation）」的做法来让VuGen可以再次成功地骗过服务器。

何谓关联（correlation）？

所谓的关联（correlation）就是把脚本中某些写死的（hard-coded）数据，转变成是撷取自服务器所送的、动态的、每次都不一样的数据。

举一个常见的例子，刚刚提到有些比较聪明的服务器，这些服务器在每个浏览器第一次跟它要数据时，都会在数据中夹带一个唯一的辨识码，接下来就会利用这个辨识码来辨识跟它要数据的是不是同一个浏览器。

一般称这个辨识码为SessionID。

对于每个新的交易，服务器都会产生新的SessionID给浏览器。

这也就是为什么执行脚本会失败的原因，因为VuGen还是用旧的SessionID向服务器要数据，服务器会发现这个SessionID是失效的或是它根本不认识这个SessionID，当然就不会传送正确的网页数据给VuGen了。

下面的图示说明了这样的情形：

当录制脚本时，浏览器送出网页A的请求，服务器将网页A的内容传送给浏览器，并且夹带了一个ID=123的数据，当浏览器再送出网页B的情求时，这时就要用到ID=123的数据，服务器才会认为这是合法的请求，并且把网页B的内容送回给浏览器。

在执行脚本时会发生什么状况？

浏览器再送出网页B的请求时，用的还是当初录制的ID=123的数据，而不是用服务器新给的ID=456，整个脚本的执行就会失败。

要对付这种服务器，我们必须想办法找出这个SessionID到底是什么、位于何处，然后把它撷取下来，放到某个参数中，并且取代掉脚本中有用到SessionID的部份，这样就可以成功骗过服务器，正确地完成整个交易了。

哪些错误代表着我应该做关联（correlation）？

假如脚本需要关联（correlation），在还没做之前是不会执行通过的，也就是说会有错误讯息发生。

不过，很不幸地，并没有任何特定的错误讯息是和关联（correlation）有关系的。

会出现什么错误讯息，与系统实做的错误处理机制有关。

错误讯息有可能会提醒您要重新登入，但是也有可能直接就显示HTTP404的错误讯息。

要如何做关联（correlation）？

关联（correlation）函数

关联（correlation）会用到下列的函数：

•web_reg_save_param：

这是最新版，也是最常用来做关联（correlation）的函数。

语法：

web_reg_save_param（“ParameterName”,,LAST）;

•web_create_html_param、web_create_html_param_ex：

这二个函数主要是保留作为向前兼容的目的的。

建议使用web_reg_save_param函数。

详细用法请参考使用手册。

在VuGen中点选【Help】>【Functionreference】>【Contexts】>【WebandWirelessVuserFunctions】>【CorrelationFunctions】。

如何找出要关联（correlation）数据

简单的说，每一次执行时都会变动的值，就有可能需要做关联（correlation）。

VuGen提供二种方式帮助您找出需要做关联（correlation）的值：

1.自动关联

2.手动关联

自动关联

VuGen内建自动关联引擎（auto-correlationengine），可以自动找出需要关联的值，并且自动使用关联函数建立关联。

自动关联提供下列二种机制：

•RulesCorrelation：

在录制过程中VuGen会根据订定的规则，实时自动找出要关联的值。

规则来源有两种：

o内建（Built-inCorrelation）：

VuGen已经针对常用的一些应用系统，如AribaBuyer、BlueMartini、BroadVision、InterStage、mySAP、NetDynamics、Oracle、PeopleSoft、Siebel、SilverJRunner等，内建关联规则，这些应用系统可能会有一种以上的关联规则。

您可以在【RecordingOptions】>【InternetProtocol】>【Correlation】中启用关联规则，则当录制这些应用系统的脚本时，VuGen会在脚本中自动建立关联。

您也可以在【RecordingOptions】>【InternetProtocol】>【Correlation】检视每个关联规则的定义。

o使用者自订（User-definedRulesCorrelation）：

除了内建的关联规则之外，使用者也可以自订关联规则。

您可以在【RecordingOptions】>【InternetProtocol】>【Correlation】建立新的关联规则。

•CorrelationStudio：

有别于RulesCorrelation，CorrelationStudio则是在执行脚本后才会建立关联，也就是说当录制完脚本后，脚本至少须被执行过一次，CorrelationStudio才会作用。

CorrelationStudio会尝试找出录制时与执行时，服务器响应内容的差异部分，藉以找出需要关联的数据，并建立关联。

RuleCorrelation

请依照以下步骤使用RuleCorrelation：

1.启用auto-correlation

1.点选VuGen的【Tools】>【RecordingOptions】，开启【RecordingOptions】对话窗口，选取【InternetProtocol】>【Correlation】，勾选【Enablecorrelationduringrecording】，以启用自动关联。

2.假如录制的应用系统属于内建关联规则的系统，如AribaBuyer、BlueMartini、BroadVision、InterStage、mySAP、NetDynamics、Oracle、PeopleSoft、Siebel、SilverJRunner等，请勾选相对应的应用系统。

3.或者也可以针对录制的应用系统加入新的关联规则，此即为使用者自订的关联规则。

4.设定当VuGen侦测到符合关联规则的数据时，要如何处理：

【Issueapop-upmessageandletmedecideonline】：

跳出一个讯息对话窗口，询问您是否要建立关联。

♣

【Performcorrelationinsceipt】：

直接自动建立关联♣

2.录制脚本

开始录制脚本，在录制过程中，当VuGen侦测到符合关联规则的数据时，会依照设定建立关联，您会在脚本中看到类似以下的脚本，此为BroadVision应用系统建立关联的例子，在脚本批注部分可以看到关联前的数据为何。

3.执行脚本验证关联是OK的。

CorrelationStudio

当录制的应用系统不属于VuGen预设支持的应用系统时，RuleCorrelation可能既无法发挥作用，这时可以利用CorrelationStudio来做关联。

CorrelationStudio会尝试找出录制时与执行时，服务器响应内容的差异部分，藉以找出需要关联的数据，并建立关联。

使用CorrelationStudio的步骤如下：

1.录制脚本并执行

2.执行完毕后，VuGen会跳出下面的【ScanActionforCorrelation】窗口，询问您是否要扫描脚本并建立关联，按下【Yes】按钮。

3.扫描完后，可以在脚本下方的【CorrelationResults】中看到扫描的结果。

4.检查一下扫瞄的结果后，选择要做关联的数据，然后按下【Correlate】按钮，一笔一笔做，或是按下【CorrelateAll】让VuGen一次就对所有的数据建立关联。

注意：

由于CorrelationStudio会找出所有有变动的数据，但是并不是所有的数据都需要做关联，所以不建议您直接用【CorrelateAll】。

5.一般来说，您必须一直重复步骤1~4直到所有需要做关联的数据都找出来为止。

因为有时前面的关联还没做好之前，将无法执行到后面需要做关联的部份。

有可能有些需要做关联的动态数据，连CorrelationStudio都无法侦测出来，这时您就需要自行做手动关联了。

手动关联

手动关联的执行过程大致如下：

1.使用相同的业务流程与数据，录制二份脚本

2.使用WinDiff工具协助找出需要关联的数据

3.使用web_reg_save_param函数手动建立关联

4.将脚本中有用到关联的数据，以参数取代

接下来将详细的说明如何执行每个步骤

使用相同的业务流程与数据，录制二份脚本

1.先录制一份脚本并存档。

2.依照相同的操作步骤与数据录制第二份脚本并存盘。

注意，所有的步骤和输入的数据一定都要一样，这样才能找出由服务器端产生的动态数据。

有时候会遇到真的无法使用相同的输入数据，那您也要记住您使用的输入数据，到时才能判断是您输入的数据，还是变动的数据。

使用WinDiff工具协助找出需要关联的数据

1.在第二份脚本中，点选VuGen的【Tools】>【ComparewithVuser…】，并选择第一份脚本。

2.接着WinDiff会开启，同时显示二份脚本，并显示有差异的地方。

WinDiff会以一整行黄色标示有差异的脚本，并且以红色的字体显示真正差异的文字。

（假如没看到红色字体，请点选【Options】>【View】>【ShowInlineDifferences】）。

3.逐一检视二份脚本中差异的部份，每一个差异都可能是需要做关联的地方。

选取差异的脚本，然后复制。

在复制时，有时并不需要取整行脚本，可能只会选取脚本中的一部分。

注意：

请忽略lr_thik_time的差异部份，因为lr_thik_time是用来模拟每个步骤之间使用者思考延迟的时间。

4.接着要在RecordingLog（单一protocol）或是GenerationLog（多重protocol）中找这个值。

将鼠标光标点到RecordingLog的第一行开头，按下Ctrl+F，开启【Find】窗口，贴上刚刚复制的脚本，找出在RecordingLog第一次出现的位置。

结果会有二种：

o在RecordingLog中找不到要找的数据，这时请先确认您找对了脚本，毕竟现在开启了二个几乎一样的脚本，很容易弄错。

o在RecordingLog中找到了要找的数据，这时要确认数据是从服务器端传送过来的。

首先可以先检查数据的标头，从标头的Receivingresponse可以知道数据是从服务器端传送到client端的。

假如此数据第一次出现是在Sendingrequest中，则表示此数据是由client端产生，不需要做关联，但是有可能需要做参数化（parameterized）。

您要找的标头格式如下：

***[tid=b9Action12]Receivingresponsefromhostastra.merc-:

80（25/11/200212:

04:

00）

5.现在您已经找到录制二次都不一样，而且是由服务器所产生的动态数据了，而此数据极有可能需要做关联。

使用web_reg_save_param函数手动建立关联

在找到是由服务器所产生的动态数据之后，接下来要做的就是找出适当的位置，使用web_reg_save_param函数，将这个动态数据撷取到某个参数中。

1.要在哪里使用web_reg_save_param函数？

在之前的步骤，我们已经在ExecutionLog找到可能需要关联的动态数据。

在ExecutionLog中选取动态数据前的文字然后复制，我们将会利用这段文字，来帮助我们找出要关联的动态数据。

不过在这之前我们要先找出使用web_reg_save_param函数的正确位置，所以我们要再重新执行一遍脚本，而且这次会开启所有的Log。

1.在VuGe