服务器性能测试脚本

1.软文推荐

2.软文推荐

3.软文推荐

目录： 1、游戏后台怎么做性能测试 2、怎么进行性能测试 3、shell脚本在测试方面能拿来干嘛 4、性能测试：Socket协议脚本编写 5、loadrunner如何使用 游戏后台怎么做性能测试

一、什么是游戏后台性能测试

性能（performance）：是系统实现其功能的能力。例如，响应时间、吞吐能力、事务处理数。

性能测试，是指在特定负载情况下，确定系统的响应速度和稳定性的表现。它也可以研究、测量、验证系统的其他特征，比如可扩展性、可靠性和资源使用率。通俗的讲：通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生成性能要求，即在特定的运行条件下验证系统的能力状况。

按游戏构成特点，将性能测试分为客户端性能、服务器性能两大块。楼主问的应该是服务器性能测试吧！

二、性能测试的关键指标

客户端性能的关键指标有：

CPU占用率、内存占用率、流量耗用量、FPS（每秒传输帧数）

服务器端性能的关键指标有：

响应时间、并发用户数、吞吐量等；

三、如何做性能测试

1.    明确测试目标；了解性能测试需求；

2.    编写性能测试计划；

3.    分析性能测试需求；

4.    编写性能测试方案、设计测试场景；

5.    相关资源准备(人力资源、硬件资源、软件资源)；

6.    测试程序开发；脚本维护、测试数据准备、测试监控准备；

7.    执行性能测试并收集测试结果；

8.    分析结果；

9.    系统调优及再测试；

针对楼主的问题，推荐你一个服务器压测平台

WeTest性能测试（腾讯游戏官方出品）

腾讯WeTest压测大师支持的性能测试方法

接口测试

接口的性能评估，给整体做参考

场景测试

登入场景，战斗场景。游戏关键性的业务测试

容量测试

用于评估服务器可承载能力，给上线需要的硬件数量配备做参考

稳定性测试

用于验证服务器长期运行的状况

调优

性能瓶颈分析，定位，系统优化

希望能帮助到你怎么进行性能测试

问题一：性能测试应该做哪些准备 环境搭建：这个根据实际规划，我在企业内做过的性能测试搭建的环境都是和用户上线使用的实际环境一样的。

数据准备：个人感觉是整个工作里第二耗时的，需要真实模拟用户数据，这个不是单单的创建几个帐号就完事的，每个用户基本都会有不太一样的配置，实际操作的时候部署数据的脚本都写到手软。

脚本编译：选择性能工具编译性能脚本，你需要跑什么业务流程就编译什么样的脚本。

脚本执行：用规划好的用户数执行脚本，这个一般持续很长时间，时间太短不足以暴露服务器等的性能瓶颈，性能测试中最耗时的就是这个步骤。

收集日志：在执行脚本完成后收集到的能客观反应系统性能的日志、报表文件，比如LR的报告、数据库的AWR日志等等。

分析结果：分析收集到的日志、报表，找出性能瓶颈或是得出性能指标结果。这个一般需要对数据库或者底层非常了解的专业人士来分析，一般测试人员只需要提供收集到的报告就差不多了。

生成报告：将上面所有的性能测试活动整理总结，输出测试报告。

问题二：如何做好性能测试？ 你好，首先很欣赏你的这种态度。我在TestBird 招聘新人的时候，也有很多小朋友觉得自己有多了解工具运用，有多熟练步骤过程，自我感觉很不错。

其实，我却想说，性能测试的重点不在性能测试工具的学习上。

当然，你也通过分析系统的压力点、LR录制脚本，设置用户，做压力，分析结果，整理测试报告。完成了性能测试的整个过程。那么我说这个性能测试报告是有效的，但它不一定是有用的。

为什么呢？因为在性能测试报告中，在你所在的环境中，你是测出了这样的效果。并未掺假，全部真实的记录。

