`
thinke365
  • 浏览: 51852 次
  • 性别: Icon_minigender_1
  • 来自: 杭州
社区版块
存档分类
最新评论
文章列表
ppmm1:图片较大,每秒点击数上不去。。。 测试时,从浏览器,浏览这张图片,图片显示速度很慢,有时显示为缩略图。 ppmm2:图片比较小,大约为30K。每秒的Transaction居然有7000多。。。难以置信。。 设置了吓人的测试目标 超出许可证,用户数目了 这下晕了,许可证用户怎么样才能突破1000呢???????? 不得不承认,这是两个优质mm, 可惜拿来做测试了。。。
感觉和普通的测试没有什么区别,只是负载生成器分布在网络的各个地方而已。。。。 两个负载生成器都可以连上 Test 1: 测试时候,远程机子,网络带宽几乎全部用上了 网络带宽居然用了99% 测试目标居然还是无法达到。。。。 Test 2: 才50个用户就达到648次点击每秒了 达到760次点击了 还有上升前景 点击数达到1000了!!!!! 此次测试分析: Test1和Test2相比有很大不同。 Test1不到300次点击的时候就上不去了, 而Test2轻易到了700。。。 Test1不能点击到500的瓶颈在于网络带宽,因为100M的网络带宽已经占用到了99%,并一直保 ...
这些函数有一个特点,那就是以lr开头,表示它不属于任何协议,只要是采用C脚本就可以使用这些通用函数。 它们是建立在C语言基础之上的脚本语言。。。 分门别类,看起来挺多的,不过要把它们用起来,却是要花费不少时间的吧??? 呵呵,熟悉了这些函数,就算步入LoadRunner高级水平的门槛了吧,呵呵
LoadRunner脚本支持加载dll,由于dll是编译级别的,具有更高的执行效率。 dll被加载之后,就可以直接使用dll里面定义的函数了。。。 通常可以通过lr_load_dll("test.dll")进行dll的加载。。。 还有一种方法是全局加载。。。 针对某一类脚本进行配置。 在这些脚本中不用再写lr_load_dll,而可以直接使用里面定义的函数。 全局dll加载设置
Loadruner的强大,很大程度上是因为它的脚本强大,而它的脚本强大,很大程度上是因为集成了C语言,你可以在脚本中使用C语言,极大地提高了 测试的灵活性。。。 很多时候,还能处理一些 录制所无法解决的问题。。。。。 提高了效率。。。。 添加其他C代码文件
存在如下场景: 当用户登录成功时,返回登录页面 登录失败时,并没有返回HTTP错误信息,而是跳出一个窗口,提示用户输入密码。。。 对这种场景,Loadrunner无法判定跳出提示窗口的情况,是登录不成功的情况。 必须通过页面关键字匹配来进行判定 定义文本是否可以找到。。。即页面正确或错误的界限
局域网内有两台机子,一台作为服务器,上面架设了wiki,另一台上运行LoadRunner,对wiki进行性能测试。。。 测试目标:看这个wiki的性能能否达到每秒500次点击。 测试方案:Vuser数目范围从50到1000,持续加压,如果不能达到预期 ...
这是一个5小时30分的面向目标测试,和之前测试不同,它需要进行长时间测试,呵呵。 长时间测可选择各种视图,这里面的峰值是怎么回事?
与之前案例分析不同,这是一次对网站有了一点了解后,考虑了网络带宽和网站性能后,进行的面向目标的性能测试,总体的结果还可以,基本达到预期目的。 我设置的目标是达到每秒28次点击,最终的结果显示基本已经达到要求了。 每秒的点击数具体为27.694。。。为什么不是精确的28呢? HTTP Responses Summary HTTP Responses Total       Per second HTTP_200       53,228      27.694 Duration: 32 minutes and 1 second. // 总运行时间 Statistics Summary   ...
大批量的点击测试 4个页面同时刷新 测试报错,这个网站果然是用了缓存技术的
呵呵,就是对一些图表进行分析啦:) 分析案例1 可以看到,吞吐量的最高点,是在用户数达到最大数之后的一段时间达到的。 就如夏天,温度最高的时候不是12点,而是下午2点一样,吞吐量的最高点是在稍后的地方出现的。 点击数和吞吐量完全吻合? 吞吐量和错误曲线基本也是一样的,怎么回事?
呵呵,别被名字骗了,其实一点也不高级,只是对现在的我而言,还是有些高级的,所以先这么记录下来吧:) 很多时候,并不是那么容易就能发现系统的性能瓶颈在哪里。 需要把多个性能指标综合起来考虑,如下操作,就可以把多个指标关联到同一张图中 现在已经把数据可视化在这里了。。。 现在的关键是对这些图进行判读了,这不在只是一个软件的使用问题了,需要对软件的运行机制有较深入的了解才行。。。 效果图如下所示: 可以将数据加回到统计结果中,还有不少图可以加呢。。。。 怎么可以Dril Down成下面这样?
[img][/img]显示网页每个组件的小酌时间,及大小 右键可以选择显示一幅图,或者多幅图 通过的测试?这个是怎么计算的? 加Group原来加的是这些啊。。。 连接的不是一个大概的展示用户,而是精确的Vuser,显示它的窗口,当 ...
没能达到500次/秒的点击速度,控制器要求自动停止测试。 (50-500的测试区间,都不能满足要求。。。) 很可能是服务器的问题,或者是网络的问题吧? 它检验的是是否能够达到目标,而不是分析统计数据。 当然也有统计数据,但它最直接的目的是验证一个系统是否具备预期的性能:)
首先设置Merge: Vuser数目和响应时间叠加显示。。。。 用户数目确定时,为什么中间还有挺大的波动? 关联统计,这个貌似挺有意思的:) 如何解读下面的关联数据统计图? 平铺统计,看数据走势? 一些操作中需要注意的细节: 选Group之后,整个要重新设定,不然Vuser又变成默认的100了。。。 设定显示更详细的信息: 下图显示了更细节的信息,可以看到秒的刻录非常小:
Global site tag (gtag.js) - Google Analytics