性能测试指标的基本概念 (摘抄)

吞吐量/处理能力
处理能力又叫吞吐量，指的是单位时间内处理的客户端请求数量。通常情况下，吞吐量用请求数/秒 Or 页面数/秒来衡量。从业务角度看，吞吐量也可以用访问人数/天Or页面访问量/天来衡量。

负载
负 载分为客户端负载和服务器端负载客户端负载的通俗解释就是有多少个用户在同时使用软件服务器端负载的通俗解释就是有多少个请求同时到达了服务器端，要求服 务器进行处理。例如，某个网站当前有10000个人在线访问，从他们的客户端层面看过去，这个负载就是客户端负载，为10000。若某个网站当前有 10000个人在线访问，某一时刻，从他们的客户端同时发出了1000个页面的请求到服务器，从服务器端层面看过去，这个负载就是服务器端负载，为 1000。

响应时间
响应时间是可以判断一个被测应用系统是否存在性能 瓶颈的最直观的要素。例如，在执行完性能测试后，发现某个交易的“平均响应时间”为8秒，超过了预先确定下来的性能指标“该交易的性能指标为平均响应时间 要小于等于3秒”。此时，就可以认为被测应用系统存在性能瓶颈了，要利用一定的手段去探查被测应用系统中哪个地方引起了系统的处理效率低以及低的原因了。 响应时间一般包括最大响应时间和平均响应时间，响应时间包括网络上的传输时间，WEB服务器上处理时间、APP服务器上的处理时间、DB服务器上的处理时间，响应时间不包括浏览器上的内容显示时间。

同时在线用户
对 于一个网站来讲，当一个用户登录到该网站的首页后，开始在该网站上进行各种操作，包括浏览网页、检索内容、提交表单等，这个过程中的用户称为在线用户。若 同一时间点或同一个时间段内，有很多这样的用户在访问该网站，这些用户统称为该网站的同时在线用户。同时在线用户的另一层理解是，将应用系统整体看作是一 个黑盒子，从用户的客户端层面看向系统，总共有多少个人在使用它。当进行性能测试时，如果你使用的是同时在线用户，则可以称之为同时在线负载。

超级并发用户
对于一个网站来讲,可能存在WEB服务器、应用服务器、数据库服 务器三个层次，而用户所使用的浏览器是在最外面的客户端层面。如果某个时间点或时间段内，共有1000个用户同时在线，他们进行着各种各样的操作，而某个 时间点上可能存在10个左右的用户同时进行了一个或多个操作，导致WEB服务器同时接收到了10个左右的交易请求，我们称这个10个左右的用户为超级并发 用户。当进行性能测试时，如果你使用的是超级并发用户，则可以称之为超级并发负载。

性能测试脚本
脚 本是用负载模拟工具开发出来的。脚本是一些代码的组合体，它用代码来实现用户对应用系统的操作。例如,你在一个网站上访问首页、输入用户名和密码后点击登 录按钮进行登录，这是用户对应用系统的两步操作内容，在脚本中则包含了实现这两个操作步骤的代码。如果你要模拟10000个用户的负载，这10000个用 户中50%进行首页的访问、20%进行注册、20%进行查询、10%进行某个页面的浏览，则你需要制作5个脚本，分别是首页访问脚本、注册脚本、查询脚 本、页面浏览脚本。

事务
事务是脚本的一个特性，每个事务都包含开始事 务和结束事务。事务用来衡量脚本中一行代码或多行代码的执行所耗费的时间。你可以将开始事务放置在脚本中某行代码的前面，将结束事务放置在该行代码的后 面，在该脚本的虚拟用户运行时，这个事务将衡量该行代码的执行花费了多长时间。

交易
交 易分为业务层面和技术层面两种定义。业务层面交易是指完成一次完整的业务操作，例如进行一次取款、查询操作。技术层面的交易是指进行一次应用程序至应用程 序、或者应用程序至数据库的系统操作。一般的一笔业务交易由多笔技术交易组成，根据业务交易的复杂度和系统应用架构的不同，其比例大致为 1：2-1：10。