为什么说它不一定是有用的，你了解系统架构么？知道数据库、中间件、前端程序的运行方式和处理机制么？了解网络协议么？了解操作系统么？熟悉开发系统的语言么，如java JVM的内在机理知道么？这些都是系统运行的一部分，都在影响着系统的性能。如果不了解这些，你如何做出有价值的有参考意义的性能测试。

所以，学会这些性能测试工具很好，但是这仅仅是第一步。性能结果只是一些数据而已，知道你在做什么，为什么要做这些，做完后能给出有价值的东西，才是后面要慢慢修炼的。

问题三：移动客户端的性能测试如何做？ 。就当练习了。。大家看了不要喷我。。现在很多测试人员做移动端测试，可能主要还是关注功能和自动化测试。性能测试可能大多是按照每个人的体验来做报告，是不是比较快，或者比较慢。当然也不乏有很多的测试人员会回复我说，性能测试都是服务器的，移动端根本就不需要性能测试。我实在觉得可笑。 不过我毕竟一直在创业公司，而且就我一个人，所以了解可能有限，我这里就说下我之前碰见的，所知道的，目的只是抛砖引玉。 另外，我这里也不去说什么MAT，instruments了，这种固有查找内存的工具大家自己google吧。 客户端的性能从系统层面，电量消耗，网络流量，内存泄漏等都是被关注，或者说用户最最关注的点。 实例一，3rd 应用的性能测试。应用本身的响应时间可以通过call 应用intent来查看，设备纯环境，设备低内存等各种情况下进行同样此数的call，进行对比。或者与同行业同性质的应用进行对比测试。我相信很快就能够有结论了。除了应用本身，还需要对于应用本身某些特别的功能进行响应测试。比如测试一个list，测试的方法为onkeydown之后查看这个list.index（0）是否高亮，是否正常的界面跳转了，那么分别进行计时（精确ms）。同样的，我们在空list以及有几百条list的情况进行这样的case test，那么就会有一个性能的结果出来。 实例二，假设你测试微薄客户端，那么你肯定是需要进行一个list上下滑动的性能测试。我们需要使用脚本语言shell或者python去call server api来仿造数据反馈到移动设备上，否则你不可能自己手动去发几百条weibo然后再测试。测试的时候需要关注两个问题，一个是list在各种情况下是否滑动流畅，一个是当list中有很多的图片的时候图片load的速度也是一个很大的测试点。这个load可以直接检查imageview什么时候load出来pic，什么时候显示在界面上，计算时间。这里其实很多应用是webview，或者数据是存在服务器端的，这个时候无论是平时的测试还是压力，还是性能，数据的修改，其实还是多使用脚本ping api比较好，能够很好的去辅助达到性能测试的效果。 实例三，比如要测试一个优酷的视频软件，那么视频的播放的时候，首先保证网络的情况下，各种分辨率各种码率的视频接入时间是需要关注。然后在播放，也就是和网络不停的通信的同时，那么需要通过tcp dump和wireshark工具来检查网络访问是否正确，视频的卡顿，视频的花屏等除了硬件兼容之外，可以通过抓包来判断其性能。如果丢包率高那么自然视频卡，体验不好，性能也就不会好。 其实以上只是一些很基础，现在很多公司也已经在这个基础上改良测试了。不过也是一些思路，让更多的企业和测试关注移动客户端的性能。不要一提到性能脑中只有LR等这些Server测试。

问题四：为什么要进行性能测试? 原因有三：

川. 开发者的水平各有不同，有的写出来的东西性能高，有的低，所以需要统一测试一下。

2. 编程工具本身也有性能问题，用这样的工具开发出来的软件也要确认一下是否达到了需求所要求的性能指标，比如响应时间应该控制在多少秒以内。

3. 性能测试，强度测试都是为了测试系统的稳定性，稳定性好，软件的质量就好，买的钱就多。

问题五：如何进行Web服务的性能测试 贴一篇我们内部的文章：

随着浏览器功能的不断完善，用户量不断的攀升，涉及到web服务的功能在不断的增加，对于我们测试来说，我们不仅要保证服务端功能的正确性，也要验证服务端程序的性能是否符合要求。那么性能测试都要做些什么呢？我们该怎样进行性能测试呢？

