性能测试进阶指南：Loadrunner实战91_第4章负载生成及监控.docx

《性能测试进阶指南：Loadrunner实战91_第4章负载生成及监控.docx》由会员分享，可在线阅读，更多相关《性能测试进阶指南：Loadrunner实战91_第4章负载生成及监控.docx（47页珍藏版）》请在三一办公上搜索。

1、第4章 负载生成及监控Controller24.1 设计场景24.1.1 新建场景24.1.2 负载生成器管理174.1.3 用户管理204.1.4 运行设置204.1.5 IP虚拟224.1.6 场景运行原理254.1.7 Service Level Agreement(服务品质保障)274.2 系统监控314.2.1 Scenario Groups(场景用户状态)314.2.2 Scenario Status(场景运行状态)324.2.3 计数器原理334.2.4 计数器管理354.2.5 SiteScope424.3 场景运行444.4 QTP脚本在场景中的运行454.5 场景数据46小

2、结47第4章 负载生成及监控Controller当虚拟用户脚本开发完成后，使用Controller将这个执行脚本的用户从单人转化为众人，从而模拟大量用户操作，进而形成负载。我们需要对这个负载模拟的方式和特征进行配置，从而形成场景。场景(Scenario)是一种用来模拟大量用户操作的技术手段，通过配置和执行场景向服务器产生负载，验证系统各项性能指标是否达到用户要求，而Controller可以帮助我们对场景的设计、执行及监控进行管理。使用Controller管理场景主要分为场景设计和场景监控两部分，最后通过运行场景完成性能测试的执行。场景执行的流程如图4.1所示。图4.1场景执行流程4.1 设计场

3、景通过对场景的设计从而形成和用户需求相同的真实负载。4.1.1 新建场景场景分为目标场景和手工场景，创建场景有两种方式。图4.5目标场景设置窗口单击Edit Scenario Goal按钮打开目标场景编辑对话框，如图4.6所示。图4.6设置目标场景中的目标在目标场景中最重要的就是目标类型，目标场景提供了五种目标，如图4.7所示，每种目标都有自己独立的设置。图4.7目标场景中提供的目标类型1. Virtual Users该参数表示虚拟用户数，被测系统所需要支持的用户数。这里只需要填写系统能够达到的用户数目即可。例如：需求规定该系统能够支持100个用户在线发帖。录制用户登录发帖后，在目标场景中将G

4、oal Type(目标类型)选择为Virtual Users，设置Reach goal of为100个用户即可，如图4.8所示。图4.8设置目标为100个在线用户2. Hits per Second该参数表示每秒点击数，是指在一秒钟能做到的点击请求数目，即客户端产生的每秒请求数(正常情况下每秒点击数等同于服务器请求响应数)。除了要设置点击的指标，还需要设置在线用户的上下限，场景运行时会自动调整用户数，来测试在一定的用户范围内系统是否都能达到定义的目标。例如：需求规定系统能够支持50150个在线用户进行浏览操作，客户端发出的请求能力为100次s(也就是正常情况下系统能够提供每秒钟返回100次HT

5、TP头为200 OK的服务器应答)。录制用户浏览操作后，在目标场景中将Goal Type(目标类型)设置为Hits per Second，设置Reach goal of为100次点击，再设置用户数最小为50最大为150即可，如图4.9所示。图4.9设置每秒点击数目标3. Transactions per Second该参数表示每秒事务数，一个事务代表完成一个操作，每秒事务数反映了系统的处理能力。当脚本中含有事务函数时才可以使用，这里需要指定事务名称、TPS指标以及需要完成该指标的用户数。例如：需求规定系统能够在50150个用户下，能够每秒处理100个用户的登录操作。在录制用户登录操作后，为登录

6、行为添加事务，事务名称为login，设置目标场景的Goal Type(目标类型)为Transactions per Second，选择事务名称为login，设置Reach goal of为100，再设置用户数最小为50最大为150即可，如图4.10所示。图4.10设置每秒事务数目标4. Transactions Response Time该参数表示事务的响应时间，反映了系统的处理速度以及做一个操作所需要花费的时间。和Transactions per Second类似，当脚本中含有事务函数时，可以设定事务响应时问的指标。例如：需求规定系统能够支持50150个在线用户，登录操作的响应时间在1秒以内

