《LoadRunner没有告诉你的》..doc

《LoadRunner没有告诉你的》 LoadRunner之—Block 如何在一个脚本中实现不同事务不同次数的循环呢？ 案例：假如你想在一个脚本中，实现登录执行1次，查询执行2次，插入执行3次，怎么办？录3个脚本？每个事务分别在脚本中复制N次？ 当然不用，LR早就想到了你的需求，下面让我们隆重推出Block。 位置：Run-time Settings--General--Run Logic 操作： 将你所要考察的事务设置在不同的Action内。 在Run Logic中的Run中删掉默认的Action。 在Run中插入Block。 在插入的Block中再插入我们要考察的Action。 设置Block的properties。这里有两种选择，Sequential和Random。如果选择Sequential，在下面的Iteration中直接填入数值，那么Block中的Action都会按输入的次数执行。如果选择Random，下面的properties还可以设置Block内各Action执行的百分比。 按照我们前面的案例，我们只需要设置3个Block，每个Block中分别插入一个Action，设置执行次数分别为1，2，3就可以了。 本人理解补充 如果脚本中各个action没有顺序或逻辑关系，Block中action顺序可以是任意的。如查询。但是像登录这样必须在前面执行的action，随意放置将导致脚本失败。 在Number of Iterations中设置的循环次数，作用于Run(x)下的所有Action，而不作用于Block下的action。即Block下的action可以通过设置Block的Properties来指定循环的次数。 《LoadRunner 没有告诉你的》之一——描述性统计与性能结果分析 LoadRunner中的90％响应时间是什么意思？这个值在进行性能分析时有什么作用？本文争取用最简洁的文字来解答这个问题，并引申出“描述性统计”方法在性能测试结果分析中的应用。 为什么要有90％用户响应时间？因为在评估一次测试的结果时，仅仅有平均事务响应时间是不够的。为什么这么说？你可以试着想想，是否平均事务响应时间满足了性能需求就表示系统的性能已经满足了绝大多数用户的要求？ 假如有两组测试结果，响应时间分别是 {1，3，5，10，16} 和 {5，6，7，8，9}，它们的平均值都是7，你认为哪次测试的结果更理想？ 假如有一次测试，总共有100个请求被响应，其中最小响应时间为0.02秒，最大响应时间为110秒，平均事务响应时间为4.7秒，你会不会想到最小和最大响应时间如此大的偏差是否会导致平均值本身并不可信？ 为了解答上面的疑问，我们先来看一张表： 在上面这个表中包含了几个不同的列，其含义如下： CmdID 测试时被请求的页面 NUM 响应成功的请求数量 MEAN 所有成功的请求的响应时间的平均值 STD DEV 标准差（这个值的作用将在下一篇文章中重点介绍） MIN 响应时间的最小值 50 th(60/70/80/90/95 th) 如果把响应时间从小到大顺序排序，那么50％的请求的响应时间在这个范围之内。后面的60/70/80/90/95 th 也是同样的含义 MAX 响应时间的最大值 我想看完了上面的这个表和各列的解释，不用多说大家也可以明白我的意思了。我把结论性的东西整理一下： 1. 90％用户响应时间在 LoadRunner中是可以设置的，你可以改为80％或95％； 2. 对于这个表，LoadRunner中是没有直接提供的，你可以把LR中的原始数据导出到Excel中，并使用Excel中的PERCENTILE 函数很简单的算出不同百分比用户请求的响应时间分布情况； 3. 从上面的表中来看，对于Home Page来说，平均事务响应时间(MEAN)只同70％用户响应时间相一致。也就是说假如我们确定Home Page的响应时间应该在5秒内，那么从平均事务响应时间来看是满足的，但是实际上有10-20％的用户请求的响应时间是大于这个值的；对于Page 1也是一样，假如我们确定对于Page 1 的请求应该在3秒内得到响应，虽然平均事务响应时间是满足要求的，但是实际上有20-30％的用户请求的响应时间是超过了我们的要求的； 4. 你可以在95 th之后继续添加96/ 97/ 98/ 99/ 99.9/ 99.99 th，并利用Excel的图表功能画一条曲线，来更加清晰表现出系统响应时间的分布情况。这时候你也许会发现，那个最大值的出现几率只不过是千分之一甚至万分之一，而且99％的用户请求的响应时间都是在性能需求所定义的