性能测试概念点分析与过程讲解

  1.  录制方式：
  1. 基本流程为：协议选择→设置录制选项→开始录制→插入命令→停止录制→回放验证

    协议选择：根据程序框架决定，比如一般情况下，B/S架构的程序都会使用http协议，当然还有一些ftp协议等，C/S架构的程序则很可能会使用一些不常见的协议所以，协议选择这一步，最好和对于开发人员沟通好确定好。

    设置录制选项：

    1)、录制准备事项

    Start recording 设置：

    Application type：可选择需要录制的对象类型，Internet Applications（录制对象是一个网络应用，基于浏览器）、Win32 Applications（支持Win32的标准客户端）。

    Program to record：设定需要录制的程序名，默认为IE，建议不要使用其他的三方的浏览器进行录制，以免出现不兼容，火狐低版本可以兼容，如果经常需要录制脚本，建议准备一下低版本的火狐浏览器，毕竟支持H5页面的浏览器不多。

    URL Address：录制的地址，比如 www.aicai.com。

    Working directory：用来指定代码的工作目录，一般默认就好。

    Record into Action：设置录制内容的存放位置，vuser_init、Action、vuser_end 这里需要说明的是 vuser_int/vuser_end 只会初始化一次，也就是说，无论脚本循环几遍，每个虚拟用户只会在启动脚本和结束脚本时去分别执行vuser_int脚本和vuser_end脚本。真正执行循环的脚本则是主体action，因此看压力需求需要，一般的压力测试主体都会放在action，但是比如在压力主体前需要登入，但压力测试的业务又不是主要压测登录，则会将登入放在vuser_init里面。

    2)、录制选项 

    Recording Options 设置：

    Script：基于Web（HTTP/HTML）协议的Vuser脚本是使用C语言作为标准的。

    Protocols：协议列表，一般在创建脚本时，会选择好录制脚本的协议，那么这时候的协议列表则是在选择好的协议之下所包含的各个协议。

    Recording：录制选项用于设置Web（HTTP/HTML）使用的录制方式，HTML-based Script（以HTML操作为录制级别）、URL-based Script（以HTTP请求为录制级别）。

    这里可以对这两种录制方式进行进一步的说明：

    HTML-based script是默认的模式,该模式可以为每个用户操作生成单独的函数.URL-based script则可以捕获所有作为用户操作的结果发送到服务器的HTTP请求,然后一一记录下来.URL-based script模式甚至可以捕获非HTML应用程序,例如小程序和非浏览器应用程序. 因此，可以这样理解，HTML-bsed script 可以看做是基于动作的录制方式，每次操作一个总请求，然后总请求里面包含了该动作的所有请求，比如我们点击首页这个动作，该动作可能包含有很多图片，css,js。等等请求，而这些请求都包含在一个请求提交里面。URL-based script 则可以看做是基于url请求的录制方式，这个模式下，每个操作中包含的所有请求会以http请求的方式独立发给服务器，也就是说一个点击首页的操作，可能包含css,js，图片等30多个请求，那么这些请求都是按一些顺序单独发过去的，一个个异步加载。

    使用HTML-based script录制的脚本直观,易于理解和维护,而基于URL-based script模式录制生成的脚本内容看起来会比较多,将HTML方式中的一个函数拆分成了很多独立的函数,但是这种脚本的可伸缩性更强,记录了更详细的用户操作信息.所以一般有经验之后都会喜欢这种模式，而且这种模式下跟我们抓包抓到的数据是一一对应的。当然，具体怎么来选择用那种方式并没有强制性，可以按自己的习惯来，但是有几种请求则必须使用URL-based script 模式。比如 存在ajax提交的业务操作。爱彩则大量使用了这种提交方式。

    选择哪种模式应该根据实际需要来进行,下面是一些常见的参考原则:

    1.基于浏览器的应用程序推荐使用HTML-based script

    2.不是基于浏览器的应用程序推荐使用URL-based script

    3.如果基于浏览器的应用程序中包含了java script,并且该脚本向服务器发送了请求,比如DataGrid的分页按钮等,推荐使用URL-based script;

    4.基于浏览器的应用程序中使用了HTTPS安全协议,建议使用URL-based script方式录制.

     

     

    Date Format Extension：将一些常见的编码格式进行转换，便于后期处理，可针对Body、Headers、Cookies、Query String四种数据段进行转码。这一块一般请求直接默认吧。

    Port Mapping：提供了对端口映射的处理规则。

    Correlation：打开脚本录制时的自动关联选项。

     

     

    3)、 开始录制

    当设置好录制选项后，单击OK按钮启动录制。

    首先会看到Recording Bar，然后就会弹出IE并自动跳转到设定好的页面，接下来就是按正常操作流程对页面功能操作一遍了，而LR会把操作过程转换成一个个提交请求。

    4）、 插入命令

    在录制的过程中可以通过Recording Bar添加一些命令。如切分脚本、添加事务的开始点和结束点、添加集合点、添加注释 等等，根据需要，按需酌情添加，对脚本业务没有什么关系和影响。

    5）、结束录制

    录制结束后，单击Stop停止录制，客户端和服务器交互协议会被放在Generation Log内，VuGen随后会对协议交互进行分析，生成脚本。

     

    6）、调试验证

    脚本录制完成后，一般是跑不起来的，必须对脚本进行调整和增强。需要做的调整和增强一般有：

            1.每个请求的作用需要了解，对于一些如图片，CSS等资源性的请求可以忽略甚至直接可以删除，因为一般性能测试还是对业务逻辑和处理进行压力测试。

            2.对于submit等提交参数的请求进行关注，分别了解各个请求的作用，并分析请求参数是否需要做参数化，参数是否随用户，时间，请求次数的改变而改变。（参数化后面详细来讲解）

            3.关注控制具体业务操作的请求，特别关注请求中url或者提交中带有的参数，一般这些参数都会对于控制一些业务操作，比如一个查看订单的请求，可能url中就包含有订单号或者用户加密信息等关键的信息，这时候如果压力测试是这个查询订单的功能，自然需要对这些参数进行参数化，但是这时候怎么参数化呢，因为像订单号这种东西是服务端返回给用户端的。不可能直接在用户端随机生成传给服务端。因此，这时候需要用到另外一个比较重要的功能----关联，关联就是在服务器生成订单号并传给客户端的时候，先把这个参数保存起来，然后在后续操作需要使用这个订单号的时候，把这个参数传递给对应的参数的过程，这个保存并参数化的动作，LR性能测试里面叫做关联。（关联的具体原理和使用后续来讲解）

           4. 对于检查点和校验逻辑的使用，一般我们会在脚本中加入一些图片和特定的文字作为检查点，比如我们请求首页，会有一些欢迎的文字，等，我们只要能在请求响应中找到这样的字样，则认为这个请求的成功的。还有一些特定的图片比如只有这个页面有这张图，那么我请求这个页面只要响应返回了这张图片，则认为请求成功。这些特殊的属性都可以作为一些检查点来判断脚本执行是否成功的标志。当然，还可以把响应中一段特殊的响应字符作为比如响应中的响应码和响应状态：code:0 success 等。至于逻辑判断，一般也是基于文字判断的基础之上的，比如在判断文字存在的前提下我们先给一个标记表示找了了检查的值也就是说请求是成功了，然后在用一个逻辑处理，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 参数化详解：

               首先，我还是要巴拉巴拉一下参数化的概念和意义，什么叫做参数化：参数化，就是在我们录制好脚本，或者写好提交请求中那些被写死的值，但是这些值又会因为提交请求不同或者用户要求变化而做的一个工作，其本质就是每次提交中力求能让这个参数的值得到变动更新。那么为什么要参数化：简单的说，就是为了更符合需求，让模拟的提交数据更符合真实数据。比如测试登入功能，如果不做参数化，那么所有的提交请求都是同一个用户在做登入操作，虽然不见得每个系统都对用户登入做了限制值允许同一个用户同一时间登入一次，在没有做这个限制的系统里面，测试登入场景的并发，使用一个账号做并发和使用不同的很多账号做并发，在提交过程中看似并没有什么不一样（服务端缓存除外），但是从数据看，还是显得太没有说服力了，至少真实情况不是这样的，因此为了更贴切的模拟出真实环境的效果。（当然也还有其他原因，比如刚才提到的服务器端缓存，如果同一个用户不断去并发，则实际上登入操作的一些查询是不走库的，直接走缓存了，这样跟我们需求的实际情况是不相符的。）
                LR中（不局限于LR）参数化详解：
            先允许我拿一个小例子来讲：