7、。在脚本中包含登录操作的事务，设置目标场景的Goal Type(目标类型)为Transactions Response Time，选择事务名称为login，设置Reach goal of为1秒，再设置用户数最小为50最大为150即可，如图4.11所示。图4.11设置事务响应时间目标5. Pages per Minute该参数表示每分钟页面的刷新次数，反映了系统在每分钟下所能提供的Page(页面)处理能力。页面的生成能力反映了一个系统的整体处理能力，一个页面请求包含了多个点击请求。例如：需求规定系统在50150个用户在线的情况下，能够每秒处理33个页面请求。设置目标场景的Goal Type(目标

8、类型)为Pages per Minute，设置Reach goal of为2000页面每分钟，再设置用户数最小为50最大为150即可，如图4.12所示。图4.12设置每分钟页面处理量目标当设置完成性能的目标后，还需要设置一下场景运行时的模式。这里分为两大部分。(1) Scenario Settings(场景设置)提供对目标场景运行的一些基础设置，如图4.13所示。图4.13目标场景的场景设置Run Time是指当目标达到后，需要继续运行多少时间来测试系统的稳定性，默认情况为30分钟。目标场景是定性型场景，目标达到并不代表系统就满足了用户需求，还需要进行一段时间的稳定性测试，确保该指标能够在一段

9、时间内达到。而如果目标无法达到，又该如何处理呢?Stop scenario and save results：如果无法达到目标，那么整个场景停止运行。Continue scenario without reaching：无法达到目标场景但仍继续运行。当勾选了Receive notification复选框时，一旦出现目标无法达到的情况，Controller会弹出信息框，提示信息The target you defined cannot be reached。(2) Load Behavior(负载生成)提供了对目标场景负载生成方式Ramp Up的设置，如图4.14所示。此处可以使用自动管理，也可

10、以手工设置一个需要达到目标的时间。图4.14目标场景的负载规则设置当设置完成后，就可以启动目标场景，Controller会自动调整用户个数形成负载，确认在这种负载情况下，定义的目标都可以达到。目标场景的目的就是通过设置目标来验证系统能否达到目标，在项目最后需要确认质量时可以使用目标场景来完成最终的测试报告，而当需要定位瓶颈的时候我们还是推荐使用手工场景。在最终的验收测试中经常需要多个功能同时满足某一性能目标。例如：某系统的需求规定50150个用户同时在线时(其中用户类型和所占比例为：登录论坛用户20，浏览论坛用户40，论坛发帖用户40)，每个用户打开一篇帖子的响应时问在2秒以内。那么我们就需要

11、在目标场景中添加这三种用户行为的脚本，通过Scenario Script中的“of Target”设置每个脚本用户所占的比例，设置场景目标类型为事务响应时间，浏览操作的响应时间为2秒即可。手工场景(Manual Scenario)手工场景就是自行设置虚拟用户的变化，通过设计用户的添加和减少过程，来模拟真实的用户请求模型，完成负载的生成。手工场景是定量型性能测试，我们通过掌握在负载的增加过程中系统各个组件的变化情况，从而定位性能瓶颈并了解系统处理能力，一般在负载测试和压力测试中应用。例如需要了解一个运动员能够举起多重的杠铃，那么可以先给出一个足够轻的杠铃(10公斤)，然后让他举一下，如果可以举起

12、来，那么再增加5公斤，重新试举，如此往复直到无法举起为止。通过这个过程可以了解该运动员的最大举重重量。每次增加的举重重量越小，最后得出的最大重量越准确。好比高考前层层模拟考，目的就是让学生了解自己的学习情况和考试成绩，为填报志愿提供参考。手工场景主要是在设计用户变化，通过手工场景可以帮助我们分析系统的性能瓶颈。手工场景的核心就是设置用户负载方式，通过Scenario Schedule的Schedule by和Run Mode选项可以对虚拟用户的负载方式进行设置，如图4.15所示。图4.15手工场景中的ScenarioSchedule我们设置场景最大在线用户为10人，每隔15秒钟增加2个负载用户

13、，1分钟后达到最大在线用户数，持续5分钟后，用户每30秒结束5个负载用户，整个场景共耗时6分30秒。通过设置Global Schedule来设计用户的增加和减少过程，具体的用户负载情况会在右侧的Interactive Schedule Graph中显示出来，如图4.16所示。图4.16 Interactive Schedule Graph场景负载图手工场景在Schedule by中分为Scenario模式和Group模式。Scenario模式Scenario模式是指所有脚本都使用相同的场景模型来运行，只需要分配每个脚本所使用的用户个数即可。Scenario模式下的Run Mode有两大类：Re