性能测试一般会围绕以下这些问题而进行：

1. 什么情况下需要做性能测试？

2. 什么时候做性能测试？

3. 做性能测试需要准备哪些内容？

4. 什么样的性能指标是符合要求的？

5. 性能测试需要收集的数据有哪些？

6. 怎样收集这些数据？

7. 如何分析收集到的数据？

8. 如何给出性能测试报告？

性能测试的执行过程及要做的事儿主要包含以下内容：

1. 测试评估阶段

在这个阶段，我们要评估被测的产品是否要进行性能测试，并且对目前的服务器环境进行粗估，服务的性能是否满足条件。

首先要明确只要涉及到准备上线的服务端产品，就需要进行性能测试。其次如果产品需求中明确提到了性能指标，那也必须要做性能测试。

测试人员在进行性能测试前，需要根据当前的收集到的各种信息，预先做性能的评估，收集的内容主要包括带宽、请求包大小、并发用户数和当前web服务的带宽等

2. 测试准备阶段

在这个阶段，我们要了解以下内容：

a. 服务器的架构是什么样的，例如：web服务器是什么？是如何配置的？数据库用的是什么？服务用的是什么语言编写的？；

b. 服务端功能的内部逻辑实现；

c. 服务端与数据库是如何交互的，例如：数据库的表结构是什么样的？服务端功能是怎样操作数据库的？

d. 服务端与客户端之间是如何进行交互的，即接口定义；

通过收集以上信息，测试人员整理出服务器端各模块之间的交互图，客户端与服务端之间的交互图以及服务端内部功能逻辑实现的流程图。

e. 该服务上线后的用户量预估是多少，如果无法评估出用户量，那么可以通过设计测试执行的场景得出这个值；

f. 上线要部署到多少台机器上，每台机器的负载均衡是如何设计的，每台机器的配置什么样的，网络环境是什么样的。

g. 了解测试环境与线上环境的不同，例如网络环境、硬件配置等

h. 制定测试执行的策略，是需要验证需求中的指标能否达到，还是评估系统的最大处理能力。

i. 沟通上线的指标

通过收集以上信息，确定性能测试用例该如何设计，如何设计性能测试用例执行的场景，以及上线指标的评估。

3. 测试设计阶段

根据测试人员通过之前整理的交互图和流程图，设计相应的性能测试用例。性能测试用例主要分为预期目标用户测试，用户并发测试，疲劳强度与大数量测试，网络性能测试，服务器性能测试，具体编写的测试用例要更具实际情况进行裁减。

用例编写的步骤大致分为：

a. 通过脚本模拟单一用户是如何使用这个web服务的。这里模拟的可以是用户使用web服务的某一个动作或某几个动作，某一个功能或几个功能，也可以是使用web服务的整个过程。

b. 根据客户端的实际情况和服务器端的策略，通过将脚本中可变的数据进行参数化，来模拟多个用户的操作。

c. 验证参数化后脚本功能的正确性。

d. 添加检查点

e. 设计脚本执行的策略，如每个功能的执行次数，各个功能的执行顺序等

4. 测试执行阶段

根据客户端的产品行为设计web服务的测试执行场景及测试执行的过程，即测试执行期间发生的事儿。通过监控程序收集web服务的性能数据和web服务所在系统的性能数据。

在测试执行过程中，还要不断的关注以下内容：

a. web服务的连接速度如何？

b. 每秒的点击数如何？

c. Web服务能允许多少个用户同时在线？

d. 如果超过了这......

问题六：网站性能测试主要有哪几种方法? 我知道的性能测试主要有：压力测试，负载测试，容量测试，发性能测试，兼容性测试（不同的操作系统和不同的浏览器）。测的时候应用在客户端的性能、应用在网络上的性能和应用在服务器端的性能都要进行测试的。

希望能帮到你。

