手写脚本
什么时候要手写？
可以有条件手写脚本的场景有两类：
- 有接口说明文档
- 没有借口说明文档，要去录制，录制不了，抓包手写
所需函数
我们这里讲的例子是基于 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
- text/html——文本方式的网页文件，默认是此方式。
- text/plain——窗体数据以纯文本形式进行编码，其中不含任何控件或格式字符。空格转换为 “+” 加号，但不对特殊字符编码
- application/x-www-form-urlencoded——默认地，表单数据会编码为 “application/x-www-form-urlencoded”。就是说，在发送到服务器之前，所有字符都会进行编码，空格转换为 “+” 加号，特殊符号转换为 ASCII HEX 值。 窗体数据被编码为：名称/值对，这是标准的编码格式。
- multipart/form-data——窗体数据被编码为一条消息，页上的每个控件对应消息中的一个部分，上传附件用到。在使用包含文件上传控件的表单时，必须使用该值。
- application/json——数据以json形式进行编码。
- application/xml——数据以xml形式进行编码，application/xml会根据xml头指定的编码格式来编码。
- 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
- 这两个函数函数类型不同，WEB_FIND是普通函数，WEB_REG_FIND是注册函数
- WEB_FIND使用时必须开启内容检查选项，而WEB_REG_FIND则不没有此限制
- WEB_FIND只能只用在基于HTML模式录制的脚本中，而WEB_REG_FIND没有此限制
- WEB_FIND是在返回的页面中进行内容查找，WEB_REG_FIND是在缓存中进行查找
- WEB_FIND在执行效率上不如WEB_REG_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忽略思考时间，只算处理时间
添加思考时间