TPS与HPS
TPS (Transactions Per Second)是估算应用系统性能的重要依据。其意义是应用系统每秒钟处理完成的交易数量，尤其是交易类系统。一般的，评价系统性能均以每秒钟完成的技术 交易的数量来衡量。系统整体处理能力取决于处理能力最低模块的TPS值。依据经验，应用系统的处理能力一般要求在10-100左右。不同应用系统的TPS 有着十分大的差别，一般需要通过性能测试进行准确估算。当系统没有达到性能瓶颈时，TPS随着负载的增加呈近似线性增长，当接近性能瓶颈时出现拐点；如果 系统健壮性较好，在到达性能瓶颈后，TPS基本保持水平，不会再随着负载的增加而有显著增长；而如果系统存在比较严重的性能问题，当到达性能瓶颈 后，TPS会出现明显的下降趋势。HPS：(Hits per Second)每秒点击次数，是指在一秒钟的时间内用户对Web页面的链接、提交按钮等点击总和它一般和TPS成正比关系，是B/S系统中非常重要的性能 指标之一。
TPS可以有多种衡量单位，在进行性能测试的业务模型分析时使用，例如：
（1）在税务系统中，可以用“系统每个月要处理10万 用户的业务操作”，这里的TPS用企业数/月来衡量；（2）在税务系统中，也可以用“系统在第七天的8个小时内要处理4万用户的业务操作”，这里的TPS 用企业数/天来衡量；（3）在税务系统中，也可以用“系统在第七天的10点到11点之间要处理1.2万用户的3种缴税交易操作，即3.6万次缴税交易操 作”，这里的TPS用交易数/小时来衡量；（4）在税务系统中，也可以用“系统在第七天的10点到11点之间要处理1.2万用户的3种缴税交易操作，即 3.6万次缴税交易操作，每次缴税交易要从客户端向服务器发送平均10次HTTP请求，即36万次HTTP请求操作”，这里的TPS用请求数/小时来衡 量。
HPS是用来衡量很多用户使用客户端进行操作，向服务器发送请求的效率。我们认为HPS表现的是最终用户的整体行为，是衡量在线负载程度的一个指标。而TPS表现的是服务器端的程序行为，是衡量服务器处理能力高低的一个主要指标。
例如：HPS＝“点击次数/秒”；TPS＝“处理事务数/秒”，HPS与TPS没有绝对的关系。

性能测试实现的准确性
在 进行了正确的性能测试分析后，获得了正确的性能测试需求，从而使用性能测试工具开发相应的性能测试脚本、开发相应的性能测试场景、在性能测试脚本中利用性 能测试数据、在性能测试脚本中设置相应的思考时间、在性能测试场景中设置运行的参数等，以期能利用自动化的性能测试工具模拟现实中大量用户同时访问被测系 统的情形。即，如果性能测试工具操作不当，将会导致无法准确的实现“模拟实际情况”的目标。例如，某些性能测试工程师在使用性能测试工具时不懂得利用“检 查点”这个功能，从而无法发现在性能测试执行过程中大量虚拟用户甚至没有登陆到系统中的严重问题，仍然认为性能测试执行效果良好，被测系统性能没有问题。

