学习各种高级外挂制作技术，马上去百度搜索（魔鬼作坊），点击第一个站进入，快速成为 做挂达人。 手柄边距 显示前延时 自动停留时间 淡入时间 淡出时间 边线 边线颜色 水平边线宽度 垂直边线宽度 阴影 阴影是否渐变 阴影灰度 阴影水平偏移量 阴影垂直偏移量 阴影水平深度 阴影垂直深度 自定义超链接被单击 提示框即将弹出 提示框即将隐藏 简单超文本框 超文本 扩展界面支持库三 卷帘式菜单 加入菜单 删除菜单 取菜单数 取菜单名称 取项目名称 置菜单名称 置项目名称 取菜单数值 置菜单数值 取项目图片 置项目图片 加入组件菜单 置菜单图标 取菜单图标 置菜单底图 取菜单底图 菜单是否已禁止 禁止菜单 项目是否已禁止 禁止项目 菜单是否已隐藏 隐藏菜单 项目是否已隐藏 隐藏项目 取菜单提示文本 置菜单提示文本 取项目提示文本 置项目提示文本 项目图标图片组 项目列表图片组 排列方式 现行选中菜单 现行选中项目 菜单底色 菜单下按色 菜单悬停色 菜单选中色 菜单文本色 菜单下按文本色 菜单悬停文本色 菜单选中文本色 项目文本色 项目悬停文本色 项目选中文本色 亮边框色 暗边框色 菜单字体 项目字体 菜单高度 菜单滚动速度 闪烁选中项目 菜单图标图片组 菜单背景图片组 显示菜单文本 显示菜单图标 菜单被改变 项目名称被改变 菜单名称被改变 菜单被单击 菜单被右击 项目被右击 项目被双击 高级选择夹 加入子夹 删除子夹 取子夹图标 置子夹图标 取子夹数值 置子夹数值 取子夹头底色 置子夹头底色 取子夹头底图 置子夹头底图 取子夹提示文本 置子夹提示文本 取子夹头区域 禁止子夹 子夹是否被禁止 隐藏子夹 子夹是否被隐藏 隐藏表头 子夹头高度 界面风格 表头样式 标题对齐方式 背景图片组 滚动按钮图片组 表头底色渐变 正常表头底色 点燃表头底色 选中表头底色 页面底色 正常标题颜色 点燃标题颜色 选中标题颜色 竖排子夹名称 显示隐藏子夹 启用禁止子夹 指定渐变起始色 正常渐变起始色 点燃渐变起始色 选中渐变起始色 页面区左边 页面区顶边 页面区宽度 页面区高度 子夹头被单击 子夹头被点燃 子夹头被右击 扩展界面支持库六 多功能条 允许用户调节 自动背景高度 两端 显示两端按钮 两端按钮图片组 后台 后台图片组 后台图片显示方式 显示后台两端 显示后台中间 缩进后台两端 前台 显示前台 前台图片组 前台图片显示方式 显示前台两端 显示前台中间 中台 显示中台 中台图片组 中台图片显示方式 显示中台两端 显示中台中间 自动伸缩中台 左按钮被单击 右按钮被单击 扩展界面支持库二 文档格式转换 转换文档 到纯文本 图片组处理 加入图片 合并图片组 提取加入图片 取文件内图标数 删除图片组图片 取图片组图片数 建空图片组 取图片组图片 超级按钮 按钮风格 选择框方式 压入方式 绘制边框 绘制焦点 通常图片 通常图片透明色 点燃图片透明色 禁止图片透明色 使用默认色 通常前景色 通常背景色 点燃前景色 点燃背景色 焦点前景色 焦点背景色 标准音提示 经过提示音 单击提示音 默认类型 高级影像框 播放位置 影像文件名 播放速度 仅播放一次 当前帧 全部帧数 被拖动 字符格式 纵向偏移 段落格式 项目符引导 首行缩进 非首行缩进 右边缩进 超级编辑框 取行文本 取首可视行 取行首位置 取字符所在行 滚动 取默认字符格式 置默认字符格式 取选择区字符格式 置选择区字符格式 取选择区段落格式 置选择区段落格式 撤消 可否撤消 清空撤消数据 寻找 可否粘贴 读入文档 自动换行 是否已更改 选择区被改变 地址被改变 动画框 创建物体 销毁物体 销毁所有物体 取物体数 取标识值 是否存在 置亮度 取亮度 趋向色变换 置层次 取层次 是否已显示 置附加文本 取附加文本 置物体位置 取物体左边 取物体顶边 取物体宽度 取物体高度 置碰撞管理 置销毁声音 置角度 取角度 转向 置旋转跟随 取旋转跟随 缩放 取横向缩放比 取纵向缩放比 自动前进 停止自动前进 自动旋转 停止自动旋转 自动方向键移动 定位物体 是否重叠 寻找重叠物体 边界检查

