LoadRunner手写脚本、检查点、集合点、事务、思考时间

手写脚本

什么时候要手写？

　　可以有条件手写脚本的场景有两类：

• 有接口说明文档
• 没有借口说明文档，要去录制，录制不了，抓包手写

所需函数

　　我们这里讲的例子是基于 http 协议的，也是常见的两种请求类型：get+post，主要有以下 3 个函数

• web_url
• web_custom_request
• web_submit_data

 　　我们用开源的接口去试试这几个函数：https://www.apiopen.top/api.html

用法

　　那么，这三个函数的用法是怎样的的？什么请求最好用什么函数呢？

1、web_url

　　web_url 最好用于 get 请求

2、web_custom_request

　　可用于 GET和POST，且 json 形式的请求只能写在这函数内

附：Encording Type

1. text/html——文本方式的网页文件，默认是此方式。
2. text/plain——窗体数据以纯文本形式进行编码，其中不含任何控件或格式字符。空格转换为 “+” 加号，但不对特殊字符编码
3. application/x-www-form-urlencoded——默认地，表单数据会编码为 “application/x-www-form-urlencoded”。就是说，在发送到服务器之前，所有字符都会进行编码，空格转换为 “+” 加号，特殊符号转换为 ASCII HEX 值。 窗体数据被编码为：名称/值对，这是标准的编码格式。
4. multipart/form-data——窗体数据被编码为一条消息，页上的每个控件对应消息中的一个部分，上传附件用到。在使用包含文件上传控件的表单时，必须使用该值。
5. application/json——数据以json形式进行编码。
6. application/xml——数据以xml形式进行编码，application/xml会根据xml头指定的编码格式来编码。
7. text/xml——文本方式的xml文件，text/xml忽略xml头所指定编码格式而默认采用US-ASCII编码。

 3、web_submit_data

　　可用于 GET和POST，POST 请求的 key - value 只能写进 body 里面

手写的方式

• 浏览器 f12 大法
• fiddler 抓包

fiddler 抓包设置一下过滤：

写一条正则，把 js、css等过滤掉

REGEX:.(js|css|js|png|gif|ico|gif?.*|css?.*|js?.*|png?.*)$

检查点

概念

　　检查点的实质是从请求的response里判断有没有返回某个字符串，从而判断请求有没有成功。压测要保证请求的成功率，检查点会影响请求成功率，通常与金钱相关的要求成功率为100%，其他的为99%、99.9%、99.99%，视具体项目而定。

什么情况加检查点

问题1：脚本中一定要加检查点吗？

　　检查点影响性能，不必要的检查点不加。

问题2：如何确定是否要加检查点？

● 数据库的 add、update、delete 操作不用检查点（跑完数据库查）；

● 数据库的查询操作一定要有检查点；

问题3：检查点的位置要放在哪？

　　当然是要检查的请求的前面，函数是哪一个呢：web_reg_find

用法：

Search for specific Text 中填入要查找的内容

Search in ：可以选择要查找的内容：ALL表全部，Body 为响应的消息体，Header就是响应头了

Save Count ：表示匹配出来的字段出现的次数

Fail if ：表示没找到或者找到了就报错

补充：还有个函数是 web_find

1. 这两个函数函数类型不同，WEB_FIND是普通函数，WEB_REG_FIND是注册函数
2. WEB_FIND使用时必须开启内容检查选项，而WEB_REG_FIND则不没有此限制
3. WEB_FIND只能只用在基于HTML模式录制的脚本中，而WEB_REG_FIND没有此限制
4. WEB_FIND是在返回的页面中进行内容查找，WEB_REG_FIND是在缓存中进行查找
5. WEB_FIND在执行效率上不如WEB_REG_FIND

说白了，用 web_reg_find 的优先级要远远高于 web_find ,所以 web_find 已经属于向后兼容的功能，不在推荐使用了。

 

事物

概念

loadrunner里响应时间指的是事物的响应时间、TPS指的是每秒通过的事物数，因此事物是loadrunner跑脚本的基础。事物是用来计时用的，把一个或多个请求圈起来放在一起，统计这一个或多个请求的时间。

