标签：
脚本录制完成后，一般是跑不起来的，必须对脚本进行调整和增强。需要做的调整和增强一般有：
1.每个请求的作用需要了解，对于一些如图片，CSS等资源性的请求可以忽略甚至直接可以删除，因为一般性能测试还是对业务逻辑和处理进行压力测试。
2.对于submit等提交参数的请求进行关注，分别了解各个请求的作用，并分析请求参数是否需要做参数化，参数是否随用户，时间，请求次数的改变而改变。（参数化后面详细来讲解）
3.关注控制具体业务操作的请求，特别关注请求中url或者提交中带有的参数，一般这些参数都会对于控制一些业务操作，比如一个查看订单的请求，可能url中就包含有订单号或者用户加密信息等关键的信息，这时候如果压力测试是这个查询订单的功能，自然需要对这些参数进行参数化，但是这时候怎么参数化呢，因为像订单号这种东西是服务端返回给用户端的。不可能直接在用户端随机生成传给服务端。因此，这时候需要用到另外一个比较重要的功能----关联，关联就是在服务器生成订单号并传给客户端的时候，先把这个参数保存起来，然后在后续操作需要使用这个订单号的时候，把这个参数传递给对应的参数的过程，这个保存并参数化的动作，LR性能测试里面叫做关联。（关联的具体原理和使用后续来讲解）
4.对于检查点和校验逻辑的使用，一般我们会在脚本中加入一些图片和特定的文字作为检查点，比如我们请求首页，会有一些欢迎的文字，等，我们只要能在请求响应中找到这样的字样，则认为这个请求的成功的。还有一些特定的图片比如只有这个页面有这张图，那么我请求这个页面只要响应返回了这张图片，则认为请求成功。这些特殊的属性都可以作为一些检查点来判断脚本执行是否成功的标志。当然，还可以把响应中一段特殊的响应字符作为比如响应中的响应码和响应状态：code:0success等。至于逻辑判断，一般也是基于文字判断的基础之上的，比如在判断文字存在的前提下我们先给一个标记表示找了了检查的值也就是说请求是成功了，然后在用一个逻辑处理，if（找到了字符）执行语句块；else执行语句块；这样就能在请求完这个请求并成功获取到响应之后，进行下一步的操作要不然则执行另外的操作。
5.事务定义：对于脚本中，可以把同一个操作或者多个操作的相关请求定义成一个事务，比如购彩的动作，可以包含获取彩期，提交订单数据，确认支付数据等相关的关键请求。当然，这个事务是我么自己定义的，名字自己随意取，定义事务的目的一个是为了更细的监控和评测具体的流程操作，另外一个也使脚本思路清晰易读，因此只要不违反这个根本目的，怎么定义都行，看自己喜好。
6.完成前面5步，就可以开始回放调试了，在调试时可以把Run-time setting中log这一项的Extended log parameter subsitution勾选上，这样可以看到调试中参数化所有参数的具体取值，一遍查证参数是否取正确。在执行一遍脚本之后，除了看日志报错以外，还需要确认数据是否入库以及各请求提交响应是否异常，并且打开View-->Test result查看各请求的响应情况。待调试通过后，脚本编写阶段的工作，就算完成了，接下来就是真正的构建场景压力测试了。
实例：
web_reg_find( "Text=当前日"，
if(atoi(lr_eval_string ("{count}"))>0)
{
lr_output_message ("登录成功");
}
else
{
lr_output_message ("登录失败");
}
6.1 参数化详解：
首先，我还是要巴拉巴拉一下参数化的概念和意义，什么叫做参数化：参数化，就是在我们录制好脚本，或者写好提交请求中那些被写死的值，但是这些值又会因为提交请求不同或者用户要求变化而做的一个工作，其本质就是每次提交中力求能让这个参数的值得到变动更新。那么为什么要参数化：简单的说，就是为了更符合需求，让模拟的提交数据更符合真实数据。比如测试登入功能，如果不做参数化，那么所有的提交请求都是同一个用户在做登入操作，虽然不见得每个系统都对用户登入做了限制值允许同一个用户同一时间登入一次，在没有做这个限制的系统里面，测试登入场景的并发，使用一个账号做并发和使用不同的很多账号做并发，在提交过程中看似并没有什么不一样（服务端缓存除外），但是从数据看，还是显得太没有说服力了，至少真实情况不是这样的，因此为了更贴切的模拟出真实环境的效果。（当然也还有其他原因，比如刚才提到的服务器端缓存，如果同一个用户不断去并发，则实际上登入操作的一些查询是不走库的，直接走缓存了，这样跟我们需求的实际情况是不相符的。）
转载至：（作者：owenhe 来源：http://www.cnblogs.com/7test/articles/4778743.html）
标签：
原文地址：http://www.cnblogs.com/Grace7582/p/4808302.html