14、al-life schedule和Classic schedule。在LoadRunner 9以前的手工场景设计中，只有一种情况可以设定，就是一个用户脚本的运行场景分为用户上升、用户持续、用户下降三个过程，只要系统满足了峰值数据后，即可证明系统能够满足性能需求，但这并不是真实的负载情况。从LoadRunner 9开始提供了Real-life schedule，也就是说可以建立一个完全真实的场景，不用像以前那样只能模拟一个山峰，从而实现压力测试和真实情况下的负载测试。Real-life schedule(真实场景模式)和以前不同的是这里可以通过Add Action来添加多个用户变化的过程，包括多

15、次负载增加Start Vusers、持续时间Duration或递减Stop Vusers，如图4.17所示。图4.17 Real.1ife下的GlobalSchedule场景添加负载策略我们先来学习设置用户的初始化方式。双击Initialize Action，弹出Edit Action窗口，如图4.18所示。图4。18虚拟用户初始化策略系统提供了3种初始化用户的方式，一般使用默认选项即在每个虚拟用户开始运行前进行初始化。然后学习设置负载增加Start Vusers。双击Start Vusers可以打开负载用户增加的策略设置窗口，如图4.19所示。图4.19修改StartVusers用户增长负载

16、趋势在这里可以设置产生负载的用户数，在默认情况下一般使用每隔一段时问增加一定的用户负载方式，但也可以设置为立即一次性加载用户。建议设置为周期性负载增长模式，这样能够更加有效地获得系统在各个负载下的性能指标(避免一次负载太大，系统无法承受)，除非需要做某些特殊情况的模拟。接着设置负载持续时间Duration。双击Duration打开设置窗口。在这里可以设置持续时间长度，通过一定时间的负载可以测试系统在该负载情况下的稳定性，如图4.20所示。图4.20修改用户负载持续时间最后设置负载释放的过程Stop Vusers。双击Stop Vusers打开设置窗口，这里提供了两种释放负载的策略，如图4.21

17、所示。一般来说可以设置用户直接停止，也可以通过设置负载逐渐下降，分析系统回收资源的能力。图4.21修改Stop Vusers用户负载递减策略通过反复添加Start Vusers/Duration/Stop Vusers可以生成一个波浪型的场景，正是因为这是一种完全自由的场景设计方式，所以才被称为Real-life，即完全真实地模拟用户负载的过程，通过这个过程的模拟克服了以前场景想要模拟负载反复起伏的困难。例如：需要模拟以下场景：3分钟用户数达到300个，持续5分钟后，用户数在1分钟内下降至50个，最后2分钟内再上升到500个，那么可以设计为：Start Vusers：3分钟达到300个，即每6

18、秒增加10个用户，共300个用户Duration：5分钟Stop Vusers：1分钟减少250个用户，每6秒减少25个用户Start Vusers：2分钟增加450个用户，每6秒增加12.5个用户Real-life schedule模式常常用在压力测试和稳定性测试中，了解系统在长时间波动负载下资源管理的能力，而Real-life的负载策略是根据性能需求模型来确定的。Classic Schedule(经典模式)这种模式就是老版本的场景设计模式，只能设置一次负载的上升持续和下降。常见的负载测试都是通过Classic方式实施的。在Classic Schedule模式下，用户的Duration持续时

19、间设置会多出Run until Complete和Run indefinitely两种方式。其中，Run until Complete指脚本只会被执行一次；而Run indefinitely指脚本会永不停止地运行下去。经典模式其实在很多时候已经够用了，通过它生成一个峰值负载，只要系统能够满足这个峰值即可。一般来说只要峰值下满足性能需求，那么常规情况也能满足性能需求。但是有时候会发现虽然峰值性能指标能满足，但系统还是会出问题。这是因为系统并不是长期都处在高负载状态下，随着负载的变化，系统的资源在不断地申请释放。如果在这个过程中存在微量的资源回收失败，那么时间一长系统就会出问题。另一方面我们知道性