web_custom_request("jyzdgateway.aicai.com/gataway",
"URL=http://jyzdgateway.aicai.com/gataway/req?service_name=ec_freeze_balance&partner_id=10001&sign=f745fae2c597ce28b682fd120d76b75e&sign_type=MD5&request_time=20150725120026&out_freeze_no=dj{NewParam}&freeze_amount=10&identity_id={NewParam_1}&account_type=MEMBER&summary=HAHA TEST SUMMARY&ext1=ext11&ext2=ext2222&ip=192.168.1.1&_input_charset=UTF-8",
"Method=get",
"Resource=1",
"Referer=",
"Snapshot=t2.inf",
//    "EncType=",
LAST);

 

 
            上面这个提交是账户资金冻结接口，其中传入了很多参数，其中主要有一个用户ID，以及订单号，这两个是要重点关注并参数化的，一个是用户维度的，这里业务是支付冻结，涉及到账户表计流水表的操作，那么如果同一时间，对同一个用户钱包进行更改操作，会产生什么情况，当然，不同业务下可能还是允许的，但如果同一种业务同时多笔请求对该用户记录进行更新操作，这在真实情况中应该是不存在的，所以这里就对用户ID的参数化提出了一个要求----并发过程中保证同一用户的钱包记录被单个请求占用。所以这样就让我们在选择以何种方式进行参数化提供了依据。显然的，这里我们需要选择unique，至于每次循环是否迭代，我这里选择的once，也就是说只在第一次取值时，每个并发用户都取不一样的，后续每次迭代都使用第一次的取值。当然，如果准备的用户量够大，够多，也可以选择每次迭代（前提是要准备足够多的用户，要不会报错测试不能进行）。
           还是按部就班的来，先介绍一下参数化的类型：
            图中可以看到，参数化的类型有很多，我大概讲几种把，比较常用的一种，file：就是读取一个制定好的文件按照配资好的规格取值的方式。优势很明显，参数都是自己制定的，可控且保证正确性。麻烦就是，数据量大的时候，要花很多时间去整这个文件。Random   Number：随机数参数，这个可以看成一个随机函数生成的值，真的很随机，完了LR自己都不知道下一个是啥值，这种方式在一些场景下能发挥重要作用，比如一些需要客户端生成的参数但对唯一性要求又不是那么高的情况，其实即使我上面的订单号（其实对唯一性要求还是比较高的），也是可以使用这个类型的，大不了设置两个5位的随机数组装起来，这样，跑的时间不长的话，其实重复的可能性很小。unique Number,唯一随机数，自动生成，适用于一些页面传递过来的唯一值。还有一种高端点的链接数据库做参数化，这个后续会开一个单独的章节讲一下。
            当同一个脚本中有几个参数进行参数化的时候，比如登入脚本中，用户名和密码，这时候就要保证一个关系，就是当取的用户名是A是，则必须取A对应的密码，才算参数化成功，这样才能正常登入。这种关系实际上在LR 中参数化的时候设置一下就好了。比如：
