1、事物
1）概念
loadrunner里响应时间指的是事物的响应时间、TPS指的是每秒通过的事物数，因此事物是loadrunner跑脚本的基础。事物是用来计时用的，把一个或多个请求圈起来放在一起，统计这一个或多个请求的时间。
2）定义事物时保证事物的准确性（干净）
● 一个事物里就放一个被测请求，这样事物响应时间就是请求响应时间；
● 除了被测试请求外，事物中不放任何其他东西，检查点、集合点全放在事物外面；
● 录制时用纯的URL，这样一个URL就是一个请求；
● 修改录制脚本中Mode=“HTTP”；
3）单场景压测与混合场景压测
● 单场景测试：先测单个接口是否满足要求，不用考虑其他依赖
● 多场景测试：对多个接口共同进行压测
问题1：对于用户来说，用户要注册必须得先进入首页，要压测注册请求是不是要模拟用户的实际操作来压接口？
要压注册不用脚本中不用加首页，单场景压测脚本的干净性会影响响应时间和TPS，如同样是压注册，小A的脚本里有首页和注册两个请求，小B的脚本里只有注册。同样运行5分钟小A的注册TPS肯定会小于小B的注册TPS。
问题2：单个场景压测，用户操作注册动作，除了注册单个API，还有js、css等请求也会对服务器有压力，怎么处理？
Js、图片、css样式都不用管，一方面有专门的前端性能测试会去测试，另一方面现在都是采用缓存技术，访问一次这些图片等静态资源资源全部缓存下来了，后面发的都是纯的接口请求。
4）添加事物
● 可录制时加事物也可录制完成后再添加事物，录制时添加事物，容易有冗余，不干净；
● 录制完后加事物，可ctrl+T,也可点击下图图标
● 录制时加事物，点击如下图标
2、检查点
1）概念
检查点的实质是从请求的response里判断有没有返回某个字符串，从而判断请求有没有成功。
压测要保证请求的成功率，检查点会影响请求成功率，通常与金钱相关的要求成功率为100%，其他的为99%、99.9%、99.99%，视具体项目而定。
2）什么情况下加检查点
问题1：脚本中一定要加检查点吗？
检查点影响性能，不必要的检查点不加。
问题2：如何确定是否要加检查点？
● 数据库的add、update、delete操作不用检查点（跑完数据库查）；
● 数据库的查询操作一定要有检查点；
3）添加检查点
3、集合点
1）概念
当通过controller虚拟多个用户执行该脚本时，用户的启动或运行步骤不一定都是同步的。集合点是在脚本的某处设置一个标记，当有虚拟用户运行到这个标记处时，停下等待，直到所有的用户都达到这个标记处时，再一同进行下面的步骤。这样能够用最大的用户并发去做下面的操作，就像集合再前进一样。集合点是为加大瞬时并发的概率，通常抢购、秒杀会用到。
2）插入集合点
4、思考时间
1）概念
控制单位时间段内向服务器发起请求的数量，以达到控制服务器压力的目的，从而影响测试的响应时间以及tps。
2）Run-time setting中开启think time
3）思考时间如何影响响应时间
例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
4）思考时间如何影响TPS
假如TPS很大，单位时间内发的请求越多，TPS就越大。那么加思考时间会让单位时间内发送的请求数变少，从而使TPS减少。
例：服务器tps=100,每次处理时间为0.1s
1个vu,1s能发10个请求，则tps=10
1个vu,思考时间1s，处理1s,则tps=1
TPS 简单说明
* 1s是按过去的上一秒算的，过去1s内处理的事物数，
* tps忽略思考时间，只算处理时间
5）添加思考时间