20、能测试需要对用户行为进行模拟，如果场景只有经典模式那么如何模拟真实的用户负载波动呢?所以这个时候Real-life就有意义了，它可以设置一个和真实情况类似的场景来实现负载。负载的真实性是受到脚本影响的，一般Real-life运行的脚本会更偏向于模拟用户操作流程，而Classic的脚本则更偏向于模拟一种操作。例如：设置一个Real-life的脚本，那么该脚本就可能包含用户随机逻辑选择、ThinkTime的变化等情况，尽可能真实地模拟系统负载状态；而Classic的脚本，只需要针对某一种操作进行模拟即可，这样可以获得该操作在性能负载下的情况，从而逐个确认性能指标，最终再将所有脚本加载，了解整个系统

21、的性能指标。以上介绍了两种场景的运行模式，那么当多个脚本在场景中运行时，我们如何配置它们之间的关系呢?在Scenario模式下经常需要模拟多个脚本共同运行的情况，从而测试系统在多种业务下的处理能力。例如：需求规定系统能够同时支持300个用户在线进行浏览操作和100个用户进行发帖操作，那么场景就需要添加两套脚本，如图4.22所示。在手工场景中，用户脚本都被称为Group，这是因为每一个用户组都代表一种脚本操作，通过组名来区别脚本之间的关系。图4.22手工场景中添加多个Group脚本如何修改各个Group的Quantity用户数呢?首先需要将场景的用户修改为百分比模式，选中Scenario菜单下的

22、Convert Scenario to the Percentage Mode，将场景用户模式改为百分比模式，如图4.23所示。图4.23切换手工场景用户数为百分比模式修改view的比例为75，然后取消选择Convert Scenario to the Percentage Mode选项，这个时候view用户数就变为300了，而post topic用户数变为100。场景的运行图如图4.24所示。图4.24多脚本场景Interactive Schedule Graph两个脚本是使用同样的负载方式进行的，只是根据用户的比例分配负载增加的趋势，这里设置了每隔15秒增加20个用户，也就是每15秒增加5

23、个发帖用户以及15个查看用户。Group模式在Group模式下，除了可以独立设置脚本开始原则以外，还可以通过Start Group策略为脚本之间设置前后运行关系。双击Group Schedule下的Start Group Action，打开Start Group策略，设置该脚本在手工场景下的Group模式中如何开始运行，如图4.25所示。图4.25 Group模式下的Start Group策略其中，Start immediately after the scenario begins表示当场景一开始就立即运行；Start (HH:MM:SS)after the scenario begins表

24、示当场景运行后多少时间后再运行;Start when group finishes表示当某一个group结束后再运行。脚本之间的场景设计使用不同的颜色区别，选中脚本可以修改该脚本的运行设置，如图4.26所示。图4.26 Group模式下多脚本Interactive Schedule Graph这里设置了temp脚本是在analysis脚本场景运行结束后再运行。在某些负载策略中需要使用Group模式才能完成场景设计。例如：需求规定系统在每日的19点至20点进行数据收集，而在21点至23点进行数据的分析。那么这时需要分别生成数据收集和数据分析的两套脚本，通过Group方式来设置场景中这两个脚本的先

25、后关系，来模拟系统的负载情况。图形化场景设计通过手工修改负载的变化趋势十分烦琐，在设计时还要通过一定的计算才能设计出符合需求的负载场景，而在LoadRunner 9后，这种操作从过去计算的模式变化成为可以直接拖曳的模式，大大降低了设计场景的复杂度。在右侧的Schedule Graph图中单击Edit mode按钮，如图4.27所示。Schedule Gragh中的节点会显示出来，这时就可以使用鼠标对图中的节点进行修改，如图4.28所示。 图4.27Schedule Graph中的 图4.28在Edit mode下对Edit mode按钮 Schedule Graph进行修改通过直接拖曳节点来完

26、成对用户变化规律的设置，也可以通过单击(Split Action)按钮实现对当前选中的线条进行分割。到这里我们介绍了目标场景和手工场景两种场景类型。场景提供脚本运行的方式，通过目标场景进行定性型负载，通过手工场景进行定量型负载。设计场景在工具上并没有复杂的内容，关键在于需求和性能测试的目标，设计的场景到底为了测试什么东西是在场景没计前需要好好考虑的。一般通过在场景中运行一种用户行为可以对某一个功能点进行性能测试和分析，如果需要对整个系统的运行情况进行性能测试和分析，就需要同时运行多个脚本。如果在场景中加载多个脚本，并分别设置其负载方式，就能完成真实情况下的负载模拟。4.1.2 负载生成器管理当

