脚本增强与调试
一般来说，使用LR的Vugen录制的脚本并不能直接用于测试，需要对脚本进行各方面的增强，主要包括添加注释、关联、检查点、事务、参数化、日志输出等。下面结合刚完成的一个web项目性能测试来对LR性能脚本增强和调试作简单的总结（不包括LR工具基本操作和基本概念的解释）。
首先当我们使用LR的Vugen录制完一个脚本后，看着满屏幕LR工具自动生成的脚本代码是否觉得有些无从下手？所以这里有一个特别有用的技巧，就是在录制时可以一边录制一边增加注释，点击录制界面上的增加注释按钮即可实时的增加注释到脚本中，比如在输入登陆用户名和密码、点击某个关键的连接或按钮时，这样录制完成的脚本中就充满着标识业务操作流程的注释，也就不致于迷失在满屏幕的脚本代码中。
完成脚本的录制后一般可以按照以下步骤对脚本进行增强：
1）脚本初步检查以及增加头注释
2）关联操作
3）增加检查点和事务
4）进行参数化
5）增加集合点
6）思考时间设置
7）手工输出日志
1、脚本初步检查以及增加头注释
对脚本进行整体检查，去掉一些无关的内容，比如一些无用的cookies，录制到的浏览器启用SmartScreen滤选器的认证请求（也可以在浏览器选项高级中关闭）等，当然这些还需要不断的经验积累。为便于后续脚本的维护，有必要增加脚本的头注释，对脚本标题、功能、日期版本等内容进行说明。
2、关联操作
关联是LR脚本增强最关键最核心的步骤，基本上也是脚本增强中工作量最大的，一个脚本中有多少个需要关联的地方取决于系统所使用的架构。LR的脚本能不能始终正确的完成对应的业务操作，就看这一步是不是正确的完成了。有时我们不进行参数化或只迭代一次时脚本运行和业务操作都能正确完成，一但进行了参数化或迭代跑多次后运行就会报错，甚至是运行并不报错但是却发现没有正确完成对应的业务操作，一般都是脚本没有正确关联所引起的。
先简单的总结下几种不同的关联方式，关联分为自动关联、手动关联和一边录制一般关联，几种关联方式的本质其实都是在脚本中添加关联函数web_reg_save_param或web_reg_save _ param_ex来保存服务器返回的某些值到一个参数中，然后供某些请求使用；不同的是自动关联，是通过LR工具本身来判断需要关联的内容，自动在脚本中添加关联函数和参数化操作；手动关联是人工识别需要关联的内容，然后手工增加关联函数和参数化操作；而一边录制一般关联，是事先根据系统架构等将具有公共特征需要关联的内容建立一个规则集合，然后在脚本录制的时候让系统根据规则自动的生成关联函数和参数化操作，以减少手工关联重复操作的工作量。
以上简单的解释了下不同的关联方式，可能首先的判断就是使用自动关联或一般录制一边关联就OK了，何必没事找事的去找麻烦的使用手工关联呢，其实不然，LR的自动关联并不能正确的完成所有需要关联的内容，甚至是有可能进行了错误的关联，那是否要说这是不是LR工具的BUG或者说LR工具做的太烂了呢？就我目前的解释只能说是工具还不能完全达到人工智能的地步，以替代人脑完成对于机器来说更高级的事情。而一般录制一般关联其实也是一种自动关联，当然也存在同样的问题。因此，自动关联和一般录制一般关联只能作为一种辅助方式，在一定程度上减少我们的关联工作量，实际使用中主要使用的还是手工关联或是结合使用这几种不同的关联方式。
一般可以按照以下步骤来对脚本进行关联操作：
a、自动关联，先通过工具的自动关联功能找出需要关联的地方，并逐个进行确认关联。
b、当脚本代码量较小，可以逐条代码进行分析，进行关联，一般代码中的xxxxid很可能就是需要关联的内容。
c、当脚本代码量很大，可能会存在较多的关联时，可以再录制一份相同业务操作的脚本，通过文件对比工具或LR自带的文件比较工具进行比较，找出脚本中不同的地方比逐个确认是否需要进行关联。另外，在录制另一份相同业务操作的脚本时，最好使用与原录制脚本不同的登陆用户和操作的参数，以免遗留待关联的地方。
d、当在同一个系统上录制的多个业务脚本或在同一系统框架下录制的多个业务脚本遵循一定的关联规律时，可以建立关联规则，并可以将规则到处为一个关联规则文件，在录制其他脚本时，先导入关联规则文件，再录制时就可以实现一边录制一边关联（自动关联）了。
附一份通用的手工关联步骤：
a、使用相同的业务流程与数据，录制二份脚本；
b、使用WinDiff工具或LR自带功能协助找出需要关联的数据；
c、使用web_reg_save_param函数手动建立关联；
d、将脚本中有用到关联的数据，用关联的参数取代。
关联的一般性规律：
a、在Submit URL之前的Server Response 中查询待关联值；
b、待关联的值尽量在最靠近Submit URL；
c、关联的左边界尽量能够唯一；
d、不能仅仅在Body中搜索，还需要到各Form中搜索；
e、Session ID、DocID 等一般需要关联；
f、加密（服务器端加密）后的值一般需要关联。
3、增加检查点和事务
在关键地方使用插入文本检查点或图片检查点，目的是确保业务操作的正确性。对性能测试计划或用例中定义的事务前后插入事务的开始和结束函数，目的是测试所定义的交易响应时间，以及在结果中体现我们所关心的业务点或交易点的各维度指标，我这里一般是将检查点和事务结合使用，事务采用手工事务，用检查点来确保该事务被正确的完成。避免使用自动事务出现这样的问题：脚本运行中，某个业务操作本来失败了，即对于LR发出的某个请求，服务器返回了错误提示，但因为没用使用检查点，而且使用的是自动事务，LR工具会误判为该业务操作正确完成造成难以发现的错误。文本检查点函数一般使用注册型函数Web_reg_find并放在要检查的那个请求的前面；事务中一般不要包含思考时间。
4、进行参数化
按照性能测试用例，将需要参数化的值进行参数化操作，参数的取值方式一定要充分考虑具体的业务对参数取值的要求，避免出现因取值造成的业务执行错误；当要将脚本放在后续的场景中执行时，还要充分考虑具体的场合，避免出现因并发用户数较多而值不够等等问题。特别的一点，当参数化的数据量较大（超过100条）时，需要修改Vugen的配置文件中MaxVisibleLines参数的值，比如将100改为10000，以确保取到更多的参数化值（当时就因这个问题导致场景中大量事务执行失败），再一点，LR的参数化取值界面上进行操作时存在一些易用性的问题和BUG，在操作时需要格外小心，操作完成后最好再确认一次，所作的更改是否生效。
一般使用较多的取值方式是：顺序+每次迭代更新，当参数的取值必须唯一时，比如创建一个合同，需要输入唯一的合同号，那么取值方式选择：唯一+每次迭代更新+当取值不够时终止该Vuser，并且结合要跑的场景策略计算出大概的取值个数，并确保参数化数据量充足。
5、增加集合点
增加集合点的目的是模拟对系统产生的绝对并发操作，并非脚本中一定要添加集合点函数，是否需要集合点来产生绝对的并发操作是在脚本调试之前的性能测试计划和用例中就已经确定的。只有脚本中含有集合点函数时，在场景设置中才能设置具体的集合点策略。
6、思考时间（think time）设置
思考时间的大小直接决定了脚本运行对系统产生压力的大小，在整个测试执行过程中会进行多次的调整，其值在性能测试计划中初步确定，脚本中思考时间一般有以下三种策略：1）将每个think time函数的值设置为一个固定值；2）删除所有的think time函数，只在某一处固定一个think time函数；3）设置为按照录制的思考时间的一定百分比大小。在Vugen中单用户调试和跑测脚本时，也可以忽略思考时间。特别的一点，vugen和controller中都能设置思考时间，但在场景中运行脚本时，场景中设置的思考时间（还包括迭代次数、pacing time等运行时设置）会覆盖vugen中的设置。另外当要设置的思考时间是小数时，直接在think time函数中使用小数即可。
7、手工输出日志
当脚本业务操作较复杂在运行时报错，为便于通过日志定位错误和后续脚本维护，可以手工在脚本中关键位置增加日志输出，关于LR中日志参见另一篇日志专题的文章，关于脚本中增加手工日志输出目前我使用的也比较少。
按照以上步骤完成了脚本的增强后，为确保关联正确和没有遗漏，还要进行以下调试。多运行几次脚本，分别依次采用单用户单次迭代、单用户多次迭代、多用户单次迭代、多用户多次迭代的方式来执行脚本，并且在执行过程中保证使用不同的登陆用户或不同的参数取值，除了检查脚本执行不报错外，还要在系统中检查相应的业务操作是否都正确完成。
LR脚本调试运行中出现较多的错误是检查点和没找到关联的错误，当出现错误时除了根据经验来快速排查错误外，一种通用的方法是在出现错误的地方设置一个断点，打开扩展日志中的服务器返回日志，再次进行运行，运行到错误之前的断点处再运行一步，出现错误并停止后，查看服务器返回的内容已确定定位错误原因并排除，不过打开了服务器返回扩展日志后，脚本运行速度会很慢，效率较低，不过该方法很通用，可以找出绝大多数的问题所在。
关于关联还有以下几点说明：
1）vugen的设置中导入了关联的规则文件后，不一定只能是并录制时边关联，可以是使用vugen打开一个未做关联的脚本，然后导入关联规则文件，点击自动关联按钮进行自动关联，关联规则文件同样会生效，不过可能需要进行较多次的自动关联。
2）在使用自动关联时可能需要关联多次，第一次扫描出一部分需要关联的后，再次扫描可能会有更多的需要关联的地方被扫描出来。
3）自动关联时，如果关联变量名依次往后编号，需要特别注意几点：
a、自动关联一部分后，保存脚本并关闭脚本，然后再重新使用vugen打开脚本再次进行自动关联扫描并进行自动关联操作，关联变量名又会从头开始排序，而不会接着上一次的序号往后排，导致关联变量名可能会有重复的问题。规避措施：同一脚本的全部关联尽量一次全部关联完成，期间不要关闭了脚本。
b、手工关联的关联变量名不要按照自动关联的关联变量名的命名规则，尽量保持较大的区别，避免关联变量名重复。
4）自动关联有时只识别到了一个需要关联值得一部分，这时候不要点击自动关联的关联生成按钮，否则会造成关联错误。可以先关联其他地方，最后再手工补充关联。
补充一个在关联中很可能遇到的问题：对于边界值中有不确定字符串时该怎么处理？
如：LR中服务器返回的值是OAMRequestContext_oamtest.huawei.com:80_68504a" value="hPJqIBKLWRWw+iTQYjdZBg=="/>，我想取出“hPJqIBKLWRWw+iTQYjdZBg ==”这段，所以左边界是OAMRequestContext_oamtest.huawei.com:80_6f6c6a" value="，但80_6f6c6a是变化，这时该怎么处理了？
有如下四种处理办法：
① 80_6f6c6a的是从哪里来的，是客户端？还是服务器返回的？如果是服务器的返回，那么我对其做一个关联，然后在关联的左边界中应用另外一个关联
② 若“80_6f6c6a”的长度是固定的，LR提供了“#”来替代数字，使用“^”来代替文本或数字。边界用/ ALNUMIC参数。当时就这么处理了。
③ 若“80_6f6c6a”的长度是变化的，可以以“OAMRequestContext_oamtest.huawei.com:”为左边界，“"/>”为右边界，把“80_68504a" value="hPJqIBKLWRWw+iTQYjdZBg==”这段取出来，然后通过C语言的代码截取需要的部分。
④ 想用正则表达式来做，但没成功，正则不是很会写。
推荐优先使用方法2，如果不能使用方法2那么就使用方法3，基本上绝大多数都能解决了。