• 对场景进行设计后，接着需要对负载生成器进行管理和设置。Load Generator是运行脚本的负载引擎，在默认情况下使用本地的负载生成器来运行脚本，但是模拟用户行为也需要消耗一定的系统资源，所以在一台电脑上无法模拟大量的虚拟用户，这个时候可以通过多个Load Generator来完成大规模的性能负载;

  1、添加负载机器之前需要开启代理运行时设置；

  注意：默认选第一项后，在这里点击OK，可能开启不了小雷达，目前在我们实际的工作中已经出现了这样的问题，后来我们找到了解决的方法。开启不了小雷达，我们选择第二项，点击OK，发现会报运行时错误，报错后我们点击报错中的退出，然后进入开始-所有程序-LoadRunner-Advanced Settings,找到Agent Configuration，点击后弹出如下界面，我们勾选第二项后，点击OK，发现小雷达出现了。

  2、设置完成后添加负载机器：

  　　● “New Rule”：在该应用下新建规则，规则中包含字符串或者字符前缀和后缀。

  　　● “Set as Default”：默认情况下，当前所作的更改只适用于当前的脚本，如果想让更改适用于本机所有脚本的话，单击该按钮即可。

  　　● “Import/Export”：利用该按钮可以把定义好的规则导入和导出。

  　　其他的标签设置采用默认值即可，这里不再详细地介绍。