定义事物时保证事物的准确性（干净）

● 一个事物里就放一个被测请求，这样事物响应时间就是请求响应时间；

● 除了被测试请求外，事物中不放任何其他东西，检查点、集合点全放在事物外面；

● 录制时用纯的URL，这样一个URL就是一个请求；

● 修改录制脚本中Mode=“HTTP”；

单场景压测与混合场景压测

● 单场景测试：先测单个接口是否满足要求，不用考虑其他依赖

● 多场景测试：对多个接口共同进行压测

问题1：对于用户来说，用户要注册必须得先进入首页，要压测注册请求是不是要模拟用户的实际操作来压接口？

要压注册不用脚本中不用加首页，单场景压测脚本的干净性会影响响应时间和TPS，如同样是压注册，小A的脚本里有首页和注册两个请求，小B的脚本里只有注册。同样运行5分钟小A的注册TPS肯定会小于小B的注册TPS。

问题2：单个场景压测，用户操作注册动作，除了注册单个API，还有js、css等请求也会对服务器有压力，怎么处理？

Js、图片、css样式都不用管，一方面有专门的前端性能测试会去测试，另一方面现在都是采用缓存技术，访问一次这些图片等静态资源资源全部缓存下来了，后面发的都是纯的接口请求。

添加事物

LoadRunner 一定要添加事务，压测过程是以事务为单位来计算的，除非设置每个请求作为事务，否则 pass 的事务为 0

● 可录制时加事物也可录制完成后再添加事物，录制时添加事物，容易有冗余，不干净；

● 录制完后加事物，可ctrl+T,也可点击下图图标

● 录制时加事物，点击如下图标

集合点

概念

　　当通过controller虚拟多个用户执行该脚本时，用户的启动或运行步骤不一定都是同步的。集合点是在脚本的某处设置一个标记，当有虚拟用户运行到这个标记处时，停下等待，直到所有的用户都达到这个标记处时，再一同进行下面的步骤。这样能够用最大的用户并发去做下面的操作，就像集合再前进一样。集合点是为加大瞬时并发的概率，通常抢购、秒杀会用到。

插入集合点

 思考时间

概念

控制单位时间段内向服务器发起请求的数量，以达到控制服务器压力的目的，从而影响测试的响应时间以及tps。

Run-time setting中开启think time

思考时间如何影响响应时间

例1：已知注册TPS=1,RT=1s，分别以1个vu和两个vu跑，RT分别为多少？

1个并发时，RT=1

2个并发：

vu1_1 RT=1s----vu2_1 RT=2s（1s等待+1s处理）

vu1_2 RT=2s（1s等待+1s处理）----vu2_2 RT=2s（1s等待+1s处理）

vu1_3 RT=2s（1s等待+1s处理）----vu2_3 RT=2s（1s等待+1s处理）

......

可以看出当时间足够长时，2个并发RT=2

例2：已知注册TPS=1,RT=1s，脚本中注册前加思考时间1s,分别以1个vu和两个vu跑，RT分别为多少？

1个并发时，RT=1

2个并发：

vu1_1 RT=1s----vu2_1 RT=1（思考时间1s，刚好把等待时间耗完）

vu1_2 RT=1s（思考时间1s）----vu2_2 RT=1s（思考时间1s）

vu1_3 RT=1s（思考时间1s）----vu2_3 RT=1s（思考时间1s）

......

可以看出当时间足够长时，2个并发RT=1s

思考时间如何影响TPS

假如TPS很大，单位时间内发的请求越多，TPS就越大。那么加思考时间会让单位时间内发送的请求数变少，从而使TPS减少。

例：服务器tps=100,每次处理时间为0.1s

1个vu,1s能发10个请求，则tps=10

1个vu,思考时间1s，处理1s,则tps=1

TPS 简单说明

* 1s是按过去的上一秒算的，过去1s内处理的事物数，

* tps忽略思考时间，只算处理时间

添加思考时间