27、对场景进行设计后，接着需要对负载生成器进行管理和设置。Load Generators是运行脚本的负载引擎，在默认情况下使用本地的负载生成器来运行脚本，但是模拟用户行为也需要消耗一定的系统资源，所以在一台电脑上无法模拟大量的虚拟用户，这个时候可以通过调用多个Load Generators来完成大规模的性能负载。Load Generator的核心是MMDRV.EXE进程，MMDRV.EXE负责运行脚本模拟用户行为，该程序支持进程或线程的方式，通过Runtime Settings即可进行设置。打开Scenario菜单下的Load Generators，如图4.29所示。图4.29 Load Gene

28、rators管理器Load Generators管理器列出了所管理的负载服务器列表，需要添加负载引擎只需要在这里单击Add按钮，然后在对话框中输入需要连接的负载引擎所在的电脑IP以及对应平台即可(确保对应平台上已经安装并启动了Load Generator服务，安装过程请参考第2.6.2节)，如图4.30所示。图4.30添加远程Load Generators添加该引擎后，可以单击Connect按钮连接一下，如果出现Ready则说明正确连接，该负载生成服务器可以使用，否则就需要检查一下是什么原因导致的连接错误。在Windows下，如果排除了防火墙的问题后，Load Generator无法连接一般是

29、由于Load Generator的权限配置错误导致的。具体的解决办法说明如下。在安装Load Generator的电脑上，打开LoadRunner中Tools菜单下的LoadRunner Agent Runtime Settings Configuration，如图4.31所示。图4.31AgentRuntimeSettings远程连接账户设置这里有两个选项，其中，在Allow virtual users to run on this machine without user login处输入登录信息，就可以让远程的Controller无须登录就直接连接到这个Load Generator，这里

30、需要输入本地电脑的账户，这样就可以解决无法远程访问负载引擎的错误。Linux负载生成器的连接。按照第2.6.2节的内容安装配置了Linux端的Load Generators后，在Controller中选择添服务器，输入Linux端的IP地址并设置操作系统为Linux后，还需要在Unix Environment中选中Dont use RSH，如图4.32所示。添加完成，单击Connect按钮，Linux平台下的负载生成器连接成功，如图4.33所示。图4.32添加Linux平台下的负载生成器图4.33添加远程Linux负载生成器连接成功当远程负载服务器被成功添加至负载服务管理器中后，就可以在Sce

31、nario Group中的Group脚本右侧选择使用哪一台负载服务器来运行对应的脚本了，如图4.34所示。图4.34设置脚本运行所在的负载生成器通过设置多个LoadGenerator可以有效地增加负载量，解决单台电脑无法模拟大量负载的问题。当场景开始运行时，Controller会先将脚本传输到各个负载生成器上，等到运行结束后，各个负载生成器的日志会被Controller回收。在大多数情况下，使用进程方式时一个Vuser会占用接近3MB的内存，而使用线程方式时一个Vuser大概只占用200KB的内存。为了保证负载生成的有效性，请在真正实施性能测试前先测试一下负载器是否存在硬件瓶颈(生成负载时的C

32、PU、内存、带宽占用情况)，确保负载生成时负载器自身不会成为瓶颈，其CPU和内存的使用率最好不超过80。4.1.3 用户管理在Scenario Groups工具条中，除了运行脚本按钮、查看脚本和Run-Time Setting功能外，Virtual Users管理器是经常使用的一个功能，该功能提供了一个对负载用户进行快捷有效监控的操作平台，如图4.35所示。单击Virtual Users按钮，弹出虚拟用户管理器，如图4.36所示。图4.35 Scenario Groups工具条图4.36虚拟用户管理器在场景运行前可以设置待运行虚拟用户的状态，如手动启动用户执行，也可为场景添加或停止用户。当场景

33、运行时，可以通过该功能对某个正在运行的用户进行监控。例如：选择某个正在运行的用户，右键菜单打开Show User功能，可以获得该用户的运行状态(效果同VuGen中的Browser)，也可以选择Show Vusers Log功能打开该用户运行的目志，还可以通过过滤规则来查找不同状态的虚拟用户。4.1.4 运行设置在场景运行前还需要对脚本的运行策略进行设置，确保整个场景中所有用户的运行方式正确。注意在Controller中Run-Time Setting独立存放在场景.lrs文件中，并不会影响该脚本在VuGen中运行的设置。在场景运行前应该对以下选项进行检查设置，以确保脚本正确执行。1.Think