• 1. 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）

  
  2. 查找瓶颈时按以下顺序，由易到难。

  
  服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器瓶颈（参数配置）-〉中间件瓶颈（参数配置，，服务器等）-〉应用瓶颈（语句、数据库设计、业务逻辑、算法等）
      注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。

  
  3 分段排除法 很有效分析的信息来源：
  1 根据场景运行过程中的错误提示信息
  2 根据测试结果收集到的监控指标数据

  1．最大并发用户数：应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。
  在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
      如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

  
  2．业务操作响应时间：
       分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。
      细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？
    如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题

  3．服务器资源监控指标：

  1 UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。
  bytes计数器的值持续降低，则很可能存在内存泄漏。内存资源成为系统性能的瓶颈的征兆:很高的换页率(high pageout rate);进程进入不活动状态;交换区所有磁盘的活动次数可高;可高的全局系统CPU利用率; 内存不够出错(out

  utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL

  
  1 SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。
  Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。 
  3 Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。
  4 Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。

   性能测试的结果分析是性能测试的重中之重。在实际工作中，由于测试的结果分析比较复

  杂、需要具备很多相关的专业知识，因此常常会感觉拿到数据不知从何下手。这也是我性能

  测试过程中感觉比较尴尬和棘手的事，为此我在研读了《WEB性能测试实战》后特作了以下笔

  记，这里只是书中第4章WEB应用程序性能分析的一

  部分，贴出来希望和大家共同讨论：

  一：性能分析的基础知识：

  1.几个重要的性能指标：相应时间、吞吐量、吞吐率、TPS（每秒钟处理的交易数）、点

  2.系统的瓶颈分为两类：网络的和服务器的。服务器瓶颈主要涉及：应用程序、WEB服务

  器、数据库服务器、操作系统四个方面。

  3.常规、粗略的性能分析方法：

     当增大系统的压力（或增加并发用户数）时，吞吐率和TPS的变化曲线呈大体一致，则系统

  基本稳定；若压力增大时，吞吐率的曲线增加到一定程度后出现变化缓慢，甚至平坦，很可能是

  网络出现带宽瓶颈，同理若点击率/TPS曲线出现变化缓慢或者平坦，说明服务器开始出现颈。

  4.作者提出了如下的性能分析基本原则，此原则本人十分赞同：

      应用此原则，分析步骤具体可以分为以下三步：

     第一步：将得到的响应时间和用户对性能的期望值比较确定是否存在瓶颈；

     第二步：比较Tn（网络响应时间）和Ts（服务器响应时间）可以确定瓶颈发生在网络还是服

     第三步：进一步分析，确定更细组件的响应时间，直到找出发生性能瓶颈的根本原因。

  二：以WEB应用程序为例来看下具体的分析方法：

  失败。通过分析成功与失败的数据可以直接判断出系统是否运行正常。若失败的事务非常多，则

  说明系统发生了瓶颈或者程序在执行过程中发生了问题。

  测试场景运行期间的每一秒内事务执行所用的平均时间，还显示了测试场景运行时间内各个事务

  的最大值、最小值和平均值。通过它可以分析系统的性能走向。若所有事务响应时间基本成一条

  曲线，则说明系统性能基本稳定；否则如果平均事务响应时间逐渐变慢，说明性能有下降趋势，

  造成性能下降的原因有可能是由于内存泄漏导致。

  秒中，每个事 务通过、失败以及停止的数量。通过它可以确定系统在任何给定时刻的实际事务

  负载。若随着测试的进展，应用系统在单位时间内通过的事务数目在减少，则说明服务器出现瓶

  每一秒中，通过、失败以及停止的事务总数。若在同等压力下，曲线接近直线，则性能基本趋于

  稳定；若在单位时间内通过的事务总量越来越少，即整体性能下降。原因可能是内存泄漏或者程

  最小、最大平均执行时间，可以直接判断响应时间是否符合客户要求（重点关注事务平均、最大

  该图可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性

  图是根据测试结果进行分析而得到的综合分析图。分析该图应从整体出发，若可能事务的最大响

  应时间很长，但如果大多数事务具有可接受的响应时间，则系统的性能是符合。

  图显示了测试过程中不同响应时间的事务数量。若系统预先定义了相关事务可以接受的最小和最

  大事务响应时间，则可以使用此图确定系统性能是否在接受范围内。

        分析到这一步，只能大概判断出瓶颈可能会出在那，要具体定位瓶颈还需要更深入

  的分析。没有贴图，看起来有点费劲，如果你对这些图都比较了解，应该是比较简单的.

• 1,把rstatd文件解压到要监控的机器上。

  2,打开终端，定位到rstatd文件夹下：查看文件夹中的内容如下：

  这之后可以执行:make check检查一下。

  命令。启动rpc服务。

  命令。检查rpc服务的状态.

  1,若RPC服务没有成功启动。

  2,若目标主机上开启了防火墙，阻挡了RPC服务。

  在LR中添加时可能会出现如下错误：

• 首先，telnet以root用户的身份登录入系统，在命令行提示符下输入：

  进入编辑文件页面后，输入：

  （命令解释：在打开的文档中查找“rstatd”）接下来继续输入：

  （命令解释：删除当前字符，在这里为删除rstatd命令前的“#”）继续输入：

  （命令解释：保存并退出，注意前面有个冒号）

  
  接着在命令提示符下输入：

  （命令解释：重新启动服务）

  这样使用loadrunner就可以监视AIX系统的性能情况了。

• 在 LoadRunner 的运行场景中，有一个不大起眼的设置，可能经常会被很多人忽略，它就是 Pacing 。具体设置方式为： Run-Time settings à General à Pacing ，这个设置的功能从字面上就很容易理解，即在场景的两次迭代 (iteration) 之间，加入一个时间间隔（步进）。设置方法也很简单，这里就不赘述了，我在这里想说明的是，这个设置到底有什么作用？为什么要进行这个设置？说实话，虽然我在以前做过的一些性能测试中，偶尔会对这个步进值进行一些设置，但其实对它的真正含义和作用，我还并不十分清楚。  
  　　前段时间，我在对X银行招聘信息系统进行性能测试的时候，发现这个值的设置对于测试的结果有着很大的影响，很遗憾当时没有深入研究这个问题，而只是简单地认为它同脚本中的 thinktime 一样只是为了更真实地模拟实际情况而已。最近在网络上看到一篇题为《调整压力测试工具》的文章，读完之后，再用之前我的测试经历加以印证，真有种豁然开朗的感觉。以下就将我的一些体会与大家分享：  
  　　通常我们在谈到一个软件的“性能”的时候，首先想到的就是“响应时间”和“并发用户数”这两个概念。我们看到的性能需求经常都是这样定义的：  
  　　看到这样的性能需求，我们往往会不假思索地就在测试场景中设置 100 个用户，让它们同时执行某一个测试脚本，然后观察其操作的响应时间，我们都是这样做的，不是吗？我在实际实施性能测试的过程中，也往往都是这样做的。可惜的是，我们中的大多数人很少去更深入地思考一下其中的奥妙，包括我自己。  
  　　事实上，评价一个软件系统的性能，可以从两个不同的视角去看待：客户端视角和服务器视角（也有人把它叫做用户视角和系统视角），与此相对应的，又可以引出两个让初学者很容易混淆的两个概念：“并发用户数”和“每秒请求数”。“并发用户数”是从客户端视角去定义的，而“每秒请求数”则是从服务器视角去定义的。  
  　　因此，上面所描述的做法的局限性就是，它反映的仅仅是客户端的视角，中国自学编程网， 。  
  　　对于这个世界上的很多事情，变换不同的角度去看它，往往可以有助于我们得到更正确的结论。现在，我们就转换一下角度，以服务器的视角来看看性能需求应该怎么样定义： “要求系统的事务处理能力达到 100 个 / 秒” ( 这里为了理解的方便，假定在测试脚本中的一个事务仅仅包含一次请求 )  
  　　面对以这样方式提出的性能需求，在 LoadRunner 中，我们又该如何去设置它的并发用户数呢？千万不要想当然地以为设置了 100 个并发用户数，它就会每秒向服务器提交 100 个请求，这是两个不同的概念，因为 LoadRunner 模拟客户端向服务器发出请求，必须等待服务器对这个请求做出响应，并且客户端收到这个响应之后，才会重新发出新的请求，而服务器对请求的处理是需要一个时间的。我们换个说法，对于每个虚拟用户来说，它对服务器发出请求的频率将依赖于服务器对这个请求的处理时间。而服务器对请求的处理时间是不可控的，如果我们想要在测试过程中维持一个稳定的每秒请求数（ RPS ），只有一个方法，那就是通过增加并发用户数的数量来达到这个目的。这个方法看起来似乎没有什么问题，如果我们在测试场景中只执行一次迭代的话。然而有经验的朋友都会知道，实际情况并不是这样，我们通常会对场景设置一个持续运行时间（即多次迭代），通过多个事务 (transaction) 的取样平均值来保证测试结果的准确性。测试场景以迭代的方式进行，如果不设置步进值的话，那么对于每个虚拟用户来说，每一个发到服务器的请求得到响应之后，会马上发送下一次请求。同时，我们知道， LoadRunner 是以客户端的角度来定义“响应时间”的 ，当客户端请求发出去后， LoadRunner 就开始计算响应时间，一直到它收到服务器端的响应。这个时候问题就产生了：如果此时的服务器端的排队队列已满，服务器资源正处于忙碌的状态，那么该请求会驻留在服务器的线程中，换句话说，这个新产生的请求并不会对服务器端产生真正的负载，但很遗憾的是，该请求的计时器已经启动了，因此我们很容易就可以预见到，这个请求的响应时间会变得很长，甚至可能长到使得该请求由于超时而失败。等到测试结束后，我们查看一下结果，就会发现这样一个很不幸的现象：事务平均响应时间很长，最小响应时间与最大响应时间的差距很大，而这个时候的平均响应时间，其实也就失去了它应有的意义。也就是说，由于客户端发送的请求太快而导致影响了实际的测量结果。  　　因此，为了解决这个问题，我们可以在每两个请求之间插入一个间隔时间，这将会降低单个用户启动请求的速度。间歇会减少请求在线程中驻留的时间，从而提供更符合现实的响应时间。这就是我在文章开头所提到的 Pacing 这个值的作用。  
  　　最后再补充一句话：虽然性能测试通常都是从客户端活动的角度定义的，但是它们应该以服务器为中心的视角来看待。请注意这句话，理解它很重要，只有真正理解了这句话，你才会明白为什么我们一直强调做性能测试的时候要保证一个独立、干净的测试环境，以及一个稳定的网络，因为我们希望评价的是软件系统真正的性能，所以必须排除其它一切因素对系统性能造成的影响。

• 如何在Loadrunner中监控服务器资源使用情况

  一．监控需要进行的配置：

  在LR控制台设置监控Windows服务器的资源比较容易，直接添加Measurements即可。

  但是大多情况下面服务器的操作系统是Linux或者Unix，这时想监控系统的资源使用情况就需要进行一些设置：

  1．由于LR是通过rpc.rstatd进程获得系统的性能数据，因此首先查看进程中是否存在该进程，或者能否通过运行./rpc.rstatd启动该进程，如果可以，恭喜你，你可以直接在LR的控制台添加

  理论上info为7个进程（前面共有两次start），如果各位有

  兴趣可以自己使用rpcinfo来查看前后的服务对比。

  关于之上的那段Shell程序，偶还灭有研究过。待研究过以后，在放上来与大家一起分享。

  本帖后上传了两个中间文件分别为：

  Average Load:上一分钟同时处于“就绪”状态的平均进程数

  Page-in Rate:每秒钟读入到物理内存中的页数

  Page-out Rate:每秒钟写入页面文件和从物理内存中删除的页数

  Paging Rate:每秒钟读入物理内存或写入页面文件中的页数

  Memory:内存使用情况可能是系统性能中最重要的因素。如果系统“页交换”频繁，说明内存不足。“页交换”是使用称为“页面”的单位，将固定大小的代码和数据块从 RAM 移动到磁盘的过程，其目的是为了释放内存空间。尽管某些页交换使 Windows 2000 能够使用比实际更多的内存，也是可以接受的，但频繁的页交换将降低系统性能。减少页交换将显著提高系统响应速度。要监视内存不足的状况，请从以下的对象计数器开始： 
  MB 或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。

  
  page/sec: 表明由于硬件页面错误而从磁盘取出的页面数，或由于页面错误而写入磁盘以释放工作集空间的页面数。一般如果pages/sec持续高于几百，那么您应该进一步研究页交换活动。有可能需要增加内存，以减少换页的需求（你可以把这个数字乘以4k就得到由此引起的硬盘数据流量）。Pages/sec 的值很大不一定表明内存有问题，而可能是运行使用内存映射文件的程序所致。

  Pages/sec 计数器的值增大数倍。如果这些计数器的计数结果超过了 0.1，那么页交换将花费百分之十以上的磁盘访问时间。如果长时间发生这种情况，那么您可能需要更多的内存。

  
  Page Faults/sec:每秒软性页面失效的数目（包括有些可以直接在内存中满足而有些需要从硬盘读取）较page/sec只表明数据不能在内存的指定工作集中立即使用。 
  

  
  Pages per second :每秒钟检索的页数。该数字应少于每秒一页。

  Page Faults/sec:将进程产生的页故障与系统产生的相比较，以判断这个进程对系统页故障产生的影响。 
  Work set: 处理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。 
  Inetinfo:Private Bytes:此进程所分配的无法与其它进程共享的当前字节数量。如果系统性能随着时间而降低，则此计数器可以是内存泄漏的最佳指示器。

  Processor：监视“处理器”和“系统”对象计数器可以提供关于处理器使用的有价值的信息，帮助您决定是否存在瓶颈。 
  %Processor Time:如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。 
  %User Time:表示耗费CPU的数据库操作，如排序，执行aggregate functions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。 
  %Privileged Time：（CPU内核时间）是在特权模式下处理线程执行代码所花时间的百分比。如果该参数值和"Physical Length 计数器会显示出处理器瓶颈。队列长度持续大于 4 则表示可能出现处理器拥塞。此计数器是特定时间的值，而不是一段时间的平均值。 
  % DPC Time:越低越好。在多处理器系统中，如果这个值大于50%并且Processor:% Processor Time非常高，加入一个网卡可能会提高性能，提供的网络已经不饱和。

  (实例化inetinfo 和dllhost 进程) 如果你决定要增加线程字节池的大小，你应该监视这三个计数器（包括上面的一个）。增加线程数可能会增加上下文切换次数，这样性能不会上升反而会下降。如果十个实例的上下文切换值非常高，就应该减小线程字节池的大小。

  %Disk Time %:指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大，那么硬盘不是瓶颈。如果只有%Disk Time比较大，另外两个都比较适中，硬盘可能会是瓶颈。在记录该计数器之前，请在Windows Length:指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。该值应不超过磁盘数的1.5~2 倍。要提高性能，可增加磁盘。注意：一个Raid Disk实际有多个磁盘

• 说一下oracle的性能测试。 oracle的性能测试主要是模拟大量的sql语句操作，来对数据库服务器进行加压。在测试前，需要准备以下要模拟的sql语句，测试脚本，并将测试控制机、测试加压机、被测数据库服务器准备妥当。

  将脚本放在控制机上，就可以开始加压了，注意的是，被测数据库服务器的各个参数配置要记录下来，以便修改参数调优时能分析清晰。记录下数据库的iops，time，tps和响应时间，结果汇总出报告。

• 　　一段对于loadrunner协议选择的经典解答协议是数据在网络中传输的结构模式。协议不同，其数据报文的结构也有所不同。协议是有层次的，一般我们从ip层开始，往上有TCP协议层，UDP协议层，而TCP和UDP协议层上又有http协议层，ftp协议层，smtp协议层等我们在lr中看到的这些应用层的协议。其实这些高层协议都是对底层协议进行的进一步封装。举个简单例子，本来IP协议的数据报文是无序，不是可靠传输的，在其数据报文外面增加了报文序号，报文状态等数据段就构成了TCP协议层。所以我们很多网络应用，没有找到合适的协议，就用winsock来录制，那是肯定没有问题的。因为几乎所有的网络传输中都是基于tcp 协议或udp协议的，而socket正是这一级上的概念。但是由于socket协议级别太低，你录下来的东西是很难理解的，都是 socket，port，data之类的东西。所以，我们尽量用高层协议来录制，我们就能看懂了。

  　　话要再说回来，解决一下具体的问题。我们看到一个软件体系架构，应该怎样选择录制协议呢？说到这里，我要说一下自己对lr录制机理的理解（我没有接触过lr内核，只是凭猜测和推断）。在录制时，lr应该会对你从本机发出去的数据进行截包，并拆包。因为我们知道协议的不同就是体现在数据包的结构不同，lr应该通过对包结构的分析，判断是不是它支持的协议，对包数据的分析，来获取用户发送的东西。比如你用ftp的协议去录制一个访问网页的IE操作，那肯定是无所收获的。因为lr没有在网络截获到 ftp协议格式的包，都是http协议格式的包，它不认，当然就是一个录制为空的结果了。现在我们弄懂了这个事情，就知道该如何选择协议了。看见很多人关心lr是不是支持mysql协议。我认为要寻找的答案的思路是这样的：

  　　1、首先弄清mysql协议和其他数据库协议的关系，看能不能用其它数据库协议录制。但其实oracle的cs协议是oracle独有自己开发的协议，sqlserver也是一样，而mysql又与这几大产品又不是隶属关系，其脚本录制的可能性很小。

  　　2、mysql协议的底层是基于什么协议的，如果直接构建在tcp协议上，lr又不支持mysql协议，那只能考虑用低一点的协议录录看，即socket。如果mysql协议是构建在odbc协议上的，那么就可能用lr的odbc api来写。

  　　很多时候一提到不是基于浏览器的应用，很多人就会想到用WinSocket协议来录制，仿佛Form窗体都可以用Winsocket 。从道理上讲网络通讯的底层都是基于Socket的，例如TCP、UPD等，似乎所有的程序都可以用Socket协议来录制。但是事实不是这样的，因为选择的协议决定了LoadRunner如何捕获数据包。否则会多捕获很多无用的数据。因此，不是所有的程序都是适合WinSocket协议的。实际上，那些基于Socket开发的应用才真正适合Socket协议来进行录制。其他的，例如基于数据库的应用，就不太时候Socket协议，甚至可能录制不到脚本。很多C/S程序，一定要选择合适的协议。根据作者的经验，C/S的程序多数需要手工开发很多脚本，因为录制的很多回放时候或多或少都会有些问题，但是可以参考录制的结果。所以测试一个程序，一定要搞清楚开发人员用了什么技术、数据流是什么协议封装的。理论上来说我们在对一个系统做性能测试以前，要先和开发人员了解一下他们在开发过程中都用了些什么技术，数据流是用什么协议封装的，还要了解我们要测试的系统的网络结构，服务器的配置等问题；还有就是要知道系统客户端和第一服务器间的协议，这中间就涉及到一个中间件的问题。另外我们要知道协议的选择直接关系到LR会捕获到什么样的数据包。这些是进行性能测试的基础。 下面说几个测试的原则（都是自己遇到过的，呵呵，没遇到过的就不知道了）：

  　　1、一般情况下b/s构架的只要 选择WEB（Http/Html)协议就可以了，如果有中间件的则选择中间件服务器的协议 ；

  　　2、C/S结构，可以根据后端数据库的类型来选择。如SybaseCTLib协议用于测试后台的数据库为Sybase的应用；MS SQL Server协议用与测试后台数据库为 SQL Server的应用；

  　　3、一般不是基于浏览器的，对于一些没有数据库的Windows应用，我们在测试的过程中都会选择WinSocket协议来录制，理论上来讲我们这样选择是正确的，但我们要知道在录制的时候所选择的协议就决定了LR如何捕获数据包，如果我们选择错误了，将会捕获到一些无用的数据包。

  cs结构是比较复杂的，在这里我要提醒大家，一定要搞清楚cs是client-database还是client-server-database结构的，只有这样我们才能够决定是选择WinSocket协议还是sql协议，或者说选择多个协议；当然协议的选择也是一个探索的过程，只要能够得到我们想要的结果，那就是正确的。还有一点，我们在做性能测试的时候应该是有测试重点的，呵呵。

  　　4、关于单协议和双协议，我只知道IE6内核的浏览器在录制脚本的时候要选择单协议，而IE7内核的浏览器在录制脚本的时候要使用双协议。

  　　 　 C/S （第二种）客户端以ODBC方法连接后台数据库 ODBC

