loadrunner 场景设计-设计与实践

场景设计-设计与实践

by:授客 QQ：1033553122

以lr 11.0 自带Web Tours为例，进行以下测试

说明：以下测试仅供演示，学习设计思路

A、确定系统组件

简单B/S架构：Client Browser ---> WebServer

 

B、系统配置

服务器配置

内存：8.00G

CPU：3.20 GHZ

操作系统:Win7 64未

 

负载生成器及Controller所在主机配置：

内存：8.00G

CPU：3.20 GHZ

操作系统:Win7 64未

浏览器：IE8

 

C、分析使用场景

场景一：登录

场景二：订票

D、任务分布

略

说明：任务分布主要是基于时间的考虑，当然也可能是地区之类的，如果是基于时间即高峰期，则，可以通过场景中的持续时间设置，选择运行一段时间来模拟

E、目标

1.测试响应时间

2.测试系统容量

F、量化测试目标

1.保证响应时间正常(8秒)的情况下，并发登录的最大用户数

2.不保证响应时间正常，保证系统能继续处理的并发登录最大用户数

3.保证响应时间正常的情况下(各操作页面的平均响应时间8秒)，并发订票的最大用户数

4.保证响应时间正常(8秒)的情况下，一部分人在查看home首页，一部分人在浏览航班，比例为2：7，最大并发数

附：关于响应时间的2-5-8原则说明

2-5-8原则，简单说：当用户能够在2秒以内得到响应时，会感觉系统的响应很快；当用户在2-5秒之间得到响应时，会赶紧系统的响应速度还可以；当用户在5-8秒以内得到响应时，会赶紧系统的速度很慢，但是还可以接受；而当用户在超过8秒后仍然无法得到响应时，会感觉系统糟糕透了，或者认为系统已经失去响应。

G、Action和事务设计

设计思想：代码结构化，测试对象独立化、最小化，以下抛砖引玉~~

action设计

1、 
关于登录

登录的前提是先打开网站首页，所以，对于我这类菜鸟来说，会有个问题:打开首页这个过程要放到哪里呢？

解答：

1) 
和登录分开，为其单独创建一个action

好处：灵活--要运行它的时候，通过运行时设置，把action添加进来即可，反之，去除即可。同时还以为它设置集合点，单独测试它的并发访问

不足：如果要进行多次迭代，比如测试持续登录，那么如果添加了访问站点首页的action，那么该action也会进行多次迭代，如果去掉访问首页的action，则没意义，因为登录前肯定要访问首页

2) 
和登录分开，放到vuser_init
action

好处：解决了第一点中的“不足”

不足：不灵活，不管脚本迭代运行多少次，仅运行一次，而且不能设置集合点，试想，假如我要测试对首页的持续访问，或者是对首页的并发访问，那岂不是还得把代码拷出来，再折腾？

3) 
和登录一起，放到自己创建的Login
action

好处：似乎可以减少函数切换带来的消耗？

不足：不灵活，同第2点一样，假如要单独对它进行持续访问测试，那也要单独把代码拷贝出来，再折腾

所以，综合，得根据具体情况在方案1和方案2之间选择

2、 
关于订票

订票，要完成订票这个过程，必须要执行一系列的操作：

步骤1.点击Flights，打开搜索航班页面（open_search_fIights_page）

步骤2.填写搜索条件，点击continue，显示搜索结果（show_search_results）

步骤3.选择航班，点击continue，打开支付页面（open_payment_page）

步骤4.输入金额信息，点击cotinue，显示支付结果页面（pay_for_reservation）

对于我这类菜鸟来说，会有个问题：这些步骤要放在同一个action中，还是为每个步骤单独设置一个action?

很遗憾，关于这个问题似乎没有统一的标准，对于这类前后联系比较紧密，为执行一次完整业务必须执行的一组操作，个人比较赞成把它们都放在同一个action里面。

以下为最终的action设计

3、 
事务设计

1) 
把访问首页，登录，订票分别成一个事务

2) 
把订票中的每个操作步骤分别做成一个子事务

备注：事务可以添加在录制时，单击工具条上的添加按钮进行添加，也可以在录制完成后添加，问题：录制完后都是代码，要是不知道哪些代码对应哪个步骤的咋办？？

方法1.tree视图，可以查看单个操作步骤(url)对应的缩略图

方法2.选择Tasks视图

->Enhancements ->Transactions,可以显示不同步骤的缩略图

可将光标定位在缩略图上，点击插入前后插入事务，如下图，还可拖动“缩放”事务包含步骤

方法3.针对某个action中的单一步骤，也可以在录制时，操作之前添加注释

=================================华丽分割线=================================

1.脚本录制->优化

~略

 

2.实施负载

1）选择手工场景下进行的测试

测试1.

保证响应时间正常的情况下，并发登录的最大用户数

不保证响应时间正常，保证系统能继续处理的并发登录最大用户数

运行时设置-运行逻辑设置

其它设置~略

方案设置

脚本中的设置集合点

运行脚本

当设置的并发用户数为140时，并发登录平均事务响应时间为3.034秒，远远小8秒

但是开始出现事务错误，如下

也就是说，这里仅得到了保证平均响应时间正常情况下能容纳的最大用户数（估计是被测试主机和服务器在同一个局域网中，网络急速，所以无法不保证响应时间正常情况下的最大用户数，这里仅为演示如何进行场景测试，不要纠结这些

 

测试2.

保证响应时间正常的情况下，并发订票的最大用户数

运行时设置-运行逻辑设置

其它设置~略

集合点设置，如下，同时注释掉登录代码中的添加的集合点、或者禁用

运行脚本

当设置的并发用户数为85时，平均“订票”事务平均响应时间为8.007s,其中子事务，打开搜索页面为4.994秒

这里做了个对比实验，把集合点设置在第二个子事务即show_search_results之前，其它设置不变，运行脚本，结果如下

结论：根据实际情况，或者性能调优，合理的设置集合点，集合点位置不一样，看到的数据就不一样，因为代码是顺序运行的，vuser仅在集合点那边达到最大并发值，好比赛跑，起点(集合点)都一样，起点过后就有跑得快，跑得慢的，并不是一直都向开始那样，所有用户每时每刻都在同一条条线上。

测试3.

保证响应时间正常的情况下，部分人在浏览航班，部分在查看home首页

这里做这个测试主要是演示如何模拟这种并发的业务的测试

做法：

1.场景中添加两份相同的脚本(复制已经录制好的脚本来实现相同的两份)，为其设置不同的用户数，好比下图

2.为每个脚本中要实行并发操作的事务前添加名字相同的集合点，并设置所有用户到达集合点才释放用户

脚本2中

脚本1中

3.为每个脚本进行运行时设置

第一个脚本的运行时设置

第二个脚本的运行时设置

注意：如图，每次在场景中通过下拉按钮重新添加脚本都会导致脚本的运行时设置失效

运行脚本

如图，当用户数为81时，平均事务响应时间如下，于可以接受范围

但是当用户数达到90的时候，服务器直接奔溃了

是否真的可以这样跨脚本并发运行vuser?

结果分析-Running Vusers->右键->选则Down Drill,如图，选择Group Name名分组

点击确定出现如下图，

如上图，两个脚本都同一个点开始运行

2）选择目标场景下进行的测试

略~感觉和手工场景差不多