在做这个参数化文件的时候，我们一般会把相关联的参数放到一起，用户名一列，密码一列，并且一一对应好。
然后当我们选择好用户名参数化后，密码参数化的时候，就会在select column出现一个select by 用户名。的选项，就是说，用户名取那个，密码则取同一行的一个，自然就一一对应了。
            
            说完了这些基本的设置，真正参数化比较难以理解的来了。最容易搞混，也最难理解的就是真正在场景中并发跑脚本的时候，每个用户每次循环到底是如何取值的，接下来就详细的来介绍一下：

            脚本设置完参数化，脚本运行的每一遍所取的参数化的值都不一样，那么这个值按照个什么情况来取呢？

Select next row【选择下一行】:

 

select next row 的意思就是，取下一个参数的方式，有三种，按顺序一个个取，从第一个取值到最后一个，或者随机取值，就是每次迭代的时候，随机在所有参数里面抽取一个作为这次迭代的值。还有就是唯一，唯一的意思是每次参数取值时，都取跟其他参数不一样的值，并且每次迭代都保证不一样，所以才说，唯一的取值方式能保证每个用户的每次迭代取值唯一，因此这时候所需要的参数值的量十分巨大，比如一个脚本打算用5个虚拟用户去并发跑场景，而跑5分钟，每个用户假如能迭代50次，那么这5个用户在这5分钟所需要的参数就是50 *5 =250个参数。当然，这里的250个参数是指参数的个数，至于这250个参数里面，可能存在值一样的，则没关系，因为LR取值时按照行号（可以认为是ID号来取的），只要ID号不一样，则被认为是不一样的参数。