• 现在好多网站系统为了防范，恶意访问系统，在登陆口进行限制，使用验证码登陆。

  　　验证码是随机产生的，并且验证码在页面上显示为图片。此时想通过直接获取服务器发送过来的参数，肯定是不可行的。

  　　在进行的时候，有两种办法进行此类系统的测试。

  　　1、将验证码暂时屏蔽，待完成性能测试后，在恢复。验证码屏蔽一定不会给性能测试带来影响，这是肯定的。

  　　2、如果要测试系统是在用的系统，屏蔽验证码会带来不安全因素，不能屏蔽验证码。遇到这个问题当然也有办法解决－－添加一个页面将验证码的输出到页面，然后用loadrunner获取到。

  　　验证码页面（a.jsp）

  在iframe中放入的c.jsp页面就是 获取验证码的页面。 　　这儿加了一个c.jsp 页面链接，主要是用在loadrunner录制脚本的时候，a.jsp 和c.jsp在B页面上加载的顺序不是有序的，因而C.JSP可能获取到的验证码为NULL。 　　在C.JSP页面上 在取得的验证码前后加上两个Q主要为了loadrunner能够捕获到这个验证码做的标记。 //获取C.JSP页面上的验证码 　　运行的时候 要把loadrunner的浏览器给关掉，否则lr的浏览器显示一下，相当于也做了一次请求。