问题七：怎么才能做性能测试工程师？ 性能测试实际上确实需要些功底儿，但是也并不是非得一两年之后才去做。

我给你列几条性能测试工作中的建议，你可以自己温习一下，然后去面试，具体的经验需要实际的工作才能得到，然而你扎实的基础知识才识支撑你走下去的动力。

1，最直接也是最表面的建议，适用于面试：Loadrunner, HttpWatch, Dynatrace, TeamQuest, JMeter(可选), Wily(可选), HTML/HTTP, Webservice, Mainframe, DB. 这些东西足够学很久很久的了，所以说需要几年的工夫，但是没必要每一样都学太深，了解即可，经验日后会积累到的。

2，相对比较深层的建议：性能测试最关键之处不是工具的选择，而是对整个性能参数的理解，所以比较贴近于概念，比如说什么是TPS, Response Time, Connection浮 per Second....还有就是什么是CPU Utilization, FreeMem, Disk IO, Paging.... 工具也无非都是通过日积月累形成的客户端，所以抓到本质才是关键。

不在这里长篇大论了，呵呵，加油！

问题八：性能测试应该怎么做 需求分析 － 测试设计 － 测试执行 － 结果分析

问题九：APP如何做性能测试 目前市面上有很多家做安全加密的平台都有做安全检测，但是大部分需要付费，如果说只是个小项目的话花钱去做的话成本太高，也不建议去做

你可以了解下爱内测这个平台，专门做测试的，有安全检测、兼容测试、插件评估等，虽然这个平台也是付费的，但是他有免费的版本提供，个人觉得安全检测免费版本已经足够强大了，自动化生成测试报告，提供精准的检测数据

希望可以帮助到你

问题十：服务端怎么做性能测试 使用LR对数据库进行性能测试，实际上有多种办法，包括通过现有的数据库协议进行CS模式的先录制后执行的模式，以及通过socket方式向服务器发包方式的测试方式。这些是常规书籍上介绍的比较简单上手的测试方法，但是不具备通用性，受已有协议或socket编程方式的限制，所以需要更为通用的测试方法。

用Java user的协议进行所有数据库性能的测试工作：

Java user 不需要录制，把所有的操作通过java语言进行实现，通过lr调用java的class进行加压批量操作，这样可以不关心被测系统是哪个数据库，只要能够通过jdbc进行访问，就能实现性能测试。

一、测试环境准备

1. 被测服务器准备，根据测试目的，搭建需要的数据库服务器，确保数据库能够正常访问，正常操作；

2. Java代码的准备，无论使用哪种IDE，只要能够编写访问数据库的class就可以，形式可以是j2se，也可以是j2ee，因为在操作时只使用class的部分方法，所以j2ee就可以了；

3. LR的脚本调试，把java的class导入到脚本调试模式，根据需要添加事务以及其他操作。

二、编写数据库访问

1. 使用myeclipse，创建web project，创建如下图的包目录：

Java文件中包含各种访问数据库的方法。

需要注意的是，class中的方法必须是public static，否则LR中无法调用。由于创建的是j2ee程序，所以不用main函数，在web中就可以进行功能验证。

确认class中的方法编写完成，创建一个web.jsp文件，如下：

导入class

声明类，并实例化，直接调用刚才编写的3个方法，因为这3个方法是直接对数据库进行操作，不需要实参，也没有返回值，所以直接实现即可。

此时启动web服务，在浏览器中输入jsp的地址，直接刷新页面，就可以调用这3个方法，如果正确，就会对相应的表进行操作，如果不正确，则需要修改相应的代码。

2. LR脚本准备：

LR脚本实际上就是对访问代码的调用，关键在于需要根据测试场景划分不同的脚本布局。

例如：在myEclipse里，我们只编写了一个class，其中包含三个方法，如果在执行性能测试时，这三个方法相互独立，互不干涉，则最简单的划分方法是，创建三个java user，每个java user中包含一个方法，做三份脚本，场景执行时分别进行调用。如果三个方法之间有相互关系，则需要根据实际情况，把有关联的方法放在一起，具体情况可按实际灵活分配。