Web服务器和APP服务器
通 俗的讲，Web服务器传送(serves)页面使浏览器可以浏览，然而应用程序服务器提供的是客户端应用程序可以调用(call)的方法 (methods)。确切一点，你可以说：Web服务器专门处理HTTP请求(request)，但是应用程序服务器是通过很多协议来为应用程序提供 (serves)商业逻辑(business logic)。Web服务器(Web Server)Web服务器可以解析(handles)HTTP协议。当Web服务器接收到一个HTTP请求(request)，会返回一个HTTP响应 (response)，例如送回一个HTML页面。为了处理一个请求(request)，Web服务器可以响应(response)一个静态页面或图片， 进行页面跳转(redirect)，或者把动态响应(dynamic response)的产生委托(delegate)给一些其它的 程序例如CGI脚本，JSP(JavaServer Pages)脚本，servlets，ASP(Active Server Pages)脚本，服务器端(server-side)Javascrīpt，或者一些其它的服务器端(server-side)技术。无论它们(译者 注：脚本)的目的如何，这些服务器端(server-side)的程序通常产生一个HTML的响应(response)来让浏览器可以浏览。要知 道，Web服务器的代理模型(delegation model)非常简单。当一个请求(request)被送到Web服务器里来时，它只单纯的把请求(request)传递给可以很好的处理请求 (request)的程序(译者注：服务器端脚本)。Web服务器仅仅提供一个可以执行服务器端(server-side)程序和返回(程序所产生的)响 应(response)的环境，而不会超出职能范围。服务器端(server-side)程序通常具有事务处理(transaction processing)，数据库连接(database connectivity)和消息(messaging)等功能。虽然Web服务器不支持事务处理或数据库连接池，但它可以配置(employ)各种策略 (strategies)来实现容错性(fault tolerance)和可扩展性(scalability)，例如负载平衡(load balancing)，缓冲(caching)。集群特征(clustering—features)经常被误认为仅仅是应用程序服务器专有的特征。
应 用程序服务器(The Application Server)根据我们的定义，作为应用程序服务器，它通过各种协议，可以包括HTTP，把商业逻辑暴露给(expose)客户端应用程序。Web服务器 主要是处理向浏览器发送HTML以供浏览，而应用程序服务器提供访问商业逻辑的途径以供客户端应用程序使用。应用程序使用此商业逻辑就象你调用对象的一个 方法(或过程语言中的一个函数)一样。应用程序服务器的客户端(包含有图形用户界面(GUI)的)可能会运行在一台PC、一个Web服务器或者甚至是其它 的应用程序服务器上。在应用程序服务器与其客户端之间来回穿梭(traveling)的信息不仅仅局限于简单的显示标记。相反，这种信息就是程序逻辑 (program logic)。正是由于这种逻辑取得了(takes)数据和方法调用(calls)的形式而不是静态HTML，所以客户端才可以随心所欲的使用这种被暴露 的商业逻辑。在大多数情形下，应用程序服务器是通过组件(component)的应用程序接口(API)把商业逻辑暴露(expose)(给客户端应用程 序)的，例如基于J2EE(Java 2 Platform, Enterprise Edition)应用程序服务器的EJB(Enterprise JavaBean)组件模型。此外，应用程序服务器可以管理自己的资源，例如看大门的工作(gate-keeping duties)包括安全(security)，事务处理(transaction processing)，资源池(resource pooling)，和消息(messaging)。就象Web服务器一样，应用程序服务器配置了多种可扩展(scalability)和容错(fault tolerance)技术。 例如，设想一个在线商店(网站)提供实时定价(real-time pricing)和有效性(availability)信息。这个站点(site)很可能会提供一个表单(form)让你来选择产品。当你提交查询 (query)后，网站会进行查找(lookup)并把结果内嵌在HTML页面中返回。网站可以有很多种方式来实现这种功能。我要介绍一个不使用应用程序 服务器的情景和一个使用应用程序服务器的情景。观察一下这两中情景的不同会有助于你了解应用程序服务器的功能。
情景1：不带应用程序服务器的 Web服务器在此种情景下，一个Web服务器独立提供在线商店的功能。Web服务器获得你的请求(request)，然后发送给服务器端(server- side)可以处理请求(request)的程序。此程序从数据库或文本文件(flat file，译者注：flat file是指没有特殊格式的非二进制的文件，如properties和XML文件等)中查找定价信息。一旦找到，服务器端(server-side)程序 把结果信息表示成(formulate)HTML形式，最后Web服务器把会它发送到你的Web浏览器。简而言之，Web服务器只是简单的通过响应 (response)HTML页面来处理HTTP请求(request)。
情景2：带应用程序服务器的Web服务器情景2和情景1相同的是Web 服务器还是把响应(response)的产生委托(delegates)给脚本(译者注：服务器端(server-side)程序)。然而，你可以把查找 定价的商业逻辑(business logic)放到应用程序服务器上。由于这种变化，此脚本只是简单的调用应用程序服务器的查找服务(lookup service)，而不是已经知道如何查找数据然后表示为(formulate)一个响应(response)。这时当该脚本程序产生HTML响应 (response)时就可以使用该服务的返回结果了。在此情景中，应用程序服务器提供(serves)了用于查询产品的定价信息的商业逻辑。(服务器 的)这种功能(functionality)没有指出有关显示和客户端如何使用此信息的细节，相反客户端和应用程序服务器只是来回传送数据。当有客户端调 用应用程序服务器的查找服务(lookup service)时，此服务只是简单的查找并返回结果给客户端。通过从响应产生(response-generating)HTML的代码中分离出来，在 应用程序之中该定价(查找)逻辑的可重用性更强了。其他的 客户端，例如收款机，也可以调用同样的服务(service)来作为一个店员给客户结帐。相反，在情景1中的定价查找服务是不可重用的因为信息内嵌在 HTML页中了。总而言之，在情景2的模型中，在Web服务器通过回应HTML页面来处理HTTP请求(request)，而应用程序服务器则是通过处理 定价和有效性(availability)请求(request)来提供应用程序逻辑的。
警告(Caveats) 现在，XML Web Services已经使应用程序服务器和Web服务器的界线混淆了。通过传送一个XML有效载荷(payload)给服务器，Web服务器现在可以处理数 据和响应(response)的能力与以前的应用程序服务器同样多了。另外，现在大多数应用程序服务器也包含了Web服务器，这就意味着可以把Web服务 器当作是应用程序服务器的一个子集(subset)。虽然应用程序服务器包含了Web服务器的功能，但是开发者很少把应用程序服务器部署(deploy) 成这种功能(capacity)(译者注：这种功能是指既有应用程序服务器的功能又有Web服务器的功能)。相反，如果需要，他们通常会把Web服务器独 立配置，和应用程序服务器一前一后。这种功能的分离有助于提高性能(简单的Web请求(request)就不会影响应用程序服务器了)，分开配置(专门的 Web服务器，集群(clustering)等等)，而且给最佳产品的选取留有余地。

