性能测试脚本的增强：
·参数化
·关联
·事务
·检查点
·思考时间
·集合点
·事务：事务的引入是为了度量相关的业务请求的响应时间和吞吐量指标。
在LR中，事务是通过两个事务函数来实现的。
lr_start_transaction（） 开始计时
lr_end_transaction() 结束计时
·注意事项：
·事务函数只是两个计时器函数，是不会影响脚本的执行逻辑的。
·事务函数一定要成对出现。除了函数本身以外，是通过函数中的事务名称来配对处理的。因此要保证事务名称的一致性。
·事务函数的添加位置，取决于业务和测试的需要。
·事务时间的构成。
事务时间=结束计时-开始计时
我们希望：
事务时间=（业务的）响应时间
但是在LR中，事务时间并不真的等于响应时间，都是大于真正的响应时间的。
在LR中，事务时间=响应时间+wasted time(浪费时间)+think time（思考时间）
·wasted time：浪费时间，是指LR自身的脚本编译、执行所需要的时间，并不包含代码执行之后的效果的时间，仅仅是代码本身的执行时间。
这个时间的大小一般客观的翻译了负载机本身的性能的好坏。
Vugen--》Controller--》Analysi。
当脚本在Controller中运行时，LR会自动将浪费时间从事务时间中剔除。
·think time：思考时间。是指LR脚本的思考时间的执行实际等待的时间。
PS：默认选项下，Vugen中是不运行思考时间函数，Controller是运行的。
当Controller中的结果导入到Analysis组件后，LR会自动将思考时间从事务时间中剔除。这就意味着在Analysis组件中看到的事务时间，已经是非常非常接近真实的响应时间的。
Analysis中的 事务响应时间=事务时间-浪费时间-思考时间。
综上：我们建议，在事务函数中，除了要度量的请求函数，尽量不要添加其它额外的代码。
·事务的结束状态。
在LR中，事务的结束状态总计有四种：
LR_PASS:表示事务的结束状态是成功。
LR_FAIL:表示事务的结束状态是失败。失败只是说脚本运行逻辑出现了fail信号。
LR_STOP：表示事务的结束状态是被停止的。基本不会出现。
LR_AUTO:表示LR会自动来判断事务的结束状态，从而选择PASSFAILSTOP。
LR会自动根据事务函数中所包含的有结束状态的函数的结束状态来自动判断。
如果函数是请求类函数，那么该类函数成功与否是取决于服务器的响应的响应代码（状态码）。
如果函数是功能型函数，那么该类函数成功与否是取决于函数自身的功能是否实现的。
因此，如果是LR_AUTO，那么事务成功其实不一定代表业务成功。如果要检测业务是否成功，则需要用户自己添加检查点来实现判断。
·检查点：
又叫断言（assertion）。
其实就是由代码代替人去完成功能测试（对比实际结果和预期结果）。
在LR中，检查点函数主要使用的是：web_reg_find（）函数。
·注意事项：
·web_reg_find函数是一个注册型函数，一定要放在要检查的请求之前。
·检查内容可以来源于正确的响应，也可以来源于错误的响应。
（预期值）要求具有唯一性和排他性。
示例：假设服务器响应的情况有六种，三种正确和三种错误的情况，分别如下：
T1：abc 123
T2：abd 134
T3：acd 245
F1：efg 567
F2：efh 578
F3：egh 568
问：通过哪些字符可以判断请求是成功还是失败？
a、e
·检查内容必然是来源于服务器的响应源代码，而不是界面所见到的内容。
·检查内容必须精确（准确）。
·检查点函数的解析：
·检查点函数内部有三个功能：查找、保存查找到次数、判断是否找到。
·Fail if：默认是执行的。选项有两个：
Not Found：如果预期值没有找到，则失败。
Found：如果预期值找到，则失败。
默认选择的是Not Found，即针对的是正确响应的预期值。
·Save Count：该选项是用来填写一个参数名，由用户自己指定。用来存储预期值的查找次数。
PS：如果勾选该选项，没有勾选Fail if选项，则最终检查点函数是不会执行Fail if 检测的。
通常来说，如果勾选了Save Count选项，则意味着我们不希望检查点函数自己检测，则是由我们自己来实现事务成功与否的判断啦。
示例：假设服务器响应的情况有六种，三种正确和三种错误的情况，分别如下：
T1：abac 1aa2e3 4a
T2：abad 1aa34 4a
T3：acda 24aa5a 5a
F1：efag 567 a
F2：efh 5aa78 aa
F3：egah 568 a
问：如何判断请求是成功还是失败？
此时只能根据字符（字符串）“a”出现的次数来判断啦。
if(atoi(lr_eval_string("{num}"))>=4)
·思考时间：
参考运行时设置。
PS：在实际测试过程中，建议添加随机的思考时间，这样对于场景的模拟是有好处的。
随机思考时间建议1-5s。
·集合点：集合点是为了模拟严格意义的并发测试而存在的。
通常来说，一旦做集合点操作，即做严格意义的并发模拟，通常我们只关心两个指标：
·错误率
·响应时间
一般来说，一旦添加集合点，通常不会长时间负载，而是指定次数进行负载。
在LR中，集合点是通过函数（Vugen）+设置（Controller）来实现的。
函数：lr_rendezvous()
·注意事项：
·集合点函数本身不会影响脚本的执行逻辑，在脚本中只是一个标记。
表示任何虚拟用户任何时候运行集合点函数后，就会遵守集合点策略进行等待。
·集合点策略：
在Controller的菜单项：scenario-rendezvous选项中进行设置。
·disable Vusers：该选项并不是说禁止用户运行脚本，仅仅是表示这些用户不再受到集合点策略的影响，即列为不受控用户，不参与集合。
·集合点策略设置的是两个要素：一次集合的人数、超时时间。
针对集合的人数，LR提供了三种可选的方式：
·% all vusers：以所有受控虚拟用户为基数，通过百分比来设置集合人数。
·% all running vusers：以所有运行中的虚拟用户为基数，通过百分比来设置集合人数。
PS：个人理解，该处存在bug。在统计过程中，统计了不参与集合的虚拟用户。
·Vusers：直接设置集合点的人数。
超时时间，LR提供的超时时间是虚拟用户之间的等待时间，而不是第一个虚拟用户到最后一个虚拟用户的等待时间。
·不同业务的并发的实现：
·不同的业务一定要有两个不同的脚本。（A和AB）
·在不同的脚本中添加集合点，名称保持一致即可。
·集合点函数的添加位置：
集合点函数必然是添加在事务函数之前。
·脚本增强技术的总结：
·一般来说，事务和检查点是必加的。
·参数化和关联是属于增强手段，视情况而言。但是实际业务中，基本上也是必须使用的。
·思考时间的添加会影响到TPS（虚拟用户数固定的情况下）。
一般来说，对于没有高并发诉求的场景，我们都建议添加随机的思考时间。
·集合点：一般就是用来测试高并发的场景的。