因为已经将class文件进行编译发布了，所以可以在“java2postgresWebRootWEB-INFclasses\lr est”目录中找到对应的class文件，

复制这个文件，找到LR的目录：HPLoadRunnerclasses\lr est 如果没有文件夹，按相同的内容创建。

在LR脚本中进行引包操作：

将需要执行的java类以及方法，放在action中，可根据实际测试情况和所需要验证的内容，具体调试代码。

在这里可以像编写普通LR脚本一样，添加事务或 *** 点等内容。

由于是通过JDBC对数据库进行访问，因此要在java user中加载jdbc驱动。

运行时设置中，增加jdbc驱动，需要注意的是java user使用的本地jdk，需要至多1.6版......

shell脚本在测试方面能拿来干嘛

shell脚本可以用来测试系统的性能，以及其上运行的程序的可靠性和运行效率。它可以帮助用户探测哪些应用程序存在性能问题，比如CPU利用率过高、反应慢、进程占用服务器等。此外，它还能检测服务器上正常运行的程序，比如用户的ftp、数据库和web服务，查看它们的响应情况、性能比较和兼容问题等。

性能测试：Socket协议脚本编写

一般C/S架构的系统使用SOCKET协议

RemoteHost 服务端地址和端口号

连接是否成功？rc=0 表示建立连接成功

由socket0 通道发送buf0里的数据

将socket通道返回的数据存放到buf1中

关闭socket0通道

第一个参数socket0是指已经建立的socket连接的名称

第二个参数buf0是需要发送的buf(在data.ws中维护)

向流套接字发送指定长度的缓冲区数据

int lrs_length_send(char socket_descriptor , char buffer , int location_option ,

[char locators ], [char additional_params ],LrsLastArg );

socket_descriptor 套接字标识符

buffer 缓冲区标识符

location_option（定位模式） 使用哪种方法进行定位

locator （定位器，跟上一个参数对应） 对应上面的参数，对应的locator参数如下：

LrsLastArg 参数结尾标识

成功返回0，否则返回错误码

在这个例子中，buf0通过socket0发送，数据使用了参数化，NameParameter是一个参数，从一系列的数据中取值。 4是长度数据，但是，随着参数NameParameter变化，长度也在随着变化，比如：David长度应该改为5，Michael长度应该改为7。

int lrs_length_receive(char socket_descriptor , char buffer , int location_option ,

[char locators ], [char additional_params ],LrsLastArg );

lrs_length_send ("socket0", "buf0", LeftRightBoundaries, "LB=LBoundary","RB=:RBoundary", "Offset=10", LrsLastArg);

socket_descriptor 套接字标识符

buffer 缓冲区标识符

location_option （定位模式） 使用哪种方法进行定位：

locator（定位器，跟上一个参数对应） 对应上面的参数，对应的locator参数有三种组合如下：

additional_params（额外参数） 主要包括缓冲区长度格式和长度计算相关的其它问题

LrsLastArg 参数结尾标识

在静态或接收到的缓冲区中搜索出现的字符串，将出现字符串的缓冲区部分保存到参数中

lrs_save_searched_string (char *s_desc, char *buf_desc, char *param_name, char *left_boundary, char *right_boundary, int ordinal, int offset, int param_len);

原始数据为："0|普通指令下达成功|10000031|"。

lrs_save_searched_string ("socke0","buf1","wtbh","LB/BIN=|","RB/BIN=|",2,0,-1);

输出结果： "wtbh =10000013" 。在以左边界和右边界第2次出现的地方，获取左右边界里面的所有的值.

原始数据为："0|普通指令下达成功|10000031|"。

lrs_save_searched_string("socke0","buf1","wtbh","LB/BIN=|","RB/BIN=|",1,0,-1);

输出结果："wtbh = 普通指令下达成功",在以左边界和右边界第1次出现的地方，获取左右边界里面的所有的值

原始数据为："0|普通指令下达成功|10000031|"