性能瓶颈
性能瓶颈实际上就是一个软件的性能缺陷，最通俗的理解“性能瓶颈”。
（1）硬件上的性能瓶颈主要指的是CPU、RAM方面的问题。例如，在进行软件需求分析、概要设计时，确定了在数据库服务器上需要6个CPU、12G内存，但是在测试时，发现CPU的持续利用率超过95%，这时可以认为在硬件上出现了性能瓶颈。
（2） 应用软件上的性能瓶颈一般指的是应用服务器、WEB服务器等应用软件，还包括数据库系统。例如，在WEBLogic平台上配置了JDBC连接池的参数，最 大连接数为50，最小连接数为5，增加量为10。在测试时发现，当负载增加时，现有的连接数不足，系统会动态生成10个新的连接数，这样导致了交易处理的 响应时间大大的增加。这时可以认为在应用软件上出现了性能瓶颈。
（3）应用程序上的性能瓶颈，一般指的是开发人员新开发出来的应用程序。例如，用 Java或者C开发出来的部署在应用服务器上用于用户交易请求处理的应用程序。例如，某个开发员开发了一个缴费处理程序，在测试时发现，这个缴费处理程序 在处理用户发过来的并发缴费请求时，只能串行处理，无法并行处理，导致缴费交易的处理响应时间非常长，这时可以认为在应用程序上出现了性能瓶颈。
（4）操作系统上的性能瓶颈，一般指的是Windows、Unix、Linux这些操作系统。例如，在windows系统中，虚拟内存设置的不合理，都指定为C驱提供虚拟内存，在测试时发现当出现物理内存不足时，虚拟内存的交换效果非常不理想，导致交易的响应时间大大增加。这时可以认为在操作系统上出现了性能瓶颈。
（5） 网络设备上的性能瓶颈，一般指的是防火墙、动态负载均衡器、交换机等设备。例如，在动态负载均衡器上设置了动态分发负载的机制，当发现某个应用服务器上的 硬件资源已经到达极限时，动态负载均衡器将后续的交易请求发送到其它负载较轻的应用服务器上。在测试时发现，动态负载均衡机制没有起到相应的作用，这时可 以认为在网络设备上出现了性能瓶颈。

1．  在controller和Vuser的LAN中的防火墙都打开54345端口即可。

2．   另外就是使用MI Listener，Controller的机器上使用MI Listener或者是和Controller在同一个内网上的机器上安装和配置MI Listener ，防火墙打开TCP/IP 或者HTTPS 的443端口。防火墙另一端的压力负载机上需要启用防火墙代理, 这样互相之间应该就可以通信了，另外如果需要通过防火墙监控资源的话，还需要在防火墙内的计算机上安装穿越防火墙进行监控的组件(包括loadrunner agent process)。具体请参考附件文档的8个步骤。

loadrunner函数 lr_save_datetime

上一篇 / 下一篇  2007-07-06 14:00:19

转贴蓝宇伊人的个人空间

