怎样插入loadrunner的TextImag检查点

检查点主要有这几个函数：

web_find()，web_image_check，web_reg_find。其中前面两个需要手动在设置里面开启才会生效（按F4，首选项-启用图像和文本检查），并且录制的模式是基于HTML的脚本。

位置：前面两个函数都是放在要检查的请求后面，后面那个放在要检查的请求前面。

插入方法：

1、在脚本界面，右键插入-新建步骤-展开web检查-有图像检查和文本检查（就是前面两个函数），选中文本检查，下面有个下拉框可以选择web_reg_find。

2、在树视图，在请求上右键，选择在之前插入或在之后插入。

3、手打。

建议：不建议用前面两个，效率低，建议用最后一个，用于在服务器返回的数据中查找指定的字符串。你可以在树视图中看到服务器返回的数据。

将来在运行脚本的过程中，QTP又根据查询语句从当前的数据库中获取实际数据，然后将实际数据与预期数据相比较，从而得知检查点是否成功。 2.修改查询结果 检查点语句生成以后，会产生一个DbTable对象，该对象在关键字视图可以看到，在仓库中也存在。可以通过设置该DBtable对象的object properties属性“Source”来修改SQL语句。修改了SQL语句就表示修改了查询结果。修改了SQL语句后，不能相应的修改预期数据表。 3.如何理解检查点的属性（checkpoint properties）上面的表是创建检查点时截取的。（无论什么时候打开本属性窗口， 表中的数据都不会改变，但可以通过窗口中的“Configure value->Constant”来手工修改表中的数据，通过这种方式修改了数据后，就相当于对截图进行了修改。如果通过“Configure value->Parameter”来将单元格的数据参数化，虽然看起来是数据被修改，但是如果再选择Constant，数据就会恢复，因此通过参数化数据的方法，不会真正影响截图的数据。） 4.指定要检查的区域 在表中指定想要检查的区域。（区域中的显示的值就是预期值。预期值可以是常数，也可以是参数变量。当在Cell Identification页中设置列by position时，本表的列必须与实际查询表的列相对应，否则检查不能通过。如在生成检查点语名时查询语句为“select username,id,realname from sys_user t”,后来通过修改object properties，将查询语句改为“select username,realname,id from sys_user t”,则执行检查时是不能通过的，因为查询表中第2、3列的数据已经不能与截取的表相对应。同理，如果在Cell Identification页中设置行by rownumber时，也会有同样的问题存在。） 以下是属性框三个页签中的内容: （1）Expected Data—设置预期值，可以是常量或参数。如，可以要求QTP从DAta table中取值作为预期值。 （2）Settings—设置预期值与实际值相比较时的语法规则。 （3）Cell Identification—指导QTP放置被检查的数据。如，假设你想检查位于检查点属性框中第一行第2列的数据，但是你明白，每运行一次测试脚本，查询出来的数据的行的排序可能发生改变。因此，让QTP通过列名和行row containing a known value in akey column来定位单元格，而不是通过列数或行数来定位单元格。 5.检查点属性窗： Checkpoint timeout—指定检查点运行的最长时限，QTP在检查点通过（在本时间范围内）或超时后，才进行下一步 *** 作。如果在最长时限时还没有检查通过，则本检查失败。 例如，检查点装载数据需要一定的时间，增长checkpoint timeout时间，可保证检查点有足够的时间通过检查，不会超时失败。 注:Checkpoint timeout选项仅仅对table检查点有效，对于database检查点无效。 Insert statement—在新增检查点时，指明检查点语句在脚本中的插入位置。 注意：Insert statement选项在录制或修改检查点时无效，只在新增检查点时有效。 注意：当一列是key column时，该列不一定是被检查的列，key column的数据仅用来帮助确定被检查的数据行。 6.指定数据的比较规则默认情况下，认为真实数据单元是字符串型，并进行精确检查，但是忽略空格。（1）Verification type（2）Exact match默认。 精确匹配。选中此项，则进行精确匹配；不选中，则只要预期值包含在真实值之中即可。 注意:只有当Verirication type为String Content时，才显示这个选项。（3）Ignore space默认。在比较时忽略单元格中的空格。添加或减少空格不会影响检查结果。 注意:只有当Verirication type为String Content时，才显示这个选项。（4）Match case区分字母的大小写。 注意:只有当Verirication type为String Content时，才显示这个选项。（5）Min / MaxCell Identification页签包括以下选项: （1）Identify columns指定将与预期数据相比较的实际数据单元在实际数据表中的列位置。 By position—根据列的顺序位置来定位（即预期数据表中的第N列对应实际数据表中的第N列）。如果列位置产生位移，就会导致不匹配。本选项一般用于Table检查点。 By column name—根据列名来定位（即预期数据表中的列名对应实际数据表中的列名）。列的位移不对检查点产生影响。一般用于database检查点，对于Table检查点无效。（2）Identify rows指定将与预期数据相比较的实际数据单元在实际数据表中的行位置。 By row number—默认。根据行的顺序位置来定位（即预期数据表中的第N行对应实际数据表中的第N行）。如果行发生位移，就会导致不匹配。 By selected key column(s)—选中此项以后，可以设置关键列，关键列列名旁有一个“钥”标记。在定位行时，到实际数据表的关键列中查找与预期数据表关键列的值相匹配的值，所找到的第1个匹配值则是正确的行。行的顺序位移不影响检查结果。如果数据库中有多行同时满足条件，则QTP只检查第1条记录。关键值可以是多个列的联合值。在对关键列进行匹配时，使用Setting页签的verification type选项中设置的匹配规则。 注：只有当选中了By selected key column(s)选项时，本选项才有效。 当选择by row number时，属性窗中预期值所在的行数，应该与真实数据所在的行数相同，否则匹配失败。因此行移位都会导致检查失败。 当选择by selected key column(s)时，属性窗口中预期值可以在任意行位置。执行检查时，以该行Key column列的值为条件在数据库中进行筛选，如果选出了符合条件的记录，则将该记录与预期值进行比较，如果记录数据全部匹配，则检查通过。（当有多个Key Column列时，则筛选条件为这些列的数据的联合）。 要注意几个问题： (1) 只有被打勾的数据才被检查，其它没打勾的即使不匹配也没关系。 (2) Key column列的数据如果没有打勾，也不会被检查，它只是提供查询条件。 (3) 属性窗口数据表中的数据本身就是默认预期数据，当然用户可以对这些预期数据进行修改。 (4) 在属性窗口数据表中的数据是相对固定的，除非用户在本属性窗口中特殊别进行了修改。 (5) 本属性窗口数据表中的所看到的数据都是预期数据，真实数据表是看不到的。真实数据表在每次执行脚本时都有可能不同。 (6) 在运行结果(result)中，如果检查失败，则可点击“checkpoint ‘表名’”看到检查结果表。双击表中的单元格，d出窗口显示该单元格的预期值与真实值。当然，本结果表中显示的仍然是预期值。 (7) 如果在属性窗口的数据表中设置了一个检查点数据，但是数据库中有多条满足条件的数据，则只检查第一条满足条件的数据，如果第1条检查完全匹配，则通过，如果不匹配，则失败。 (8) 如果在属性窗口的数据表中设置了多个相同的检查点数据，但数据库中只有一条满足条件的数据，该条数据只与第1个检查点进行匹配检查。其它几个检查点失败。