lrs_save_searched_string("socke0","buf1","wtbh","LB/BIN=|","RB/BIN=|",1,4,-1);

• 输出结果："wtbh = 指令下达成功",在以左边界和右边界第1次出现的地方，获取左边界为起点的第4个字符后面的数据。

将静态或接收到的缓冲区保存到参数中

lrs_save_param (char *s_desc, char *buf_desc, char *param_name, int offset, int param_len);

参数:

从数据包中第34个字符开始连续取8个字符。

将用户、静态或接收到的缓冲区保存到参数中

lrs_save_param_ex (char *s_desc, char *type, char *buff, int offset, int length, char *encoding, char *param);

参数:

loadrunner如何使用

1、使用LoadRunner 完成测试一般分为四个步骤：

2、Vvitrual User Generator 创建脚本

创建脚本，选择协议

录制脚本

编辑脚本

检查修改脚本是否有误

3、中央控制器（Controller）来调度虚拟用户

创建Scenario，选择脚本

设置机器虚拟用户数

设置Schedule

如果模拟多机测试，设置Ip Spoofer

4、运行脚本

分析scenario

分析测试结果

5、安装LoadRunner 中文版

LoadRunner 分为Windows 版本和Unix 版本。如果我们的所有测试环境基于Windows

平台， 那么我们只要安装Windows 版本即可。本章讲解的安装过程就是LoadRunner7.8中文的Windows 版本的安装。

6、使用LoadRunner进行负载/压力测试

7、录制基本的用户脚本

创建用户脚本需要用到VuGen。提示： 运行VuGen 最好在1024*768 的分辨率下， 否则有些工具栏会看不到。

启动Visual User Generator 后， 通过菜单新建一个用户脚本， 选择系统通讯的协议。

这里我们需要测试的是Web 应用，同时考虑到后台SQL数据库所以我们需要选择Web(HTTP/HTML)协议＋SQL SERVER协议，确定后， 进入主窗体。通过菜单来启动录制脚本的命令。

8、在URL 中添入要测试的Web 站点地址..。

●测试选择要把录制的脚本放到哪一个部分， 默认情况下是“Action”。

这里简单说明一下：VuGen 中的脚本分为三部分：vuser_init、vuser_end 和Action。其

中vuser_init 和vuser_end 都只能存在一个， 不能再分割， 而Action 还可以分成无数多个部分（ 通过点击New 按钮， 新建ActionXXX）。在录制需要登陆的系统时， 我们把登陆部分放到vuser_init 中， 把登陆后的操作部分放到Action 中， 把注销关闭登陆部分放到vuser_end 中。（ 如果需要在登陆操作设集合点， 那么登陆操作也要放到Action 中， 因为vuser_init 中不能添加集合点） 在其他情况下， 我们只要把操作部分放到Action 中即可。注意： 在重复执行测试脚本时，vuser_init 和vuser_end 中的内容只会执行一次， 重复执行的只是Action 中的部分。

点“ 选项 ”按钮， 进入录制的设置窗体， 这里一般情况下不需要改动。

●然后点“OK” 后，VuGen 开始录制脚本。在录制过程中， 不要使用浏览器的“ 后退” 功能，LoadRunner 支持不太好！ 录制过程中， 在屏幕上会有一个工具条出现。录制的过程和WinRunner 有些类似， 不再多介绍。录制完成后， 按下“ 结束录制” 按钮，VuGen 自动生成用户脚本， 退出录制过程。

完善测试脚本

当录制完一个基本的用户脚本后， 在正式使用前我们还需要完善测试脚本， 增强脚本的

灵活性。一般情况下， 我们通过以下几种方法来完善测试脚本。插入事务、插入结合点、插入注解、参数化输入。这里只举例介绍参数化如何设置，其它只作简单介绍。

插入事务

事务（Transaction）： 为了衡量服务器的性能， 我们需要定义事务。比如： 我们在脚本