34、 Time在VuGen中Think Time默认为忽略，但是在场景中，该选项会自动按照脚本录制的lr_hink_time()函数进行运行。Think Time可以模拟真实用户的操作等待，如果该时间设置得太短，那么得出的性能数据就会比较悲观(模拟的用户操作比真实用户快，服务器的负载压力会比正常情况大，从而结果较差)，反之结果会过于乐观，所以这个时间不能随意设置。由于录制脚本的时候对业务比较熟悉，所以会导致Think Time偏小，这里可以尝试取一个熟练用户的操作速度和一个新用户的操作速度的平均值来设置合理的Think Time值。2.场景中MMDRV.EXE负载的生成方式Load Generat

35、ors会调用mmdrv.exe来生成负载，而负载的生成分为进程方式和线程方式。使用进程模式模拟负载的资源开销会相对较大，每个虚拟用户会使用一个单独的mmdrv.exe来完成负载的实现，这样做用户之间会相互独立，不会互相影响。而如果使用线程方式，那么所有用户都是在一个mmdrv.exe上模拟的，用户行为使用线程方式，模拟消耗的资源较小。一般来说使用线程可以在固定的硬件平台上产生更多的负载模拟，但使用线程也会存在不稳定的情况，导致用户脚本执行错误。3.系统日志设置在场景中系统曰志会从Always send messages变为Send messages only when an error occ

36、urs，不出现错误就不记录日志，这样可以减少负载时记录日志的资源开销，从而提高模拟效率。当需要进行错误跟踪时，再将其打开。4.关闭自动化事务在脚本中都会对关键的操作添加事务从而获得响应时间，一般会默认设置自动化事务(对每个Action都默认设置一个事务)，导致每次都会多几个无关紧要的事务统计，为了避免多余的数据影响，建议关闭自动化事务选项。5.带宽模拟带宽会直接影响到事务的响应时间，而真实环境下每个用户的带宽也是有限的，这里需要为用户设置一个合理的带宽来得到真实用户访问的响应时间。通常情况下一个客户端在访问一个Web网站时的平均连接速度是在30-50KBs左右，这里可以选择512 Kbps(D

37、SL)，为场景中的每个用户分配512Kb的带宽。为了避免出现由于模拟用户过多，导致Load Generator上出现带宽瓶颈的情况，需要在设置前进行计算。如果设置每个用户有512Kb的带宽，那么在100Mb总带宽下，最多模拟200个用户。6.集合点策略如果脚本中含有集合点，则需要根据需求对集合点的策略进行设置。当场景需要多脚本并发负载时，只需设置同名集合点即可实现。4.1.5 IP虚拟很多时候服务器都对IP有限制策略，不允许同一个IP地址上有多个客户连接操作，这时就需要使用IP虚拟这个功能将虚拟用户脚本从一个IP运行变成不同IP运行。IP虚拟技术主要是得益于TCPIP的支持，在TCPIP组中，

38、一块物理设备可以绑定多个IP地址。打开网卡属性中的高级设置，找到IP设置标签，添加IP地址，如图4.37所示。添加IP地址后，可以通过ipconfig命令确认多个IP是否已经应用在了物理网卡上。当网卡绑定多个IP地址后，接着只需要在Controller中打开IPSpoofer支持功能即可，如图4.38所示。 图4.37在TCPIP高级设置中 图4.38 Enable IP Spoofer启动场景下的为网卡添加lP地址 IP虚拟支持该选项打开后，在Controller下会出现图标，说明该功能正在运行。如果需要生成大量的IP地址，那么可以通过Load Runner白带的IP Wizard工具实现(

39、该工具要求网卡处于非DHCP模式下)。打开LoadRunner中Tools菜单下的IP Wizard工具，如图4.39所示。IP Wizard可以快捷生成大量的IP地址并将其添加到网卡中，相对于手工来说方便了很多。选择创建一个新的设置后，单击下一步按钮。接着需要输入服务器的IP地址，如图4.40所示。图4.39 IP地址生成向导图4.40需要访问的服务器lP地址填写服务器IP地址后，单击下一步按钮。在如图4.41所示的界面中单击Add按钮输入所需要构建的网段类型和IP数目。这里构建一个ClassB类(C类的IP地址由于区域较小，最大只能容纳255台主机，不太适合用来做性能测试)的IP地址，然后