一、Loadrunner中事务

LR度量的是客户端发送请求到服务器响应处理并返回的时间，看上去和响应时间没有差异，我在之前也都是这样认为的，但实质上事务和响应时间之间还是存在着一定的细微差异。

实际事务时间包括以下四个部分

第一部分:Wasted time，脚本录制过程中，自动插入所花费的时间；脚本录制后，手工编码输入执行所花费的时间。

第二部分:函数自身所消耗的时间，包括lr_start_transaction和lr_end_transaction

第三部分:Think Time，用于模拟用户思考的时间lr_think_time()

第四部分:响应时间 = 网络+服务器处理时间

注:在事务的时间计算中，会自动排除第一和第二种，第三部分是人为设置或是录制形成，只要做一下减法也可以排除，所以真正事务要度量的时间是第四部分，响应时间。

添加事务的方式

1、当对录制的脚本不是特别的熟悉时，可以选择录制时在工具栏添加事务，这样系统会在自动生成的脚本中插入事务函数

2、如果对脚本较为熟悉，可以选择在录制结束后添加事务

3、纯手工编码添加事务命令

补充：lr_end_transaction函数的int status有四种状态（根据状态去判断事务的执行情况）

LR_AUTO:自动根据规则来判断状态

LR_PASS:系统做了正确的事务，并且记录事务所执行的时间（响应时间）

LR_FAIL:事务失败，没有达到脚本应该有的效果（后期统计中将被独立统计）

LR_STOP:事务被停止

二、 Loadrunner中检查点

如何快速的知道一个脚本在回放时候是正确还是错误，在这里我们就要用到一个函数web_reg_find，通过它去设置检查点，自动在回放的脚本中搜索指定信息，如果找到则通过，如果找不到就是失败。

举个Demo，用LR自带的例子，在登录系统以后，设置检查点，查看系统会给出什么返回。

设置检查点的方式，在Page View视图中选择需要检查的文字，右键选择添加，如下：

如果页面中未出现检查点设置的文本或者图片，则出现错误信息

三、事务与检查点应运

首先录制一个登录的脚本，这里我们对业务熟悉，就直接使用手动插入事务的处理方法，通过鼠标右键，在需要插入事务的地方选择Insert->Start Transaction/End Transaction

插入事务后再次运行脚本，事务以Pass结束，持续时间为0.0556，浪费时间为0.0016s

说明:这里如果是录制时插入事务，那么生成的事务时间需要减去思考时间后，才是事务真正的响应时间。

在事务的脚本中，我们插入检查点，检查点插入的位置通常是放在事务的内部，这样便于理解检查点的作用，检查点函数自身消耗的时间会被事务自动排除。

如果脚本能正确进入Web Tour Welcome页面，那么执行成功，出现下面提示

【补充说明】:与事务相关的函数还包括以下五种:

lr_get_transaction_duration()//获得对应事务到达函数运行位置时持续的时间

lr_get_transaction_duration()//获得对应事务到达该函数运行位置时的waste时间

lr_get_transaction_duration()//为一个事务添加waste时间

lr_get_transaction_duration()//将一个事物暂停，该函数后面的 *** 作都不会被记入事务时间

lr_get_transaction_duration()//将暂停的事务恢复

---