loadrunner other
客户端环境配置:
a、IE浏览器配置推荐(IE9)
浏览器是用来录脚本,我本人习惯用IE8,IE9和火狐也可以,IE9选择32位的,就是win7系统有两个IE9,选择32的,x86
b、退出360等各种管家软件
360软件管家会影响脚本的录制
c、保证网络正常
d、保证LR正常
单独提交如何编写脚本,把详细过程以及注意事项都写出来:
a、分析协议
协议可以理解为一个约定,就是对数据包发送格式的统一约定,如果你按约定来就能识别你,也能发成功,如果你不按约定来就不认你,当前最主流的协议是WEB(HTTP/HTML),只有选对了协议才能正常的录制脚本,协议选择不对录制的脚本可能为空
b、录制脚本
使用LoadRunner性能测试工具录制脚本
c、优化脚本(去掉无用的东西)
有时录制的脚本里有一些无用的东西,要把这些东西删掉
d、强化脚本
可以在脚本里插入事务,检查点,参数化,加入一些判断条件等,让脚本更健壮
e、调试脚本(多次迭代通过才行)
脚本强化完之后还要对脚本进行调试,一定要多次迭代运行脚本
场景设计策略:
a、快增长
秒杀使用快增长策略,瞬间用户数就上来了
b、慢增长
适用于所有场景
c、用户数执行完停止场景
这种场景用的比较少
一般情况下场景设计的步骤如下:
---添加脚本
---添加压力机
---设置run time setting
---设置Schedule
性能测试场景类型:
单场景(某个页面、某个接口的单点性能):用的比较多,登录,达到开发的要求,还要压出极限值,避免上线以后背锅
混合场景:多个业务混合在一起,如发帖,回帖等,排除数据库死锁或线程死锁
稳定性场景:N*12,长时间跑看是否有内存泄漏,24小时只允许有一次full gc
Controller里Global Schedule设置,按照下图的配置即可:
选择组模式可以跑多个脚本的时候设置时间间隔,第一个脚本选择Start immediately after the scenario begins,第二个脚本是在上一个场景开始后多长时间开始,可以设置时间
百分比模式集合点置灰,而且百分比模式不能添加虚拟用户,虚拟用户组模式可以看到集合点,可以添加vuser
递增模式:能找到最佳用户数和最大并发数
多一次跳转,多一次请求损耗,多入口也会影响性能
压力机:增加压力的机器,可以指定多个压力机对系统进行加压
监控用户最高的那个时间段,有这个数据是最好的,如果没人提供这个,建议压15-20分钟
添加压力机的一般步骤:
a、保证要联合的机器上装了LR agent,并启用了(状态栏那里会有一个小卫星)
b、本地系统的RPC服务开启(改为自动)
c、请从你的Controller的机子上登录下要联合的机子
d、关闭防火墙+杀毒+360等,拥有权限,并在同一个网段内
A地点压B地点(机房)的机器,要求很大的并发,选择压力机的原则是在机房选择压力机,能避免带宽瓶颈
Loadrunner工作原理:
LoadRunner启动以后,在任务栏会有一个Agent进程,通过Agent进程,监视各种协议的Client与Server端的通讯,使用自带的一套C语言函数将录制下来的用户操作转化为脚本,LoadRunner调用这些脚本向服务器发出请求,并接收服务器的响应,至于服务器内部如何处理,它并不关心
EXTRARES中的图片是放在静态服务器上的,对测试的影响不是很大,静态文件浪费带宽,真正有瓶颈的是动态的,如果你是想做系统的性能预估,那么可以保留EXTRARES中的内容,但是如果这里的内容是与系统毫无关系的建议删除掉
html录制的脚本比较简洁直观,每个录制出来的请求只包含web_submit_data,web_url这两个函数,能把隐藏域中的数据抓出来,非常容易理解和维护, 在回放时,html脚本积极地解析返回的信息来获得要下载的资源,缺点是脚本回放需要更多的cpu和内存,web_url的请求方式是GET请求方式,拿页面数据的,web_submit_data函数是提交数据的,是POST请求方式,web_submit_data()函数能把隐藏域中的数据抓出来,而web_submit_form()不能
接口类型:
HTTP接口:通过GET或POST来获取数据,在数据处理上效率比较高,get请求的body里为空,post请求参数值可以放在ITEMDATA里,也可以放在Body里
webservice接口:通过soap协议来获取数据,比起HTTP来说能处理更加复杂的数据类型,对于移动、电信使用webservice接口
缓存产生的原因:通过缓存读取数据要比从磁盘读取快,工人如cpu,车间如内存,仓库如磁盘,车间越大越好
API(Application Programming Interface),就是接口
sprintf函数的作用是把格式化的数据写入某个字符串中然后打印出来
web_add_header("name","value")请求头函数,把值塞到属性里
lr_save_string("192.168.0.99","ip")函数的用法是把第一个值保存到第二个里
lr_output_message(lr_eval_string("{Param_qqCheckOnlineResult}"))
lr_eval_string函数主要是返回脚本的一个参数当前的值,以lr_eval_string("{title_count}")为例,取出title_count的值,lr_eval_string函数一般和文本检查点配合使用,查询文本检查点查询到的文本次数,通过atoi(lr_eval_string("{title_count}"))这样的方式和0进行比较,lr_eval_string函数放在脚本,Action()部分里最后一个web_url()函数的后面,return 0的前面
if(atoi(lr_eval_string("{title_count}"))!=0)
{
lr_output_message("发帖成功");//输出日志,输出来是黑色的
}
else
{
lr_error_message("发帖失败");//输出日志,输出来是红色的
}
web_image_check("imcheck","Src=图片的相对路径",LAST)是图像检查点函数,要放在请求的后面,第一个参数可以随便,叫什么名字都可以,第二个参数是图片的相对地址, 如何查找图片的相对地址呢,首先找到要设置成图片检查点的图片,点击鼠标右键,点击属性按钮,就可以看到图片的地址,去掉登录页面的URL剩下的部分就是图片的相对地址,设置成图片检查点后,还要设置一下,在LR脚本页面点击Vuser按钮,找到Run_Time_Settings,在Preferences标签里找到Checks选项,勾选Enable Image and text check,就是设置图片和文本检查点的前置条件就是勾选上Enable Image and text check,无论是文本检查点还是图片检查点检查的都是源码,HTML的源文件,源码里Src对应的相对路径,如果Src那里填上绝对路径就会查不到,而且还会报错
为什么jmeter比loadrunner测的并发会大一些?
jmeter比loadrunner测的响应时间会短一些,loadrunner比jmeter测的准确一些
loadrunner和jmeter都是完整的接收返回结果,才能发送下一次请求,ab,webbench的响应时间是建立第一次握手,只包括发送时间,只判断服务器状态2X,响应时间短,自然并发就会多一些,不接收服务器返回结果,只握手不挥手,因为测试是面向用户的,要接收返回结果,我是用loadrunner测试的,以我的为准
ab,webbench和cpu的关系,测试并发不一样,cpu越多,发出的请求越多,并发越多
ab、webbench比 loadrunner 、jmeter并发多很多,jmeter比loadrunner测的响应时间会短一些,loadrunner比jmeter测的准确一些,并发过万的话用ab,webbench,他们没有license的限制,并发不到1万的话用哪个工具都行,jmeter性能测试的tps比loadrunner的大10倍,因为jmeter默认勾选了Use KeepAlive,链接不会断开,还使用这个链接通道
在多大并发下的响应时间,在多长响应时间内的并发数,按照开发的角度定义事务,响应时间不包括前端页面的加载
从负载机发起压力,到最终负载机接收到整个数据包结束,end transaction结束,这个过程是loadrunner的响应时间
为什么不用lr自带的linux监控?
第一要在被测的Linux服务器上安装rpc.rstatd rpcinfo -p,并且启动起来才能监控
第二当被监控的机器压力上来之后,Linux会将无关紧要的进程kill掉来释放一些资源,这就是为什么用lr监控到中间就没有了,抓到的数据断掉了
客户端是负载机(Windows或Linux),Web服务器和数据库服务器是操作系统程序,Web服务器下面是Web服务器中间件,中间件下面是应用程序本身,性能测试的数据流转过程就是从发送请求开始到接收到请求结束,就在这个区域里,各个环节都要监控起来,剩下的过程就是一步一步排查