40、从172.14.0.1开始，生成400个IP地址，如图4.42所示。图4.41添加IP地址段图4.42设置400个B类lP地址Verify that new IP addresses are not already可以校验IP地址是否存在。确定后，该工具将对每个IP地址进行检测，如果已被使用，那么跳过，否则留下。用IP Wizard将IP地址写入网卡后，并没有立即生效，我们可以使用ipconfig命令来确认。如果显示的网卡中没有新添加的IP信息，那么可以通过重启网卡的方式来完成生效工作(禁用网卡，启动网卡)。那么如何检查每个脚本使用的IP地址呢?在打开IP Spoofer后，只需要确保场景日志

41、打开，并且将其设置为扩展日志，就可以在运行的日志中找到对应的IP信息，注意如果虚拟用户的数目大于IP的数目，那么用户之间的IP会出现重复的情况。在Controller 9.1中IP虚拟支持进程和线程模式，也可以在设置中找到相关选项。选中Controller中Tools菜单下的Expert mode模式，然后打开Options对话框，在General标签中就可以看到IP虚拟的设置标签，注意，当Scenario菜单下的Enable IP Spoofer选项启用时，才能在这里设置Multiple IP策略，如图4.43所示。图4.43设置IP虚拟分配策略当脚本在远程Load Generator上运行

42、时，只需要在对应的Load Generator上配置多IP即可，另外需要注意的是当使用IP虚拟的时候推荐先和网络管理员商量一下，避免出现一些网络架构方面的问题。4.1.6 场景运行原理在场景中可以设置其需要持续一段运行时间，而一个脚本运行一次的时间是有限的。在场景中当场景运行时间大于脚本运行时间时该如何处理呢?这里可以设置一个简单的脚本来尝试一下：Action()Ir_eval_string(“(interation)”);return0;在Parameter List中设置参数interation的取值为interation number，格式为：08d。切换这个脚本到手工场景使用一个用户运

43、行，设置脚本的Duration时间为2分钟，运行结束后通过日志即可了解场景运行的实质。Virtual User Script started MsgId：MMSG-15967Starting action vuser_init. Msgld：MMSG-15919Web Turbo Replay of LoadRunner 9.10.0 for Windows Vista; WebReplay85 build 5896 MsgId:MMSG-27143RunMode：HTML MsgId：MMSG-26000Run-Time Settings file: ”C:IUsersAdministrat

44、orAppDataLocalITemp1r5tmpdirex0.792 1rcfgzJt.793 cfgM51.797” MsgId：MMSG-27141Ending action vuser_init. MsgId：MMSG-15918Running Vuser.MsgId：MMSG-15964Starting iteration 1.MsgId：MMSG-i5968Starting action Action.MsgId：MMSG-15919Action.c(3)：Notify：Parameter Substitution：parameter”interation”=“00000001”M

45、sgId：MMSG-13992Ending action Action.MsgId：MMSG-15918Ending iteration 1.MsgId：MMS-15965Starting iteration 2.Msgld：MMSG-159681Starting action Action.MsgId：MMSG-15919Action.c(3)：Notify：Parameter Substitution：parameterinteration”=“00000002”MsgId：MMSG-13992Ending action Action.Msgld：MMSG-15918Ending iter

46、ation 2.MsgId：MMSG-15965/省略中间的内容Starting iteration 24893.MsgId： SG-15968Starting action Action.MsgId：MMSG-15919Action.c(3):Notify:ParameterSubstitution:pamameter”interation”n00024893”MsgId:MMSG-13992Ending action Action.MsgId：MMSG-15918Action was aborted.MsgId：MMSG-10694Ending Vuser.MsgId：MMSG-15966

47、1Starting action vuser_end.MsgId：SG-15919Ending action vuser_end.MsgId：MMSG-15918Vuser Terminated.MsgId：MMSG-15963在Run Logic中，任意一个脚本都是分为init、run、end三个部分。当脚本在场景运行时，虚拟用户被初始化后先会运行init然后进入run，当整个run结束后场景会检查是否到达该虚拟用户的结束时间，如果没有到达，那么继续自动迭代这个run过程，直到虚拟用户到达结束时间该脚本停止run过程，最后完成end内容，如图4.44所示。图4.44场景运行原理在场景运行结束时停止用户的模式有3种，打开Options对话框可以对其进行设置，如图4.45所示。图4.45场景结束停止虚拟用户策略设置在Con