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，车间如内存，仓库如磁盘，车间越大越好

 

sprintf函数的做用是把格式化的数据写入某个字符串中而后打印出来

lr_save_string("192.168.0.99","ip")函数的用法是把第一个值保存到第二个里

API (Application Programming Interface)，就是接口

web_add_header("name","value")请求头函数，把值塞到属性里

 

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那里填上绝对路径就会查不到，并且还会报错

 

loadrunner事务响应时间包括数据发送和数据接收的时间，包括请求接收完毕，事务完成，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，连接不会断开，还使用这个连接通道

 

jmeter自己内存溢出、垃圾回收或服务器挂了，tps没有变化，请求没有发出去，响应也没有返回来

 

在多大并发下的响应时间，在多长响应时间内的并发数，按照开发的角度定义事务，响应时间不包括前端页面的加载 

从负载机发起压力，到最终负载机接收到整个数据包结束，end transaction结束，这个过程是loadrunner的响应时间

 

开发说为何我看到的响应时间比你看到的响应时间小不少？

开发看时间在日志里看，看接口，打点end-start

一、测试工具的差别性  二、测试脚本的差别性(事务定义不同致使测试结果不同、思考时间的位置不同)  三、测试版本  四、测试环境(硬件，软件，数据)，硬件是整个架构的全部硬件，软件是指数据库的配置，redis的配置，nginx的配置，数据量大小测试结果也不同  五、人为缘由(压测时别人也在操做服务器，对服务器压测)