loadrunner混合场景测试

应用场景 假设有 3 个不同的测试场景，分别为并发登录、核心业务、可靠性测试，3 个场景有先后执行顺序。由于 白天测试机器另有用处，只能在晚上进行性能测试，这时我们的期望是能否把测试场景都设定好之后晚上 自动运行，第二天我们回来看测试结果呢？ 答案是肯定的，可以有两种方式实现。 第一种，相对简单 充分利用 LR Controller 里面 Group 的功能。 新建一个场景把 3 个脚本都添加进来，在 Edit Schedule 中选择“Schedule by Group”的方式，在 StartTime 中设置 3 个脚本的运行顺序为“Start when Group xxx finished”，并在“Scenario Start Time”中 设定场景在晚上的运行启动时间。设定完定时执行场景后，点击 StartScenario 按钮，会出现一个倒计时 窗口，这样在固定的某个时间上，测试场景中的 3 个脚本将乖乖的按照设定的先后顺序进行测试。注意， 如果没有点击 StartScenario 按钮激活测试，是不会真正进行测试的。（感谢 Athenst 朋友的提醒，_） 第二种，比较灵活 我们把应用场景稍微扩展一下，假设其中 1、3 场景只有一个测试脚本，而核心业务场景由数据录入、数 据查询、数据上报 3 个脚本组成，同样的，3 个场景仍需按顺序进行测试。这时如果采用第一种方式，由 于第 2 个场景有 3 个脚本，所以第三个脚本的启动时间就是一个问题了。由于 Controller 中每个脚本都对 应一个 Group，而且 GroupName 不能重复，这时第三个场景的 StartTime 中“Start when group finished” 则只能是选择第二个场景中的某个 Group，而并非是第二个场景的 3 个脚本都完成之后再进行，无法达到 我们的初衷。 这时，可以通过命令行的方式来进行。 首先创建并设置好 3 个测试场景，再创建一个一个批处理程序按先后顺序调用这 3 个场景进行测试，最后 通过 Windows 的定时任务设定批处理的执行时间。 批处理示例如下： cls SET M_ROOT=“D:Program FilesMIMercury LoadRunnerbin“ %M_ROOT%wlrun.exe -TestPath “D:Program FilesMIMercury LoadRunnerscenarioTestTestScen_1.lrs“ -Run %M_ROOT%wlrun.exe -TestPath “D:Program FilesMIMercury LoadRunnerscenarioTestTestScen_2.lrs“ -Run %M_ROOT%wlrun.exe -TestPath “D:Program FilesMIMercury LoadRunnerscenarioTestTestScen_3.lrs“ -Run 这种方式比较灵活，但需要注意在 Result Settings 中设置“Automatically create a results directory for each scenario execution”，以免后面的测试结果覆盖了前面的。 另外补充一下，如果想对某个脚本进行 50、100 、150.等用户数递增的测试，也可以用以上方法实现， 但需要注意的是将事务名称区分开以便进行分析。 有这样的一个案例：现网站有 1000 个同时在线用户，其中百分 20%的用户浏览网页，30%的 用户注册，%20 的用户登录，30%的用户查询，如何针对这种需求设计场景，（注不单设 场景，要求使用混合场景全程模拟真实用户行为）： 设计 方法一： 1.录制完脚后，并对其进行完善，比如有这样三个脚本, Reg_Action,Login_Action,Order_Action 2.假如 VU 设为 100 个，30%的用户注册,20%的用户在登录，余下的用户做订票操作。 3.在场景中的 run-time-setting 中我们可以这样设置：在 Run-Logic 中在 General Run Logic 中设置 run 属性，run 有两种属性,一种是 Sequential(顺序模式)，另一种是 Random(随机模式)，通过 Random 这种方式，我们可以模拟 30%的用户在注册，20%的 用户在登录。（注，此设置是在控件器中的 run-time-setting 中设置） 4.其中的 bloce 块可以实现更为复杂的脚本运行策略 这种方法确少灵活性，下面描述如何用编程实现： 方法二：通过程序解决 1.用程序 来判断随机出来的概率和和其给定的值作判断，如果符合这个条件，则调用此函 次（脚本一次） 2.比如说 100 个用户,20%就是 20 个用户, 那么 【0-20 】这个范围内， 在 action 中模拟 20%的用户浏览网页，可以这么操作： Action int rowNum; rowNum=rand()%100+1; if (rowNum =20%) /调用一个脚本 return 0; 例如：性能测试场景设计-混合业务场景下的脚本比例控制 在某个业务场景中，包含数据创建和数据查询两项业务；现需考察数据创建和数据查询两 项业务在并发比例为 2:1、总并发量为 100 用户情况下的混合响应时间。 在 Vugen 端实现 对混合比例的设置，可直接在脚本中进行，即通过随机函数 rand 实现，脚本设计如下所示。 int num; Action() num = rand()%3; lr_start_transaction(“综合业务-数据创建与数据查询“); if(num2) Data_Create(); /数据创建 else Data_Search(); /数据查询 lr_end_transaction(“综合业务-数据创建与数据查询“, LR_AUTO); return 0; 该种方式的优缺点对比： 优点： 脚本本身实现了比例控制的功能，Controller 端的设置较为简单，即在 Controller 中只需将该混合业务作为单一业务对待，设置也跟单一业务场景的设置方法完全相 同； 测试得到响应时间即为混合业务的响应时间。 缺点： 在已有数据创建和数据查询脚本的情况下，针对混合业务场景需要单独创建一个混 合业务脚本，且混合比例改变时需要重新修改脚本； 当需要考察混合业务场景中不同业务类型各自的响应时间时，通过该种方式无法实 现。 2、在 Controller 端实现 在业务类型较多，混合业务场景较为复杂的情况下，采用修改脚本的方式会比较麻烦。例 如，若共有 5 种业务类型，现需要对其任意两种业务的混合场景进行压力测试，如果仍采 用第一种方式，那么我们就必须得针对两两业务的混合情况，创建 10 个混合业务脚本。 当业务类型更多，或者混合场景更为复杂（如需考虑任意三种、任意四种业务等的混合情 况）时，脚本的创建量会大大增加，且均为乏味的重复性工作。 针对这种情况，直接在 Controller 端进行设置会简单得多，只需要加载各个业务脚本，并 设置不同脚本的并发数即可。对于本文中的案例，在 Controller 中的设置方法如下所示。 该种方式的优缺点对比： 优