中有一个数据查询操作， 为了衡量服务器执行查询操作的性能， 我们把这个操作定义为一个事务， 这样在运行测试脚本时，LoadRunner 运行到该事务的开始点时，LoadRunner 就会开始计时， 直到运行到该事务的结束点， 计时结束。这个事务的运行时间在结果中会有反映。

插入事务操作可以在录制过程中进行， 也可以在录制结束后进行。LoadRunner 运行在

脚本中插入不限数量的事务。

具体的操作方法如下： 在需要定义事务的操作前面， 通过菜单或者工具栏插入。输入该事务的名称。注意： 事务的名称最好要有意义， 能够清楚的说明该事务完成的动作。插入事务的开始点后， 下面需要在需要定义事务的操作后面插入事务的“ 结束点”。同样可以通过菜单或者工具栏插入。默认情况下， 事务的名称列出最近的一个事务名称。一般情况下， 事务名称不用修改。事务的状态默认情况下是LR_AUTO。一般情况下， 我们也不需要修改， 除非在手工编写代码时， 有可能需要手动设置事务的状态。

插入集合点

插入集合点是为了衡量在加重负载的情况下服务器的性能情况。在测试计划中， 可能会

要求系统能够承受1000 人同时提交数据，在LoadRunner 中可以通过在提交数据操作前面加入集合点， 这样当虚拟用户运行到提交数据的集合点时，LoadRunner 就会检查同时有多少用户运行到集合点，如果不到1000 人，LoadRunner 就会命令已经到集合点的用户在此等待， 当在集合点等待的用户达到1000 人时，LoadRunner 命令1000 人同时去提交数据， 从而达到测试计划中的需求。

注意： 集合点经常和事务结合起来使用。集合点只能插入到Action 部分，vuser_init 和vuser_end 中不能插入集合点。具体的操作方法如下： 在需要插入集合点的前面， 通过菜单或者工具栏操作输入该集合点的名称。注意： 集合点的名称最好要有意义， 能够清楚的说明该集合点完

成的动作。

插入注释

注释的作用就不多说了， 不过插入注释最好是在录制过程中。具体的操作方法如下： 在需要插入注释的前面， 通过菜单或者工具栏操作

参数化输入

如果用户在录制脚本过程中， 填写提交了一些数据， 比如要增加数据库记录。这些操作

都被记录到了脚本中。当多个虚拟用户运行脚本时， 都会提交相同的记录， 这样不符合实际的运行情况， 而且有可能引起冲突。为了更加真实的模拟实际环境， 需要各种各样的输入。参数化输入是一种不错的方法。

用参数表示用户的脚本有两个优点：

① 可以使脚本的长度变短。

② 可以使用不同的数值来测试你的脚本。例如， 如果你企图搜索不同名称的图书， 你

仅仅需要写提交函数一次。在回放的过程中， 你可以使用不同的参数值， 而不只搜索一

个特定名称的值。

参数化包含以下两项任务：

① 在脚本中用参数取代常量值。

② 设置参数的属性以及数据源。

参数化仅可以用于一个函数中的参量。你不能用参数表示非函数参数的字符串。

另外， 不是所有的函数都可以参数化的。

参数化输入的讲解， 我们采用一个例子的方式来进行。

在本例中我们参数化用户的登陆名：

先看如下脚本，通过脚本录制找到用户登陆部分，如图

参数名随意取，建议取通俗易懂的名字，下面我们重点介绍一下参数的类型。

●DateTime： 很简单， 在需要输入日期/时间的地方， 可以用DateTime 类型来替代。

其属性设置也很简单， 选择一种格式即可。当然也可以定制格式。

.●Group Name：暂时不知道何处能用到，但设置比较简单。在实际运行中，LoadRunner

使用该虚拟用户所在的Vuser Group 来代替。但是在VuGen 中运行时，Group Name

将会是None

.●Load Generator Name： 在实际运行中，LoadRunner 使用该虚拟用户所在Load Generator 的机器名来代替。

.●Iteration Number： 在实际运行中，LoadRunner 使用该测试脚本当前循环的次数来