性能瓶颈实际上就是一个软件的性能缺陷

  那我们如何最通俗的理解“性能瓶颈”

  （1）硬件上的性能瓶颈

      主要指的是CPU、RAM方面的问题。

      例如，

      在进行软件需求分析、概要设计时，确定了在数据库服务器上需要6个CPU、12G内存，

      但是在测试时，发现CPU的持续利用率超过95%，

      这时可以认为在硬件上出现了性能瓶颈。

  （2）应用软件上的性能瓶颈

      一般指的是应用服务器、WEB服务器等应用软件，还包括数据库系统。

      例如，

      在WEBLogic平台上配置了JDBC连接池的参数，最大连接数为50，最小连接数为5，增加量为10。

      在测试时发现，当负载增加时，现有的连接数不足，系统会动态生成10个新的连接数，这样导致了交易处理的响应时间大大的增加。

      这时可以认为在应用软件上出现了性能瓶颈。

  （3）应用程序上的性能瓶颈

    一般指的是开发人员新开发出来的应用程序。

    例如，

      用Java或者C开发出来的部署在应用服务器上用于用户交易请求处理的应用程序。

    例如，

      某个开发员开发了一个缴费处理程序，在测试时发现，

      这个缴费处理程序在处理用户发过来的并发缴费请求时，

      只能串行处理，无法并行处理，

      导致缴费交易的处理响应时间非常长，

      这时可以认为在应用程序上出现了性能瓶颈。

  （4）操作系统上的性能瓶颈

      一般指的是Windows、Unix、Linux这些操作系统。

      例如，

        在windows系统中，虚拟内存设置的不合理，

        都指定为C驱提供虚拟内存，

        在测试时发现当出现物理内存不足时，

        虚拟内存的交换效果非常不理想，

        导致交易的响应时间大大增加。

        这时可以认为在操作系统上出现了性能瓶颈。

  （5）网络设备上的性能瓶颈

      一般指的是防火墙、动态负载均衡器、交换机等设备。

      例如，

        在动态负载均衡器上设置了动态分发负载的机制，

        当发现某个应用服务器上的硬件资源已经到达极限时，

        动态负载均衡器将后续的交易请求发送到其它负载较轻的应用服务器上。

        在测试时发现，动态负载均衡机制没有起到相应的作用，

        这时可以认为在网络设备上出现了性能瓶颈。

LoadRunner常用函数

转贴蓝宇伊人的个人空间

 1.   Int web_reg_save_param("参数名","LB=左边界","RB=右边界",LAST);/注册函数，在参数值出现的前面使用，注册成功时返回值为0，注册失败时返回值为1。左右边界需根据TreeView里相关步骤的SeverResponse代码来确定。用以上函数能获取第一个符合条件的数值。
2.         web_reg_save_param("参数名”,"LB=左边界”,"RB=右边界","Ord=All",LAST);/当参数有多个值时，加上"Ord=All”后可获取所有的数值。注册成功后，{参数名_count}表示取得的数值个数，{参数名_1}为第一个数值，{参数名_2}为第二个数值。
3.         lr_save_string(“字符串变量”,"参数名")/将字符变量里的值传递给指定参数。通过该函数来改变DataFile类型参数的数值。
4.         lr_eval_string("{参数名}")/取得参数的数值。可取得已注册参数或DataFile类型参数的数值。eval就是evaluation（估价, 评价, 赋值）的缩写。
5.         int sprintf(char * string , const char*format_string[,args]);/字符串赋值函数
Action()
{
int index=56;
charfilename[64],*suffix="txt";
sprintf(filename,"log_%d.%s",index,suffix);
lr_output_message("Thenewfilenameis%s",filename);
return 0;
}
Output：Thenewfilenameislog_56.txt
6.         char*strcat(char*to,constchar*from);/将一字符串追加到另一字符串后面
7.         web_find("find_time","What=2006-03-0118:21:16.882",LAST);/增加检查点,检查 “2006-03-0118:21:16.882”这个字符串是否出现在当前页面上。find_time为自己任意输入的检查点名称。
8.       事务函数
lr_end_sub_transaction/标记子事务的结束以便进行性能分析
lr_end_transaction/标记LoadRunner事务的结束
lr_end_transaction_instance/标记事务实例的结束以便进行性能分析
lr_fail_trans_with_error/将打开事务的状态设置为LR_FAIL并发送错误消息
lr_get_trans_instance_duration/获取事务实例的持续时间（由它的句柄指定）
lr_get_trans_instance_wasted_time/获取事务实例浪费的时间（由它的句柄指定）
lr_get_transaction_duration/获取事务的持续时间（按事务的名称）
lr_get_transaction_think_time/获取事务的思考时间（按事务的名称）
lr_get_transaction_wasted_time/获取事务浪费的时间（按事务的名称）
lr_resume_transaction/继续收集事务数据以便进行性能分析
lr_resume_transaction_instance/继续收集事务实例数据以便进行性能分析
lr_set_transaction_instance_status/设置事务实例的状态
lr_set_transaction_status/设置打开事务的状态
lr_set_transaction_status_by_name/设置事务的状态
lr_start_sub_transaction/标记子事务的开始
lr_start_transaction/标记事务的开始
lr_start_transaction_instance/启动嵌套事务（由它的父事务的句柄指定）
lr_stop_transaction/停止事务数据的收集
lr_stop_transaction_instance/停止事务（由它的句柄指定）数据的收集
lr_wasted_time/消除所有打开事务浪费的时间
lr_end_sub_transaction/标记子事务的结束以便进行性能分析
r_end_transaction/标记LoadRunner事务的结束
lr_end_transaction_instance/标记事务实例的结束以便进行性能分析
lr_fail_trans_with_error/将打开事务的状态设置为LR_FAIL并