顺序（Sequential）：按照参数化的数据顺序，一个一个的来取。

随机（Random）：参数化中的数据，每次随机的从中抽取数据。

唯一（Unique）：为每个虚拟用户分配一条唯一的数据

 

Update value on【更新时的值】： 

 

update value on XXX ,就是说参数的值在什么时候更新，为什么要有这个设置呢？是因为我们脚本中有可能同一个参数会出现多次，也有可能我们业务需求，需要这几个同样的参数在每次循环中保证一致的值，但有时候业务需要又需要这几个同样的参数每次出现都以不同的值出现，甚至有时候，因为业务特性，这些值只需要在第一次循环的时候进行参数化，之后的数据可以一致保持不变。因此这里会有按每次迭代更新参数值，按每次参数出现时，更新参数值，和once，即只在第一次参数化时更新参数值。

每次迭代(Each iteration) ：每次迭代时取新的值，假如50个用户都取第一条数据，称为一次迭代；完了50个用户都取第二条数据，后面以此类推。

每次出现(Each occurrence)：每次参数时取新的值，这里强调前后两次取值不能相同。

只取一次(once) ：参数化中的数据，一条数据只能被抽取一次。（如果数据轮次完，脚本还在运行将会报错）

 

上面两个选项都有三种情况，如果将他们进行组合，将产生九种取值方式。

Select Next Row

【选择下一行】

Update Value On

【更新时的值】

Replay Result

【结果】

顺序（Sequential）

每次迭代(Each iteration)

功能说明：每迭代一次取一行值，从第一行开始取。当所有的值取完后，再从第一行开始取

如：5个用户并发测试，总共准备的参数有10个，然后并发的时候每个虚拟用户跑了11遍，则具体取值情况为：所有用户，第一遍循环取第一个值，第二遍循环取第二个值........第十一遍循环取第一个值。也就是说对于每一个并发的用户来说都是按照这个规则从第一个开始取值取到最后然后重新开始从第一个开始取值，所以同一遍循环中，所有的并发用户是取到的值时同一个。

顺序（Sequential）

每次出现(Each occurrence)

功能说明：每次出现取一行值，从第一行开始取。当所有的值取完后，再从第一行开始取

如：和上面的一样，只是重新取值的时候换成了每次遇到该参数就重新取值。比如一个脚本中参数A出现了2次，每次迭代取值则跑一遍脚本取一次值，所以同一个循环迭代中，脚本中两个地方出现的参数A值一样，而每次出现取值则第一次出现取一个值，第二次出现取另外一个值。

顺序（Sequential）

只取一次(once)

功能说明：每次迭代都取参数化文件中第一行的数据。once，很明显，更新值只更新一次，那就是第一次迭代的时候，所有用户，按循序去取第一个值，之后则不再进行更新，无论循环多少遍，都用这个值去迭代。

随机（Random）

每次迭代(Each iteration)

功能说明：每次从参数化文件中随机选择一行数据进行赋值，对于每个并发用户都是这样，而且取值没什么规律可言，所以对于10个用户并发来说，反正每次迭代每个用户的取值都不确定，很随机。当然，也可能会有取值重复的，

随机（Random）

每次出现(Each occurrence)

功能说明：同上，每次参数出现，所有用户随机取值

随机（Random）

只取一次(once)

功能说明：还是一样的随机，所不同的是，这次只在第一次随机取值，而后续的迭代则一直沿用第一次随机取到的值。也就是说，10个并发用户，第一次迭代，各自随机去取值，无论取到了什么，那么接下来的迭代都用这个取到的值。所以这10个用户第一次所取到的值有可能不一样，也有可能个别重复。

唯一（Unique）

每次迭代(Each iteration)

自动分配块大小

功能说明：唯一性取值，这个理解起来比较绕，用一个列子来说明，假设10个用户并发去跑场景，假设跑5分钟各自跑了10次循环，那么当这是个用户泡脚本之初就会去分配参数，第一个用户要跑十次，所以第1--第10个参数分配给第一个用户，第二个用户则分配第11-20个.......一次类推，这样如果10个用户跑10遍则需要至少100参数去参数化，然后取值也是按顺序来的，第一个用户第一次循环取第1个值，第二个用户第一次循环取第11个值，第三个用户第一次循环取第21个值，，，，以此类推。所以所有的取值都不会重复。对于单个用户来说，每次遍历都是取新值，对于所有并发用户来说，每次循环的取值也不同，所以保证每个取值都是唯一的。