代替。

.●Random Number： 随机数。很简单。在属性设置中可以设置产生随机数的范围

.●Unique Number：唯一的数。在属性设置中可以设置第一个数以及递增的数的大小。

注意： 使用该参数类型必须注意可以接受的最大数。例如： 某个文本框能接受的

最大数为99。当使用该参数类型时， 设置第一个数为1， 递增的数为1， 但100 个

虚拟用户同时运行时，第100 个虚拟用户输入的将是100，这样脚本运行将会出错。

注意： 这里说的递增意思是各个用户取第一个值的递增数， 每个用户相邻的两次循

环之间的差值为1。举例说明： 假如起始数为1， 递增为5， 那么第一个用户第一

次循环取值1， 第二次循环取值2； 第二个用户第一次循环取值为6， 第二次为7；

依次类推。

●Vuser ID： 设置比较简单。在实际运行中，LoadRunner 使用该虚拟用户的ID 来代

替，该ID 是由Controller 来控制的。但是在VuGen 中运行时，Vuser ID 将会是–1。

File： 需要在属性设置中编辑文件，添加内容，也可以从现成的数据库中取数据（ 下

面我们将会介绍）

●User Defined Function： 从用户开发的dll 文件提取数据。就目前我认为， 这种方式

没有必要。VuGen 支持C 语言的语法，在VuGen 中重新编写类似的函数应该不难。

上面的例子中， 我们取随机数即可。点“Properties… ..” 按钮， 进行属性设置窗口

添入随机数的取值范围为（1-50）， 选择一种数据格式。在“属性” 中有以下几

个选项：

◆Each Occurrence：在运行时， 每遇到一次该参数， 便会取一个新的值

◆Each iteration：运行时， 在每一次循环中都取相同的值

◆Once：运行时， 在每次循环中， 该参数只取一次值

这里我们用的是随机数， 选择Each Occurrence 非常合适。

下面我们再介绍用数据库中的用户名来参数化登陆用户名。

框选住登陆名，点鼠标右键，弹出对话框，选择“替换为新参数”弹出对话框，此时参数名输入：name，参数类型选择File，如图

注意： 参数的文件名不要使用con.dat、pm.dat 或者lpt*.dat 等系统装置名下面我们将会连接数据库， 从数据表中选择用户名。点“数据向导” 按钮，显示如图

添入连接字符串， 点“创建” 按钮，选择事先配置好的ODBC连接。在SQL语句里输入select查询语句，出现如图窗口

提醒： 在参数数据显示区， 最多只能看到100 行， 如果数据超过100 行， 只能点“编辑” 按钮， 进入记事本看。

“选择下一行 ” 有以下几种选择：

●Sequential： 按照顺序一行行的读取。每一个虚拟用户都会按照相同的顺序读取

●Random： 在每次循环里随机的读取一个， 但是在循环中一直保持不变

●Unique ： 唯一的数。注意： 使用该类型必须注意数据表有足够多的数。比如Controller 中设定20 个虚拟用户进行5 次循环， 那么编号为1 的虚拟用户取前5 个数， 编号为2 的虚拟用户取6-10 的数， 依次类推， 这样数据表中至少要有100 个数据， 否则Controller 运行过程中会返回一个错误。

“按编号”指选择列表中的那一列数据，从左到右分别是1、2、3依次

通常用在有关联性的数据上面。我们这里取值Sequential 即可。完成设置关闭即可

4.3 单机运行测试脚本

经过以上的各个步骤后， 脚本就可以运行了。运行脚本可以通过菜单或者工具栏来操作。

执行“ 运行” 命令后，VuGen 先编译脚本， 检查是否有语法等错误。如果有错误，VuGen

将会提示错误。双击错误提示，VuGen 能够定位到出现错误的那一行。为了验证脚本的正

确性， 我们还可以调试脚本， 比如在脚本中加断点等， 操作和在VC 中完全一样， 相信大家谁都不会感到陌生。如果编译通过， 就会开始运行。然后会出现运行结果。