9.      命令行分析函数
lr_get_attrib_double/检索脚本命令行中使用的double类型变量
lr_get_attrib_long/检索脚本命令行中使用的long类型变量
lr_get_attrib_string/检索脚本命令行中使用的字符串
10.  信息性函数
lr_user_data_point/记录用户定义的数据示例
lr_whoami/将有关Vuser脚本的信息返回给Vuser脚本
lr_get_host_name/返回执行Vuser脚本的主机名
lr_get_master_host_name/返回运行LoadRunnerController的计算机名
11.  字符串函数
lr_eval_string/用参数的当前值替换参数
lr_save_string/将以NULL结尾的字符串保存到参数中
lr_save_var/将变长字符串保存到参数中
lr_save_datetime/将当前日期和时间保存到参数中
lr_advance_param/前进到下一个可用参数
lr_decrypt/解密已编码的字符串
lr_eval_string_ext/检索指向包含参数数据的缓冲区的指针
lr_eval_string_ext_free/释放由lr_eval_string_ext分配的指针
lr_save_searched_string/在缓冲区中搜索字符串实例，并相对于该字符串实例，该缓冲区的一部分保存到参数中
12.  消息函数
lr_debug_message/将调试消息发送到输出窗口
lr_error_message/将错误消息发送到输出窗口
lr_get_debug_message/检索当前的消息类
lr_log_message/将输出消息直接发送到output.txt文件，此文件位于Vuser脚本目录中。该函数有助于防止输出消息干扰TCP/IP通信。
lr_output_message/将消息发送到输出窗口
lr_set_debug_message/为输出消息设置消息类
lr_vuser_status_message/生成格式化输出并将其打印到ControllerVuser状态区域。
lr_message/将消息发送到Vuser日志和输出窗口
13.  操作函数
web_custom_request允许您使用HTTP支持的任何方法来创建自定义HTTP请求
web_image在定义的图像上模拟鼠标单击
web_link在定义的文本链接上模拟鼠标单击
web_submit_data执行“无条件”或“无上下文”的表单
web_submit_form模拟表单的提交
web_url加载由“URL”属性指定的URL
14.  身份验证函数
身份验证函数web_set_certificate使Vuser使用在InternetExplorer注册表中列出的特定证书
身份验证函数web_set_certificate_ex指定证书和密钥文件的位置和格式信息
身份验证函数web_set_user指定Web服务器的登录字符串和密码，用于Web服务器上已验证用户身份的区域
15.  缓存函数
缓存函数web_cache_cleanup清除缓存模拟程序的内容
16.  检查函数
检查函数web_find在HTML页内搜索指定的文本字符串
检查函数web_global_verification在所有后面的HTTP请求中搜索文本字符串
检查函数web_image_check验证指定的图像是否存在于HTML页内
检查函数web_reg_find在后面的HTTP请求中注册对HTML源或原始缓冲区中文本字符串的搜索
17.  连接定义函数
连接定义函数web_disable_keep_alive禁用Keep-AliveHTTP连接
连接定义函数web_enable_keep_alive启用Keep-AliveHTTP连接
连接定义函数web_set_connections_limit设置Vuser在运行脚本时可以同时打开连接的最大数目
18.  并发组
web_concurrent_end标记并发组的结束
web_concurrent_start标记并发组的开始
19.  cook函数
web_add_cookie添加新的Cookie或修改现有的Cookie
web_cleanup_cookies删除当前由Vuser存储的所有Cookie
web_remove_cookie删除指定的Cookie
20.  关联函数
web_create_html_param将HTML页上的动态信息保存到参数中。（LR6.5及更低版本）
web_create_html_param_ex基于包含在HTML页内的动态信息创建参数（使用嵌入边界）

初次体验LR8.1卸载+LR9.0安装（超有成就感，吼吼）

上一篇 / 下一篇  2008-08-28 16:23:20 / 天气: 晴朗 / 心情: 高兴 / 精华(1) / 置顶(1) / 个人分类：性能测试

性能测试（并发负载压力）测试分析－简要篇