唯一（Unique）

每次出现(Each occurrence)

步长为1

功能说明：和上面类似，只是更新换成了每次参数出现就取值，

唯一（Unique）

只取一次(once)

功能说明：并发用户取值原则还是一样，比如10个用户，会按顺序去取1--10这10个参数，分别对第一次循环的参数赋值，而之后的每次迭代，则用第一次取到的值。

 
            
 
 

2. 抓包方式

1准备事项
    1. 安装抓包工具以及相关浏览器插件：Fiddler ，火狐浏览器的firebug，等。安装过程这里不再简述了，查阅我之前写过的文档，熟悉这些工具的使用方式。
      LR相关设置：对于手写脚本来说，录制设置其实不重要，因为用不到，那么这里主要需要对运行选项进行设置，也就是Run-time setting 选项中的相关内容，打开Vuser--->Run-time setting 
      Run logic设置一般直接选择默认，这个设置的意思是运行时，action执行的次数，如果调试打算重复执行多次，则可以调整到自己想要的次数。
      Pacing 具体是设置action循环的节奏的，就是上一遍循环完成后是立即下一次循环还是休息一会儿再进行。看业务场景需要了，如果没有必要可以选择立即执行下一次循环。
      Log 上文提到过的日志打印，和上面设置一样就好。主要也是调试用。还是跑场景时对场景参数化数据分析用。
      think time 设置思考时间。思考时间是指在我们脚本执行过程中有一些步骤跟步骤之间的停顿时间，比如登入操作，显然在登入页面加载完成后，到登入提交这个过程，用户需要一个输入用户名密码的过程，那么这两部分请求中间，肯定就有了一个停顿时间，而思考时间就是为了满足这个场景产生的。以便为了更好更准确的模拟用户行为。设置思考时间，需要在脚本中加入思考时间函数lr_think_time(2)，2是停顿的时间，单位秒。在脚本中加了这个函数之后如果运行设置中不设置think time选择，则这个函数不会生效。当然场景中也会有一个这样的运行设置，要想这个函数生效也要勾选上对应的按钮才行。
      Miscellanioeus 设置一下Automatic Transaction 以便收集每个事物的响应时间和其他测试数据。主要的设置就这几个，其他的大多默认就好。
       
      2.2 抓包
      无论是接口请求还是页面请求，我们都可以想办法把它的包抓到，利用Fiddler这类软件，可以清晰看到一个请求和该请求的响应。而我们写脚本的依据也就来自这些包里面。具体的抓包方法这里不做具体讨论了。查阅以前写过的Fiddler使用，这里主要来分析一下抓包的数据以及和脚本的对应关系。
      首先看每个请求的Headers
       
      上图可以看到Headers中包含了请求的一些关键信息，比如请求方式为get，请求地址为http://wiki.intra.inzwc.com/rest/quickreload/latest/13468871?since=1438235434617，请求报文格式是application/json格式，回调地址referer是http://wiki.intra.inzwc.com/pages/viewpage.action?pageId=13468871,这些信息都是后续写脚本需要用到的信息。接下来看请求参数和body信息。
       
      这是一个我去投资的登录请求，请求用的是post方式，提交的具体参数包含有t=1438236210099(时间戳),mobile=13012312314(手机号码即用户名)，loginPwd=wbTC5wVj6eef7k8VQcc/9TpT5QhFnclzeA/QD4mrbrZqpMyWH8YanJvzEldWSOEBGZuUyju/Ddmb09C5uLnHTBjlbBesv4WHqfVJuNIyi2ioTUuXfqbeAN29WgFMq9NRYe6RJsMxb2fGUxrOFHJjqIIxpfmgFGJ0Av4MmPhoE4c=(登入密码，加密后生成的字符串)，checkCode=uhv6(验证码)。有了这些信息结合上面Headers里面包含的信息，实际上一个提交请求函数就可以写出来了。
      web_submit_data("login", /** ----------函数名称---------**/
      "Action=http://www.woqutz.com/uc/login/crossdomain-ajax-login?t=1438236210099", /***----请求的URL，对应抓包里面的URL----***/
      "Method=POST", /**---提交请求的方式，一般就get或者post两种，其他方式比如update等很少用---***/
      "RecContentType=text/html", /**--请求报文格式，一般也就那么几种，常见的text/html，application/json--**/
      "Referer=http://jyzd.woqutz.com/", /**--回调地址对应headers中的referer--**/
      "Snapshot=t34.inf", /**-LR中的快照，手写脚本这个可以随机写一个，不过txx.inf 这种格式需要保持-**/
      "Mode=HTTP", /**--请求准守的http请求协议，这个一般的B/S结果程序都是一样的--**/
      ITEMDATA, /**-脚本函数中的关键字，上面是对请求头的一些定义，下面则是对body相关的一些定义。-**/
      "Name=t", "Value= 1438236210099", ENDITEM,
      "Name= mobile", "Value= 13012312314", ENDITEM,
      "Name= loginPwd", "Value=wbTC5wVj6eef7k8VQcc/9TpT5QhFnclzeA/QD4mrbrZqpMyWH8YanJvzEldWSOEBGZuUyju/Ddmb09C5uLnHTBjlbBesv4WHqfVJuNIyi2ioTUuXfqbeAN29WgFMq9NRYe6RJsMxb2fGUxrOFHJjqIIxpfmgFGJ0Av4MmPhoE4c=", ENDITEM,
      "Name= checkCode", "Value= uhv6", ENDITEM,
      LAST);
       
       
      这样一个提交函数就完成了，其实一般请求下，LR录制的脚本也好，关键的函数就那么几个，一个是这个提交函数，另外一个常见的是另外一个请求函数：
      web_custom_request("jyzdgateway.aicai.com/gataway",
"URL=http://jyzdgateway.aicai.com/gataway/req?service_name=ec_freeze_balance&partner_id=10001&sign=f745fae2c597ce28b682fd120d76b75e&sign_type=MD5&request_time=20150725120026&out_freeze_no=dj{NewParam}&freeze_amount=10&identity_id={NewParam_1}&account_type=MEMBER&summary=HAHA TEST SUMMARY&ext1=ext11&ext2=ext2222&ip=192.168.1.1&_input_charset=UTF-8",
"Method=get",
"Resource=1",
"Referer=",
"Snapshot=t2.inf",
//    "EncType=",
LAST);

       

      注意看两个函数格式，稍微有点区别，web_submit_data 函数一般都会有参数提交，而且参数会单独一一列出来，而web_custom_request函数其实也有参数提交，只是参数都直接包含在请求地址里面。上面的例子是配资项目账户金额冻结的接口请求。整个URL=http://jyzdgateway.aicai.com/gataway/req?service_name=ec_freeze_balance&partner_id=10001&sign=f745fae2c597ce28b682fd120d76b75e&sign_type=MD5&request_time=20150725120026&out_freeze_no=dj{NewParam}&freeze_amount=10&identity_id={NewParam_1}&account_type=MEMBER&summary=HAHA TEST SUMMARY&ext1=ext11&ext2=ext2222&ip=192.168.1.1&_input_charset=UTF-8 前面的jyzdgateway.aicai.com/gataway/req是真正的请求地址，而？后面的则都是提交的参数，service_name=xxx，以&符号隔开另外的参数，partner_id=10001(商户ID)，sign=XXXXXXXX(安全验证签名)，sign_type=md5(签名方式)request_time=2015xxxxx(请求时间)，out_freeze_no=xxxxxxx(请求订单号)，freeze_amout=10(冻结金额)，identity_id=xxxxxx(用户ID),account_type=MEMBER(冻结用户的类型)，summary=xxxx之后的参数则只是为了日志方便和监控而传入的，跟实际业务关系不大。
      这里列举了两个提交函数，并举例说明了两种请求方式下来选择提交函数以及如何把抓包到的请求转化成LR代码。主要还是要理解抓包抓到的数据每项都是什么，做什么用，LR提交函数中的每项是填什么信息，这样才能在任何转化请求的情况下，来根据抓包收集到的数据转化成我们要的LR性能脚本，
      这里举例的只是两个请求，当然，真正的业务压力测试逻辑可能不止一个抓包数据，可能包含很多个请求，这时候需要我们一个个去写并按顺序排列出来。
       

      关联的使用：

      前文我们聊到过关联，那么关联到底是做什么的呢？
       未完待续
       
posted @ 2015-09-02 15:34  owenhe  阅读(976)  评论(0)    收藏  举报