做过一段时间的接口测试任务，下面把一段接口测试的脚本分享出来：

    Action()
{

//首先调用web_reg_find()这个注册函数，我们接口的正常返回结果都是<Code>0</Code>
    web_reg_find("Search=Body", //定义查找范围
    "SaveCount=result", //定义查找计数变量名称
    "Text=<Code>0</Code>", //定义查找内容
     LAST);

 //发送请求
 web_submit_data("FollowersGetByName",
  "Action= http://10.240.248.103:7004/Following/FollowersGetByName.ashx?",
  "Method=POST",
  "Referer= http://10.240.248.103:7004/Following/FollowerGetByName.ashx?",
        "Mode=HTML",
  ITEMDATA,

//Name后面的值都是接口参数值，可以参考开发人员提供的接口设计文档或者录制脚本获得

//接口的参数值一般都要参数化，尽可能的模拟真是场景
  "Name=userid","Value={NewParam}",ENDITEM,
  "Name=snsid","Value=6000",ENDITEM,
  "Name=username","Value={myUserName}",ENDITEM,
                LAST);

  

//刚才的web_reg_find()注册函数派上用处，可以对结果进行统计

  if (atoi(lr_eval_string("{result}")) > 0) //判断如果<Code>0</Code>
                                               //字符串出现次数大于0
        lr_output_message("Log on successful."); //在日志中输出Log on successful
    else
  //如果出现次数小于等于
       lr_error_message("Log on failed"); //在日志中输出Log on failed

 return 0;
}

你是否肯定你的网站完全兼容各大浏览器？是否知道多少秒可以打开你的网站？ 是否可以自信地说你的网站根本就没有打不开的时候？ 是否……
虽然它看似不重要，但这些在一定程度上也对你的网站的访问量产生了影响 。这里列出了一份31 个免费在线测试工具，你可以通过这些工具来测试你的网站，并根据结果对你的网站进行修改。

网站代码验证没人可以细致到保证自己的网站代码都是正确的，你可以通过以下测试来验证网站代码是否正确。

1 .WDG HTML Validator一个很好的工具，能找出网站语法错误的地方，并标注出来，也可选择对网站上单独的每一页进行单页分析。（强烈推荐）

2 .W3C Markup Validation Service对 HTML 和 XHTML 都能进行代码测试，自称是互联网络上第一个（也是使用者最多的）的 HTML 验证工具。

3 .W3C CSS Validation Service用于验证 css 源代码，能够标注出不好的 css 代码设计。例如：“Same colors for color and background-color in two contexts”。

4 .RUWF XML Syntax Checker用于查找 XML 文件的错误。

5 .W3C Feed Validation Service用于查找 Atom 和 RSS feed 中的错误语法。

6 .W3C Link Checker用于搜寻查明你网站内的所有链接里是否有断链。（强烈推荐）

7 .Juicy Studio Link Analyser测试网站内的链接的 URL 是否存在死链，与 W3C Link Checker 很类似。
网站的使用性
我们常常看到网站设计者把重点放在怎网站的吸引力上，而完全不考虑会不会影响来访者的使用，一个浏览难度很大的网页是注定要失败，要让你的来访者方便的得到他要的信息（从而成为重复访客），你的网站应当遵循 WCAG section 508 易用性规则。

8 .Watchfire WebXACT所有严谨的设计师和开发者都必须使用的工具，它会生成一个非常详尽的报告书，包括：网站质量，易用性和隐私等。（强烈推荐）

9 .ATRC Web Accessibility Checker测试网站的 WCAG 2.0 Level2 兼容性，它会生成一份报告，提出一系列建议，如：如何提升页头，链接，数据，图表和文字的访问速度。

10 .WAVE 3.0 Web Accessibility Tool高度可定制的工具，它采用了图形化模型展示网站兼容性问题（ WCAG 1.0 and section 508 ）。（强烈推荐）

11 .TAW Web Accessibility Test测试网页是否存在冲突（ WCAG 1.0 兼容性 ），通过图形模式生成一份依据 wcag 优先模式为基础的网站修改建议。

12 .HiSoftware CynthiaSays portal采用了非常严格的规则来测试网页（ 根据 section 508 和 WCAG 1.0 规则 ），生成的报告也极为详细（ 详细到很难看懂 ）。

13 .HERA Accessibility testing with Style使用一种极为复杂但容易理解方式指出网页的 wcag1.0 兼容性问题。

14 .Juicy Studio CSS Analyser进行了色彩对比测试，以确保你的网站的色调会符合 WCAG 1.0 的要求。

15 .Juiciy Studio Readability Test分析你网站上的文字是否有语法错误或拼写错误等问题，容易让人理解不（ 根据 the Flesch Reading Ease 和 Flesch-Kincaid grade level algorithms 规则 ）。（ 适合英文网站使用 ）
网站的速度
打开你的网站的速度快慢，是来访者会不会再次访问网站的关键因素，在一般情况下，一个网络不是很快的来访者是不愿意访问一个充满着图片、flash 动画、多媒体文件的网站。为了使你的网站覆盖人群的范围最大化，你必须优化你的网站，使它的打开速度尽可能的快。

16 .Web Page Analyzer from Website Optimization一个很好的工具，它在分析完一个网页后，会为减少加载时间提出优化建议，着重优化物体的数目，图片和网站的总体大小。（强烈推荐）

17 .WebSitePulse Test Tools有一系列的工具来确定网站的加载速度和主机信息。

18 .Internet Supervision Url Check从世界各地不同的服务器来测试你的网站的加载时间，用于确定是不是各地的来访者都能顺利快速的打开你得网站。
浏览器模拟工具
这是一个普遍的问题，因为现在有着很多的操作系统和浏览器，你得网站必须得兼容它们，但这绝不是一件容易的事。通过下列工具，你可以了解你得网站在各种浏览器上的显示效果。

19 .Browsershots能给出你的网站在不同浏览器下显示效果的截图，包括：Firefox 和 Internet Explorer （ Windows ）、Firefox 和 Safari （ Mac OS X ）、Iceweasal 和 Konqueror （ Linux ），但是结果要在 1 - 3 小时后才能出来。

20 .IE NetRenderer实时生成你的网站在 Internet Explorer 5.5 、6.0 和 7.0 下的截图。

21 .MobiReady Report分析使用手机访问网页的兼容性问题，会生成一份详细的报告，并提供了在两种不同类型的手机浏览器上你得网站可能显示的样子。
搜索引擎优化 (SEO)
一个网站，如果对搜索引擎有着比较好的友好度，一定会比较有竞争力。

22 .UrlTrends会显示网站的访客是如何通过搜索引擎来到你的网站，还有各个流量是多少。这些数据是包括 Google, Yahoo, MSN, Alexa, AlltheWeb, AltaVista 和其他一些网站。（强烈推荐）

23 .iWEBTOOL Backlink Checker一个很好的工具，它能找出有什么站点链接到你的站点，那些站点是什么类型的站点。

24 .iWEBTOOL Multi-Rank Checker显示你网站的 Alexa 和 Google PageRank 数值。

25 .Microsoft adCenter Labs: Advertising and Keyword Research Tools一个极好的工具，用于分析和预测你网站的来访者和市场。（强烈推荐）

26 .Domain Tools Whois lookup一个 WHOIS 网络工具。

27 .SEO-Browser可以让你看到在搜索引擎眼里一样的网站（ 去掉所有的”美丽”配件 ）。

28 .SEO Workers SEO Analysis Tool非常有用的工具，分析了网站上的各种分类特征，包括 meta. 标签、关键字密度及加载时间。（强烈推荐）

29 .Seekport Seekbot可以分析网站的数据和内容，以得出搜索引擎会如何有效的解释分析的网站。

30 .SEO Chat SEO Tools用以分析网站 Google adsense 盈利潜力，关键字密度，Meta. tag 等等……

31 .Marketleap Search Engine Marketing Tools用来分析网页，让你知道你的网站检索、设定的关键字好不好。

最近尝试用LR测试公司营帐系统的协议接口，使用了LR中socket协议的基本函数，实现了发送请求数据，接收返回数据并从返回数据中截取到指定范围的字符串rspcode，并转换回整形，实时反馈测试结果的功能

respcode:200=正常

附Action源码，具体包的信令因涉及到项目信息不公布。

#include "lrs.h"

Action()
{
 char *buf0;
 int ActucalNumber;
 int respcode;
 int length;
 int Numberofbuf0;

 lrs_create_socket("socket0", "TCP", "RemoteHost=172.16.11.170:8888",LrsLastArg);
 lrs_send("socket0", "buf0", LrsLastArg);
 lrs_receive("socket0", "buf1", LrsLastArg);

lrs_get_buffer_by_name("buf0",&buf0,&Numberofbuf0);

//获取send buf的包的长度,在修改发送包buf0的时候自动统计包长

 ActucalNumber=lrs_get_last_received_buffer_size("socket0");

//socket接收到buf动态包长，由于返回的数据包的包长动态变化，所以lrs_save_param_ex操作时需要获取ActualNumber

 lrs_save_param_ex("socket0","received",NULL,0,ActucalNumber,"ascii","param1");

//获取返回数据的字符串
 lrs_save_param_ex("socket0","received",NULL,32,4,"ascii","param2");

//respcode在接口返回字符串中的位置为32~36
 length=strlen(lr_eval_string("<param2>"));

//获取rspcode字符串的长度，lrs_hex_string_to_int函数用
 lrs_hex_string_to_int(lr_eval_string("<param2>"),length,&respcode);

//字符型转换成整形，方便在日志中查看respcode结果
 lrs_close_socket("socket0");

 lr_output_message("-----------------------------------INFO---------------------------------------");
 lr_output_message("The length of resp is %d", ActucalNumber);
 lr_output_message("The content of resp is %s", lr_eval_string("<param1>"));
 lr_output_message("The content of respcode is %s", lr_eval_string("<param2>"));
 lr_output_message("Respcode is %i", respcode);
 lr_output_message("包长度：%d",Numberofbuf0);

    return 0;
}

同时也使用python实现了类似的测试代码，下回分解.

LoadRunner Monitor Linux System material(转载)

今天用LoadRuner来监控Linux系统资源，遇到了一点麻烦，不过还是解决了，下面将操作的过程描述如下：

1. 首先在Linux服务器上安装rpc.rstatd服务，这里用的是rpc.rstatd-4.0.1.tar.gz安装包，如果没有可以到该网址上去下载：http://sourceforge.net/projects/rstatd；

2. 执行安装包：

   解压安装包：tar -xvzf rpc.rstatd-4.0.1.tar.gz

   进入安装包：cd rpc.rstatd-4.0.1.tar.gz

   配置rpc.rstatd: ./configure

   编译rpc.rstatd： make

   安装rpc.rstatd： make install

3. 重新启动xinetd:  /etc/init.d/xinetd restart;

4. 修改etc/xinetd.d 目录下的3个conf(rlogin,rsh,rexec)文件中的disable均设置为no，

   即设置：disable=no，保存；

5. 启动rpc.rstatd并查看是否真正启动该服务：

   【root@localhost~】#rpc.rstatd

   【root@localhost~】#rpcinfo -p

   结果如下：

从上图中可以看出rpc.rstatd服务已经启动

6. 启动LoadRunner并监控Linux系统资源：

   在controller中，将System resource Graphs中的Unix resources拖到右侧的监控区域中，并单击

   鼠标右键选择“Add Measurements”,在弹出的对话框中输入被监控的linux系统的IP地址，然后选择需

   要监控的性能指标，并点击“确定”，出现如下结果：

   Monitor name :UNIX Resources. Cannot initialize the monitoring on 10.10.15.62. 
Error while creating the RPC client. Ensure that the machine can be connected and that it runs the rstat daemon (use rpcinfo utility for this verification).
Detailed error: RPC: Failed to create RPC client.
RPC-TCP: Failed to establish RPC server address.
RPC-TCP: Failed to communicate with the portmapper on host '10.10.15.62'.
RPC: RPC call failed.
RPC-TCP: recv()/recvfrom() failed.
RPC-TCP: Timeout reached. (entry point: CFactory::Initialize). [MsgId: MMSG-47190]

   检查原因，发现是Linux系统中的防火墙开启了并且阻挡了LoadRunner监控Linux系统的资源，因此要将

   防火墙关闭。

7.关闭防火墙： [root@localhost ~]# /etc/init.d/iptables stop;

8. 重复步骤6，成功后结果如下图所示：

Apache JMeter是可以对利用HTTP或FTP服务器的应用程序进行测试的工具。它是基于Java的，通过所提供的API它还具有高度可扩展性。典型的JMeter测试包括创建循环和线程组。循环使用预设的延迟来模拟对服务器的连续请求。线程组是为模拟并发负载而设计的。JMeter提供了用户界面。它还公开了API，用户可以从Java应用程序来运行基于JMeter的测试。为了在JMeter中创建负载测试，需要构建测试计划。在实际操作中，Jmeter需要执行一系列的操作。最简单的测试计划通常包括下列元件：

线程组——这些元件用于指定运行的线程数和等候周期。每个线程模拟一个用户，而等候周期用于指定创建全部线程的时间。例如，线程数为5，等候时间为10秒，则创建每个线程之间的时间间隔为2秒。循环数定义了线程的运行时间。使用调度器，还可以设置运行的起始时间。

取样器——对于服务器HTTP、FTP或LDAP请求，这些元件是可配置请求。该教程仅侧重于Web Services请求。

监听器——这些元件用于请求数据的后期处理。例如，可以将数据保存到文件或用图表来说明结果。此时JMeter图表并没有提供许多配置选项；然而它是可扩展的，它始终可以添加额外的可视化效果或数据处理模块。

Apache JMeter网站给出了关于可用元件的详细说明。在某些情况下，如果可用元件不适合特定的测试，开发人员可通过在安装Jmeter的\lib\ext\目录中放置jar文件来编写他/她自己的脚本或Java类，并将其嵌入测试计划。

本文中我们使用的是版本是JMeter 2.1。从 Web 站点 下载可执行二进制文件，将其解压缩,然后应用程序即可在Windows或Unix平台中使用。如果是在Windows操作系统中工作，要转到bin文件夹用jmeter.bat 或jmeterw.bat启动应用程序。初始用户界面如图1所示。

图1：启动Apache JMeter

创建负载测试

使用Jmeter的负载测试功能，可以在服务器上产生高负载并确定其容量和限制。注意：若要使用Web services样本，需要有可用的mail.jar和activation.jar，它们可从Sun Microsystems中获取（请参阅下面的链接）。由于授权限制，Apache没有分发这些库。下载这两个jar文件之后，将它们放入Java classpath或安装Jmeter的lib目录中。

图2：创建线程组和基本Web Services测试计划

现在，右键单击Test Plan并添加Thread Group和Loop Controller。我们使用这两个元件来设置模拟的并发用户数和测试持续时间。在树状结构的Loop Controller下面，添加“WebService (SOAP) Request”和Graph，如图2所示。如果不能向测试计划添加WebService请求，则可能是路径中没有mail.jar或activation.jar。

键入线程数、等候周期和循环数。在本教程中我们分别使用5、10和100。将循环控制器计数设置为1。如果配置了Web Services的WebLogic Server仍然没有运行，请手动启动它或从WebLogic Workshop中启动。

配置负载测试

如图3所示，我们需要对发送到服务器的SOAP请求参数进行设置。如果指向WSDL文件的链接（URL)可用，将该链接粘贴到WSDL URL字段并单击Load WSDL。可用的方法将显示在Web Methods组合框中。接下来，需要单击Configure以便填充Server Name或IP、Port Number、Path和SOAPAction。

图3：WebService（SOAP）请求对话框（单击图像查看完整尺寸的屏幕截图）

如果没有可用的WSDL链接，也可以手动键入服务器名称、端口号、路径和SOAP操作的值。最后一步，在SOAP/XML-RPC Data区域填写SOAP请求。用户也可以通过SOAP XML Data选项用File从文件中加载。

输入Web Services请求对话框中的所有字段之后，单击Ctrl+S保存JMeter项目。为了使数据可视化，我们添加了图表元件“Graph results”和“Spline Visualizer”。此外，我们也可以通过添加“Save responses to a file”元件将响应发送到文件；这在检查SOAP响应错误时很有用。为了模拟更真实的客户端请求顺序，我们在树中插入了定时器元件——“Gaussian Random timer”。执行该操作之后，客户端的请求的分布更加混乱，将会以随机方式而不是以相等的时间间隔来点击服务器。我们将Gaussian随机时间设置为偏离100ms，恒定延迟偏移量为300ms.

运行负载测试

用户可以通过单击Ctrl+R运行负载测试，或者从菜单中选择Run并单击Start运行负载测试。单击图形元件，将会看到图表被填充，数据代表对服务器的请求，如图4至6所示。

图4：说明测试结果的图表。线程数＝5，等候时间＝10，循环数＝100。循环控制器设置为1。

我们选择在图表中显示三个参数——吞吐量（绿线）、中间值（紫线）和平均值（蓝线）。我们对测试参数进行修改。为了模拟服务器上的较高负载，我们将线程数提高到10和50并比较服务器的响应时间。再次单击Start并观查图表中显示的结果；参见图5和图6。

图5：说明测试结果的图表。线程数＝50，等候时间＝5，循环数＝20，循环控制器设置为1。

图表底部参数的含义如下：

吞吐量是服务器每分钟处理的请求数。
　平均值是总运行时间除以发送到服务器的请求数。
　中间值是代表时间的数字，有一半的服务器响应时间低于该值而另一半高于该值。
　偏离表示服务器响应时间变化、离散程度测量值的大小，或者，换句话说，就是数据的分布。
　最后的样本就是最后完成的请求。

只要观察这三次运行及它们的相应图表，我们就可以得到下列有价值的结果：

响应时间很明显地随着线程的增加而增加。若要继续进行测试，我们可以更改线程数、等候周期和循环数。注意：我们没有更改或调整服务器的配置。WebLogic Server 9.0中有一个可自动配置的线程池，其配置范围受到限制（请参阅Naresh Revanuru撰写的 Workload Management in WebLogic Server 9.0 ，Dev2Dev），上表说明客户端数量的增长对服务器响应时间的影响是非线性的。实际上，将这个数字提高两倍或十倍不会产生明显的影响！然而，使用接近或超过默认服务器限制的线程数来运行同一个试验时应引起注意。为了检验从服务器收到的响应是真实的SOAP响应而不是HTTP错误，我们观察下列输出文件的内容。这是符合上面要求的SOAP响应：

<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header/>
<soapenv:Body>
<m:calculateAreaResponse xmlns:m="http://myservice">
<m:return>12</m:return>
</m:calculateAreaResponse>
</soapenv:Body>
</soapenv:Envelope>

为了使测试结果更加可视化，向计划中添加Spline Visualizer，它紧靠着Graph Results。Spline Visualizer提供了关于所有样本次数的视图。它用分段插入功能绘制出一条连续的线，在绘制时跨越10个点，每个点代表10﹪的样本。在样条图表中用直线取代连接点，提供了基于多项式近似算法的平滑分布视图。结果如图7所示

图6：使用Spline Visualizer说明与图6相同测试结果的图表（单击图像查看完整尺寸的屏幕截图）

Multiple JMeters

JMeter还具有一项十分有用的Remote Start功能，它允许用户从多台机器启动JMeter测试。客户端主机地址可以输入到位于bin文件夹下的“jmeter.properties”文件中。找到remote_hosts属性并在那里添加远程主机名称，使用逗号进行分隔。重新启动Jmeter，在Run菜单中单击Remote Start或Remote Start All。某些Web和应用程序服务器可连续处理同一个IP地址的多个请求以及并行处理不同IP地址的请求，因此，对于请求来自不同的机器或将测试负载分布到几个客户端显得十分关键的情况，可以使用该选项来执行操作。

web_url
语法：
        Int Web_url(const char *name, const char * url, <Lists of Attributes>, [EXTRARES,<Lists of Resource Attributes>,LAST)

返回值
        成功时返回LR_PASS (0)，失败时返回 LR_FAIL (1)。

参数：
        Name：VuGen中树形视图中显示的名称，在自动事务处理中也可以用做事务的名称。

        url：页面url地址。

        List of Attributes：（支持下列属性）

        1 TargetFrame

        2 TargetBrowser or TargetBrowserOrdinal

        3 RecContentType  - 在录制期间响应的报头文本类型（text/html, application/x- javascript），这是为了确认目标URL是否是可录制的资源。
        4 Referer - 要提交页面请求的URL .（获得当前页面，如果明确指出了位置，那么这个属性无效或者忽略。URL中写明了，要获取的页面）
        5 Resource - 指定一个值说明这个URL是否是一个资源，0 表示不是资源，1 表示是资源
        6 Snapshot  -  快照，快照文件名称，用来关联用的。
        7 Mode  - 录制的等级，是否是HTML或者HTTP模式。

        EXTRARES：分隔符，表示下列列表，是由script、active、java applet、flash产生的请求（具体设置在，Recorded options --Recording--选择 html base scritp --- html Reccorded  可以设置是否需要录制这些东西。）。

        List of Resource Attributes：下载的资源属性

URL The URL (Uniform. Resource Locator) of the web resource to load
通过URL地址（资源统一定位器）要下载的web资源
Referer The URL of the referring web page.
发送下载请求的页面。比如一个swf要下载一个图片，那么swf就是referer
ENDITEM A marker that indicates the end of each resource in the list.
列表中每个资源的结束标志符


        LAST：属性列表结束的标记符。



说明
        Web_url根据函数中的URL属性加载对应的URL，不需要上下文。

        

        可以使用web_url 模拟从FTP服务器上下载文件。web_url 函数会使FTP服务器执行文件被真实下载时的操作。除非手工指定了"FtpAscii=1"，下载会以二进制模式完成。

        在录制选项中，Toos—Recording Option下，Recording选项中，有一个Advanced HTML选项，可以设置是否录制非HTML资源，只有选择了“Record within the current script. step”时，List of Resource Attributes才会被录制到。非HTML资源的例子是gif和jpg图象文件。

        通过修改HTTP头可以传递给服务器一些附加的请求信息。使用HTTP头允许请求中包含其他的内容类型（Content_type），象压缩文件一样。还可以只请求特定状态下的web页面。

        所有的Web Vusers ，HTTP模式下的WAP Vusers或者回放模式下的Wireless Session Protocol（WSP），都支持web_url函数。

这两个函数均用于内容的查找，但两者也有本质的区别，具体介绍如下：

一、web_find（）函数

该函数的作用是“在页面中查找相应的内容”，常用参数及含义如下：

web_find("web_find", //定义该查找函数的名称
%vR`}1}0 "RightOf=a", //定义查找字符的右边界

"LeftOf=b", //定义查找字符的左边界

"What=name", //定义查找内容

LAST);

使用该函数注意以下事项：

1、 位置

该函数在页面内容显示出来以后，在页面中进行查找，所以只能写在要查找内容之后

2、 录制模式

该函数只能在基于HTML模式录制的脚本中进行查找

3、 必须启用内容检查选项

在runtime setting->Preferences里面，把Enable image and text check选中，否则不执行该查找函数

4、 在VB和JAVA语法中不支持该函数

该函数有以下一个缺点：

1、 执行效率较低

2、 不返回查找结果情况，如想在执行该函数后根据查找结果做进一步操作时，没有返回值可以依据

例如：

在页面中查找“登录成功”的字符串，如果找到该字符串在日志中输出“登录成功”，如果找不到该字符串，则在日志中输出“登录失败”，此时使用该函数没有依据来做此判断，但使用web_reg_find()函数，使用它其中的SaveCount可以进行判断，具体方法我们下面介绍。

转载请注明出处：http://www.51testing.com/?41972

二、web_reg_find（）函数

该函数的作用是“在缓存中查找相应的内容”，常用参数及含义如下：

web_reg_find("Search=Body", //定义查找范围

"SaveCount=ddd", //定义查找计数变量名称

"Text=aaaa", //定义查找内容

LAST);

使用该函数注意以下事项：

1、 位置

该函数写在要查找内容的请求之前，通常情况下写在如下六个函数之前：

Web_castom_request();web_image();web_link();web_submit_data();web_submit_form();web_url()

2、 使用技巧

在该函数的参数中有个“SaveCount”，该参数可以记录在缓存中查找内容出现的次数，我们可以使用该值，来判断要查找的内容是否被找到，下面举个例子来说明：（引用LR的帮助中的例子）

// Run the Web Tours sample

web_url("MercuryWebTours",

"URL=http://localhost/MercuryWebTours/",

"Resource=0",

"RecContentType=text/html",

"Referer=",

"Snapshot=t1.inf",

"Mode=HTML",

LAST);

// Set up check for successful login by looking for "Welcome"

web_reg_find("Text=Welcome",

"SaveCount=Welcome_Count",

LAST);

// Now log in

web_submit_form("login.pl",

"Snapshot=t2.inf",

ITEMDATA,

"Name=username", "Value=jojo", ENDITEM,

"Name=password", "Value=bean", ENDITEM,

"Name=login.x", "Value=35", ENDITEM,

"Name=login.y", "Value=14", ENDITEM,

LAST);

// Check result

if (atoi(lr_eval_string("{Welcome_Count}")) > 0){ //判断如果Welcome字符串出现次数大于0

lr_output_message("Log on successful."); }//在日志中输出Log on successful

else{ //如果出现次数小于等于

lr_error_message("Log on failed"); //在日志中输出Log on failed

return(0); }

我觉得这个方法非常有用，我们可以举一反三，应用到我们实际的项目中

转载请注明出处：http://www.51testing.com/?41972

三、插入函数的方法

1、 手工写入，在需要插入函数的位置手工写入该函数

2、 光标停留在要插入函数的位置，在INSERT菜单中，选择new step，在列表中选择或查找要插入的函数，根据提示填写必要的参数

3、 在tree view模式下，在树状菜单中选中要插入函数的位置，右键，选择insert after或insert before，根据提示填写必要的参数

四、总结

1、 这两个函数函数类型不同，WEB_FIND是普通函数，WEB_REG_FIND是注册函数

2、 WEB_FIND使用时必须开启内容检查选项，而WEB_REG_FIND则不没有此限制

3、 WEB_FIND只能只用在基于HTML模式录制的脚本中，而WEB_REG_FIND没有此限制

4、 WEB_FIND是在返回的页面中进行内容查找，WEB_REG_FIND是在缓存中进行查找

5、 WEB_FIND在执行效率上不如WEB_REG_FIND

功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。针对Web系统的常用测试方法如下：      

1. 页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。可以使用一些工具，如LinkBotPro、File-AIDCS、HTML Link Validater、Xenu等工具。LinkBotPro不支持中文，中文字符显示为乱码；HTML Link Validater只能测试以Html或者htm结尾的网页链接；Xenu无需安装，支持asp、do、jsp等结尾的网页，xenu测试链接包括内部链接和外部链接，在使用的时候应该注意，同时能够生成html格式的测试报告。如果系统用QTP进行自动化测试，也可以使用QTP的页面检查点检查链接。

2. 相关性检查：功能相关*：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确，常见的情况是，增加某个数据记录以后，如果该数据记录某个字段内容较长，可能会在查询的时候让数据列表变形。
数据相关*：下来列表默认值检查，下来列表值检查，如果某个列表的数据项依赖于其他模块中的数据，同样需要检查，比如，某个数据如果被禁用了，可能在引用该数据项的列表中不可见。

3. 检查按钮的功能是否正确：如新建、编辑、删除、关闭、返回、保存、导入，上一页，下一页，页面跳转，重置等功能是否正确。常见的错误会出现在重置按钮上，表现为功能失效。

4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度。还要检查需求规定的字符串长度是否是正确的，有时候会出现，需求规定的字符串长度太短而无法输入业务数据。

5. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型。

6. 标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键。看系统处理是否正确。常见的错误是系统对空格的处理，可能添加的时候，将空格当作一个字符，而在查询的时候空格被屏蔽，导致无法查询到添加的内容。

7．特殊字符检查：输入特殊符号，如@、#、$、%、!等，看系统处理是否正确。常见的错误是出现在% ‘ " 这几个特殊字符

8. 中文字符处理: 在可以输入中、英文的系统输入中文,看会否出现乱码或出错。

9. 检查信息的完整*: 在查看信息和更新信息时,查看所填写的信息是不是全部更新,更新信息和添加信息是否一致。要注意检查的时候每个字段都应该检查，有时候，会出现部分字段更新了而个别字段没有更新的情况。

10. 信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理。

11. 检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按“delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除, 看是否正确处理。如果有多页，翻页选，看系统是否都正确删除，并且要注意，删除的时候是否有提示，让用户能够更正错误，不误删除。

12. 检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.

13. 检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.

14. 重复提交表单：一条已经成功提交的纪录，返回后再提交，看看系统是否做了处理。对于Web系统来说，可以通过浏览器返回键或者系统提供的返回功能。

15. 检查多次使用返回键的情况: 在有返回键的地方,返回到原来页面,重复多次，看会否出错。

16. 搜索检查: 有搜索功能的地方输入系统存在和不存在的内容,看搜索结果是否正确.如果可以输入多个搜索条件,可以同时添加合理和不合理的条件,看系统处理是否正确，搜索的时候同样要注意特殊字符，某些系统会在输入特殊字符的时候，将系统中所有的信息都搜索到。

17. 输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方。

18. 上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。下载文件能否打开或者保存，下载的文件是否有格式要求，如需要特殊工具才可以打开等。上传文件测试同时应该测试，如果将不能上传的文件后缀名修改为可以上传文件的后缀名，看是否能够上传成功，并且，上传文件后，重新修改，看上传的文件是否存在。

19. 必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加“*”；对必填项提示返回后，焦点是否会自动定位到必填项。

20. 快捷键检查：是否支持常用快捷键，如Ctrl+C、 Ctrl+V、 Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。

21. 回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错。这个地方很有可能会出现错误。

22．刷新键检查：在Web系统中，使用浏览器的刷新键，看系统处理如何，会否报错。

23．回退键检查：在Web系统中，使用浏览器的回退键，看系统处理如何，会否报错。对于需要用户验证的系统，在退出登录后，使用回退键，看系统处理如何；多次使用回退键，多次使用前进键，看系统如何处理。

24．直接URL链接检查：在Web系统中，直接输入各功能页面的URL地址，看系统如何处理，对于需要用户验证的系统更为重要。如果系统安全性设计的不好，直接输入各功能页面的URL地址，很有可能会正常打开页面。

25．空格检查：在输入信息项中，输入一个或连串空格，查看系统如何处理。如对于要求输入整型、符点型变量的项中，输入空格，既不是空值，又不是标准输入。

26．输入法半角全角检查：在输入信息项中，输入半角或全角的信息，查看系统如何处理。如对于要求输入符点型数据的项中，输入全角的小数点（“。”或“．”，如４．５）；输入全角的空格等。

27．密码检查：一些系统的加密方法采用对字符Ascii码移位的方式，处理密码加密相对较为简单，且安全性较高，对于局域网系统来说，此种方式完全可以起到加密的作用，但同时，会造成一些问题，即大于128的Ascii对应的字符在解密时无法解析，尝试使用“uvwxyz”等一些码值较大的字符作为密码，同时，密码尽可能的长，如17位密码等，造成加密后的密码出现无法解析的字符。

28．用户检查：任何一个系统，都有各类不同的用户，同样具有一个或多个管理员用户，检查各个管理员之间是否可以相互管理，编辑、删除管理员用户。同时，对于一般用户，尝试删除，并重建同名的用户，检查该用户其它信息是否重现。同样，提供注销功能的系统，此用户再次注册时，是否作为一个新的用户。而且还要检查该用户的有效日期，过了有效日期的用户是不能登录系统的。容易出现错误的情况是，可能有用户管理权限的非超级管理员，能够修改超级管理员的权限。

29．系统数据检查：这是功能测试最重要的，如果系统数据计算不正确，那么功能测试肯定是通不过的。数据检查根据不同的系统，方法不同对于业务管理平台，数据随业务过程、状态的变化保持正确，不能因为某个过程出现垃圾数据，也不能因为某个过程而丢失数据。

30．系统可恢复性检查：以各种方式把系统搞瘫，测试系统是否可正常迅速恢复。

31．确认提示检查：系统中的更新、删除操作，是否提示用户确认更新或删除，操作是否可以回退（即是否可以选择取消操作），提示信息是否准确。事前或事后提示，对于Update或Delete操作，要求进行事前提示。

32．数据注入检查：数据注入主要是对数据库的注入，通过输入一些特殊的字符，如“’”，“/”，“-”等或字符组合，完成对SQL语句的破坏，造成系统查询、插入、删除操作的SQL因为这些字符而改变原来的意图。如select * from table where id = ‘’ and name = ‘ ’，通过在id输入框中输入“12’-”，会造成查询语句把name条件注释掉，而只查询id=12的记录。同样，对于update和delete的操作，可能会造成误删除数据。当然还有其它一些SQL注入方法，具体可以参考《SQL应用高级SQL注入.doc》，很多程序都是基于页面对输入字符进行控制的，可以尝试跳过界面直接向数据库中**数据，比如用Jmeter，来完成数据注入检查。

33．刷新检查：web系统中的WebForm. 控件实时刷新功能，在系统应用中有利有弊，给系统的性能带来较大的影响。测试过程中检测刷新功能对系统或应用造成的影响（白屏），检查控件是否回归默认初始值，检查是否对系统的性能产生较大影响（如每次刷新都连接数据库查询等）。

34．事务检查：对于事务性操作，断开网络或关闭程序来中断操作，事务是否回滚。

35．时间日期检查：时间、日期验证是每个系统都必须的，如2006-2-29、2006-6-31等错误日期，同时，对于管理、财务类系统，每年的1月与前一年的12月（同理，每年的第1季度与前一年的第4季度）。另外，对于日期、时间格式的验证，如2006年2月28日、2006-2-28、20060228等。日期检查还要检查日期范围是否符合实际的业务，对于不符合时间业务的日期，系统是否会有提示或者有限制。

36．多浏览器验证：越来越多的各类浏览器的出现，用户访问Web程序不再单单依赖于Microsoft Internet Explorer，而是有了更多的选择：Maxthon、Firefox、Tencent Traveler等，考虑使用多种浏览器访问系统，验证效果。

37．安装测试：对于C/S架构的系统，安装程序的测试是一个重要方面，安装程序自动化程度、安装选项和设置（验证各种方案是否都能正常安装）、安装过程中断测试、安装顺序测试（分布式系统）、修复安装及卸载测试。

38．文档测试：主要是对用户使用手册、产品手册进行测试，校验是否描述正确、完整，是否与当前系统版本对照，是否易理解，是否二义性等。

39．测试数据检查：事实告诉我们，测试数据比代码更有可能是错的，因此，当测试结果显示有错误发生的时候，怀疑代码错误前要先对测试数据检查一遍。

40．请让我的机器来运行：在某些项目中，出现一个病态的问题：系统没有问题呀，它在我的机器上是能够通过的。这就说明了其中存在着和环境相关的BUG。“是否所有的一切都受到了版本控制工具的管理？”、“本机的开发环境和服务器的环境是否一样？”、“这里是否存在一个真正的BUG，只不过是在其他的机器里偶然出现？”。所有的测试必须在所有系统要求的机器上运行通过，否则的话，代码就可能存在问题。

41．Ajax技术的应用：Ajax有很多优点，但也有很多缺点，如果利用优点、避免缺点，是我们对新的Web2.0应用的一个挑战。而Ajax的应用最直接的问题就是用户体验，用户体验的效果直接关系到是否使用Ajax技术。“会做，并不意味着应该做、必须做”，这就是对Ajax技术的很重要的注解。

42．Ajax技术的应用：Ajax采用异步调用的机制实现页面的部分刷新功能，异步调用存在异常中断的可能，尝试各种方法异常中断异步的数据调用，查看是否出现问题。在这里遇到的一个问题就是对日期控件的操作，已经如果页面数据较多的时候的刷新。

43．脚本错误：随着Ajax、IFrame等异步调用技术的发展，Javascrīpt技术也越来越受到开发人员的重视，但Javascrīpt存在调试困难、各浏览器存在可能不兼容等问题，因此在Web系统中，可能会出现脚本错误。同时，脚本错误造成的后果可大、可小，不能忽视。

 初来公司，就获悉公司一直在用bugzillia来进行测试管理。但目前跟测试搭边的，只是利用了bugzilliar进行项目提测，bug提交分配管理。而并没有真正做到对bug真正意义上的管理，而且也没有对测试用例进行有效管理。而目前采用的还是老套的EXCEL来进行管理。由于牵涉到和开发以及产品等其它部门的流程，如果需要更换测试管理工具，想必会对整个公司的技术部做一个大手术，除了需要说服测试部门，还需要说服其它部门老大。之前也力推了一下最简单的bugfree，但还是因为种种原因没有被实施起来。 不过还是 畅想一下，如果采用测试用例管理工具，势必会对测试模块的划分，测试用例的索引，测试用例的执行跟踪功能等带来一定的收益。


现在整理了一些测试管理工具，面对如此众多的bug管理工具，你愿意选择哪个呢？

Bugzilla是一个错误跟踪系统，用于对软件产品程序开发过程的错误跟踪。它的强大功能表现在以下几个方面：

1.         强大的检索功能

2.         用户可配置的通过Email公布Bug变更

3.         历史变更记录

4.         通过跟踪和描述处理Bug

5.         附件管理

6.         完备的产品分类方案和细致的安全策略

7.         安全的审核机制

8.         强大的后端数据库支持

9.         Web，Xml，Email和控制界面

10.     友好的网络用户界面

11.     丰富多样的配置设定

12.     版本间向下兼容

为什么使用Bugzilla

Bugzilla是一个拥有强大功能的错误跟踪系统。它可以使我们更好的在软件开发过程中跟踪软件错误的处理过程，为开发和测试工作以及产品质量的度量提供数据支持，从而有效的保证软件产品的质量。

 

Bugzilla使用指南

新建一个Bugzilla账号

1.       点击“Open a new Bugzilla account”链接，输入你的Email地址（如：XXX@office）然后点击“Create Account”。

2.       稍候，你会收到一封邮件。邮件中包含你的登录账号（与你的Email相同）和口令，这个口令时Bugzilla系统随机生成的，你可以根据你的需要进行变更。

3.         在页面的黄色页角中点击“Log In”链接，而后输入你的账号和口令。最后点击“Login”

产品和结构（Product and Component）

Bug记录按产品分类，每种产品按功能拆分成几类。以Bugzilla产品为例，它由以下几部分构成：

l          Administration

l          Bugzilla-General

l          Creating/Changing Bug

l          Documentation

l          Email

l          Installation

l          Query/Buglist

l          Reporting/Charting

l          User Accounts

l          Changing Passwords

l          User Interface

Bug报告状态分类和Bug处理意见（Status and Resolution）：

1.       Bug报告状态分类（Status）

l          待确认的（Unconfirmed）

l          新提交的（New）

l          已分配的（Assigned）

l          问题未解决的（Reopened）

l          待返测的（Resolved）

l          待归档的（Verified）

l          已归档的（Closed）

2.       Bug处理意见（Resolution）

l          已修改的（Fixed）

l          不是问题（Nvalid）

l          无法修改（Wontfix）

l          以后版本解决（Later）

l          保留（Remind）

l          重复（Duplicate）

l          无法重现（Worksforme）

指定处理人（Assigned To）

l          可以指定一个处理人

l          如不指定处理人，则系统指定管理员为默认处理人

超链接（URL）

l          输入超链接地址，引导处理人找到与报告相关联的信息

概述（Summary）

l          概述部分“Summary”的描述，应保证处理人在阅读时能够清楚提交者在进行什么操作的时候发现了什么问题。

l          如果是通用组件部分的测试，则必须将这一通用组件对应的功能名称写入概述中，以便今后查询。

硬件平台和操作系统（Platform. and OS）

l          测试应用的硬件平台（Platform），通常选择“PC”

l          测试应用的操作系统平台（OS）

版本（Version）

l          产生Bug的软件版本

Bug报告优先级（Priority）

l          分五个等级即P1-P5，P1的优先级别最高之后逐级递减

Bug状态（Severity）

l          Blocker，阻碍开发和/或测试工作

l          Critical，死机，丢失数据，内存溢出

l          Major，较大的功能缺陷

l          Normal，普通的功能缺陷

l          Minor，较轻的功能缺陷

l          Trivial，产品外观上的问题或一些不影响使用的小毛病，如菜单或对话框中的文字拼写或字体问题等等

l          Enhancement，建议或意见

报告人（Reporter）

l          Bug报告提交者的账号

邮件抄送列表（CC List）

l          Bug报告抄送对象，该项可以不填

l          如需要抄送多人，可将邮件地址用“，”分隔

从属关系（Bug “ID” depends on，Bug “ID” blocks）

l          “Bug “ID” depends on”如果该Bug必须在其他Bug修改以后才能够修改，则在此项目后填写那个Bug的编号

l          “Bug “ID” blocks”如果该Bug的存在影响了其他Bug的修改，则在此项目后填写被影响的Bug编号

附加描述（Additional Comments）

l          在Bug跟踪过程中测试与开发人员通过这里进行沟通

l          开发人员可以在这里填写处理意见和处理记录

l          测试人员可以在这里填写返测意见和对在返测过程中发现的新问题进行描述

Bug查找

l          可以通过页脚中的“Query”链接进入查找界面

l          根据查找的需要在界面中选择对象或输入关键字

l          查找功能能够进行字符或字串的匹配查找

l          查找功能具有布尔逻辑检索功能

l          你可以通过在查找页面中选择“Remember this as my default query”将当前检索页面中设定的项目保存。以后可以从页脚中的My bugs中直接调用这个项目进行检索

l          你还可以通过在“Remember this query, and name it:”后面输入字符，将你当前检索页面中设定的项目保存命名，同时选中“and put it in my page footer”。则以后这个被命名的检索将出现在页脚中。（有关如何在页脚中设定显示的项目请参见1.5.3）

Bug列表

l          如果你运行了Bug检索功能，系统会根据你的需要列出相关的项目

l          你可以通过列表页脚附近的“Change Columns”设定在列表中显示的Bug记录中的字段名称

l          如果你拥有必要的权限，你还可以通过“Change several bugs”修改列表中罗列出的Bug的记录。例如：修改Bug的所有者

l          通过“Send mail to bug owners”你可以给列表中罗列的Bug记录的所有者发信

l          如果你对查找的结果不满意，希望重新调整检索设定。你可以通过“Edit this query”实现

l          通常情况下，检索结果中只显示最基本的信息。你可以通过“Long Format”显示更详细的内容

用户属性设置（Edit prefs）

1           账号设置（Account Settings）

l          在这里你可以改变你账号的基本信息，如口令，Email地址，真实姓名

l          为了安全起见，在此页进行任何更改之前你都必须输入你当前的口令

l          当你变更了你的Email地址，系统会给你的新老Email地址分别发一封确认邮件，你必须到邮件中指定的地址对你的更改进行确认

2           Email设置（Email Settings）

l          你可以在此通过选择告诉系统，你希望在什么条件下收到和你相关的邮件

3           页脚（Page Footer）

l          设定“Preset Queries”是否在页脚中显示

4           用户权限（Permissions）

你可以在此查看自己账号现在的权限

在用户需求规格说明书中，会给出系统的功能、界面与性能的要求。规范的需求规格说明书都会给出明确的性能指标，比如单位时间内访问量要达到多少、业务响应时间不超过多少、业务成功率不低于多少、硬件资源耗用要在一个合理的范围中，这些指标都会以可量化的数据进行说明。如果，实际项目并没有这些正规的文档时，项目经理部署测试任务给测试组长时，一般就会说明是否要对项目的哪些业务模块进行性能测试，以及测试的要求是什么的。最麻烦的就是项目经理或者客户要求给出一个测试部门认为可以的数据，这样非常难做的。可是“甲方”往往都是提要求的，“乙方”只能“无条件”接受！

对于正规的项目，用户需求规格说明书中一般会给出类似表5- 1的性能测试要求：

测试项	响应时间	业务成功率	并发数	CPU使用率	内存使用率
用户登录	<=3秒	>98%	20	<75%	<75%

                                                            表5- 1需求规格说明书中的性能要求                  

表5- 1给出的指标非常明确，在测试过程中，我们只需收集用户登录模块的响应时间、登录成功率、并发数、CPU使用率、内存使用率的数据，然后与表5- 1的指标进行比较即可，通过的，就认为达到了客户要求的性能，未达到就分析原因，并给出测试报告及解决建议。

大多数是没有明确的需求，需要我们自己根据各种资料、使用各种方法去采集测试指标。以OA系统为例，假设《FIX OA系统需求规格说明书》中并未指明系统的性能测试要求，需要测试工程师自己分析被测系统及采集性能衡量指标。

分析OA系统的结构，所有功能中仅有考勤模块可能是被测系统最终用户经常使用的业务点，那么我们的重点应该在放在该模块上。一般我们可以从下面三个方面来确定性能测试点：

第一、              用户常用的功能。常用的功能一旦性能无法满足，比如登录功能，从输入用户名与密码点击登录按钮到显示成功登录信息，花了5分钟，这样的速度是人无法忍受的。而对于用户不常用的，比如年度报表汇总功能，三个季度甚至是一年才使用，等个10分钟也是正常的，这些是跟用户的主观感受相关的，得根据实际情况区分。

第二、              系统业务逻辑复杂，数据流转频繁的功能。这些地方最终用户可能看不到、用不到，但在系统是个关键点，没有它其他功能就不能正常工作，即使用户未提出做性能测试，作为测试部门也应该对这些地方进行性能测试，以保证他们能够正常工作。

第三、              与外部系统的接口处。有时候本系统需要使用其他系统的组件。我做过的一个项目，B/S结构的企业信息管理系统，其用户管理模块中的用户数据就是使用早期C/S结构的ERP系统。前一个使用Oracle数据，后一个是用Sybase数据，设定了每三个小时更新一下用户信息，以保证两个系统用户信息是一致的。这样的功能，也是应该做测试的，特别是涉及到多系统的。

综合考虑，与考勤模块相关的是登录模块，因为登录是考勤的前置条件，所以在实际的测试中不仅要测试考勤的，还应该考察登录模块的性能表现，尽管这不是用户要求的。

OA系统是一个面向广大企业用户的办公自动化系统。根据大多数公司的作息安排，早上九点基本是公司的上班时间。那么根据实际业务分析，早上8:40到9:10可能是OA系统登录的高峰期。因为很多人集中在这个时候达到公司进行考勤业务操作。这个时候，就可以确定系统测试的一个时间段了。接下来，需要调查一般会有多少人使用OA系统，这个数据比较难，应该公司的规模不一样，人数也就不一样。既然是面向公众，那么就可以由开发工程师给出一个参考值，比如开发工程师说可以支持2000 人同时使用，那么我们就将使用系统的人数定为2000人。既然说是2000人同时使用，我们可以理解为2000人在8:40到9:10这30分钟的时间里都要完成登录、考勤操作，并且不能有失败的业务。也就是说业务的成功率要求在100%。这样一来，到目前为止，得到了下面几个数据：

1、  OA系统使用高峰期为30分钟；

2、  并发使用人数为2000；

3、  登录、考勤成功率100%。

接着分析，在满足功能的同时，还需要考虑操作的响应时间。很多公司都有迟到处罚制度，我原来的公司迟到一分钟扣五块钱，有的公司甚至更狠。所以，如果应为页面反映慢而导致迟到，会“冤死”一批人，这样的问题绝对不能出现。那么响应时间为多少算正常呢？说实话，这样的问题本身就是有问题的，何谓快，何谓慢？都是主观判断，你心急的时候觉得它慢，不急的时候觉得它快，所以没有一个定论，按照业内一个经验值，就是2、5、8或者3、5区分。2秒或者3秒的功能结果响应时间是非常理想，5秒就有点让人觉得不爽了，而8秒，甚至更高很可能导致用户放弃操作，或者再次发起第二次请求。这样的经验值在实际测试中对我们确定响应时间有很高的参考价值，当然响应时间还应该根据业务类型定，而不能仅从用户的感官考虑。我们这里就采用常规的3秒为目标，也就是说OA系统处理登录、考勤业务的服务器响应时间不超过3秒。

除了软件的要求外，还应该对硬件资源进行监控，比如应用服务器的CPU使用率、内存使用率、带宽情况、Web服务器的资源使用情况等等，那么如果用户未提出要求，我们就按照常识走，CPU的使用率不超过75%，内存使用率不超过70%，其他指标这里就不列出了。之所以选择这两数值，是因为他们具有代表性。CPU的使用率超过75%可以说是繁忙，如果持续在90%甚至更高，很可能导致死机、机器响应超级慢等问题。如果过低也不好，说明CPU比较空闲，可能存在资源浪费的问题。对于内存存在同样的问题。

通过上面的分析，最终采集得到本次测试的性能参考指标如表5- 2所示：

表5- 2 OA系统性能参考指标

得出本次测试的性能参考指标后，我们就可以进行测试模型的建立了。

建立业务模型

得到性能测试参考指标后，再次分析OA系统的实际使用情况，我们可以进行测试模型的建立，也就是建模。所谓建模，就是建立用户业务模型。建模是性能测试的基础。只有建立合理有效的业务模型，才能模拟出真实的系统使用情况，才能找到今后可能发生的缺陷，所以建立恰当的业务模型是我们性能测试成功与否的关键。那如何建立用户业务模型呢？

根据上面的测试要求，我们需要测试OA系统登录与考勤两个模块的性能。这两个模块的使用方法是什么样的？用户又是怎么使用的？相对其他的业务系统而言，这里的功能比较简单了。登录功能很常见，输入用户名与密码，点击登录按钮即可完成登录操作。登录成功后，直接进入考勤页面，点击考勤按钮，即可完成考勤操作。所以，不需做太多的分析就能弄清楚这个过程。如果用流程图表示，则可表示为图5- 2。

图5- 2 OA系统考勤流程图

建立实际的业务模型如表5- 3所示：

表5- 3 OA系统考勤业务模型

经过分析测试要求与建立业务模型两步，基本上已经确定了本次测试的内容。大多数项目的性能测试分析都可以使用这样的方法。在分析与建模过程中，最重要的是要弄清楚当前测试的重点是什么，对应的业务流程是什么，就像我们做功能测试一样的，性能测试也需要在客户的实际应用基础上开展，否则脱离实际的测试是无效的。

评审确定指标

前面的两步仅是测试工程师的分析确定过程，并没有取得项目组的审核，要知道，在一个软件生产过程中，评审在每一个过程都应该存在。得到测试指标与模型后，就需要编写对应的性能测试计划或者性能测试方案，并提交项目进行审批。如果项目组没有这个要求，测试工程师也需告知项目经理、开发组长与测试组长，并要求得到反馈。我曾做过的一个移动项目，方案改了三次，局方经理才同意，尽管他们并没有提出什么要求，就是认为不妥，此时我们就必须不断调整，他不同意，我们就不能开展工作。所以，有时候这个评审可能是个形式，但也得做。一般在这个阶段会生成性能测试计划或者性能测试方案。后期的性能测试工作就按照这些文档开展。

1.入职时的工资高低不重要，只要你努力工作你会得到相应待遇的
　　我估计几乎找过工作的人都听过这句话，当我们确定被聘用跟公司谈工资时，他们都会说“如果以后你业绩突出、努力工作，你的报酬也会相应增加的”，特别是当第一次找工作的时候大多数人会相信这些话，但是千万～～别相信。
　　刚入职时，你的工资就是你的全部（当然有一些岗位，比如销售或弹性工资的岗位除外），而且你入职以后大部分待遇都会跟着你的工资而浮动，工资调整也是按你目前的工资乘于一定的百分比，保险、公积金也跟工资有关系，当你的基本工资低的时候你今后的报酬增长空间也不大。
　　所以，找工作时千万不要心软，多争取一些基本工资，因为这是你的所有。
　　我第一次找工作时就是犯了这个错误，当时心软没要求更高的工资，当时觉得基本工资比别人低几百块钱无所谓，但是后来才发现它有一个杠杆作用，尽管以后每年你工资涨幅比别人大，但是工资还是比别人低。
　　比如你入职时的基本工资为4000，第二年涨幅为20% （一般的企业极少数人能涨20%），那第二年工资为4800； 如果你的同事入职时基本工资为4500，第二年涨幅为10%（一般涨幅），那他第二年工资为4950。
　　是不是看到差距了？ 请记住，入职时工资就是你的全部，一定不能心软。

2.人事部不是你的倾谈对象
　　我在公司看过很多员工找人事部经理谈话，而且人事部员工可能会定期找员工谈话，问员工在工作中有没有遇到什么问题？ 有没有人事部需要帮员工解决的事情？
　　但是请你记住， 公司人事部并不是你的倾谈对象，人事部的首要任务不是去帮助雇员，而是保护公司利益不受雇员损害，这才是最为重要的。 可能很多人认为人事部门是自己的朋友，有时甚至连对公司、对老板的真实态度都会告知于人事部门。（如果你经常这样的话，我可以肯定的说，你会跌得很惨，而且不会有人告知你原因的）
　　无论人事部的人员表现得何等友好，你均要认清，你跟他们的谈话内容，他们必然会与决策部门分享这些信息，例如你的老板、经理、主管及首席执行官。人事部门的职责就是（有时也是合法的）告知公司决策部门你那些所谓的“ 秘密”。
　　比如你不喜欢你目前的工作内容、或与老板的关系处理的不好，你千万不能找人事部抱怨，你应该直接跟你的老板沟通。可能当时谈话时人事部的员工会给予同情，说自己向自己的上司反映这个情况，但是大多数情况下人事部门会将你与他们的对话原封不动地转达给你的老板，而你的老板对此是绝对无法原谅的，出现问题首先不去找老板解决，而是直接找到人事部门，这样你的处境就很被动了，有可能被迫离开公司了。



3.你的能力并不能确保你的安全
　　很多公司在招聘员工或对外宣传时说我们公司注重员工的能力，提倡员工能发挥自己的主观能动性 （确实有一些公司是提倡创新的，但是极少数，大部分都只是打打口号而已）。对于刚入职的员工来说可能都会有一种心理，那就是向同事或领导展示你的才华、展示你的能力，但是请注意： 公司或你的领导倒希望先看到你的忠诚，而不是显摆自己的能力。不管你的目的是什么，这个并不重要，如果你一贯展示你的能力，很有可能上司觉得你卖弄小聪明、是一个不值得信赖的人，或他会感受到威胁，如果他认为你在威胁他的位置，他才不管你有多聪明，他宁愿要一个愚笨但对自己忠诚的人。
　　所以，当你刚入职或刚调到一个新部门的时候，千万不能先自作聪明，你首先要做的是熟悉环境熟悉上司同事的性格，即使你是一个专家也要先摆低姿态，当然必要的是关键时刻也需要显示自己的能力，让别人觉得你是深藏不露。
　　韩国有一个俗语说“要想让婚姻生活幸福，就要当3年聋子，3年哑巴，3年盲人” ，因为以前在韩国婆婆对媳妇很是虐待，你必须是装聋作哑才能熬过去（当然现在已经不是这种情况了），我说这个的目的是新来乍到，你应该学会作哑装聋，刚开始多听、多学，听到闲言碎语要装聋。



4.报销单是公司测试你的一个工具
　　看到这个题目或许你会纳闷？报销单也能测试员工？是的，我们平时不以为常的报销单也是公司或领导测试你的一个工具。
　　大部分公司都会有月底报销（餐费、交通费、电话费等）或出差报销吧？
　　你让你的领导在你的报销单上签字的时候，他有没有说过什么？或他有没有做过什么表情？ 请注意，其实大部分情况下领导们都会看你报销的金额，而且如果他们愿意的话财务部门可以随时提供每个人的报销明细。
　　以前看过一些在公司里面贪小便宜的人，餐费、交通费里总是放着一些自己私人用的（而不是为了公司业务）费用，或许这些费用只有100元，但正是这些小钱会坏了你的前程。
　　我认识的一个老板跟我说过这样一句话：“某某员工哪天报了业务餐费，但是那天明明是我付款了。”或许这位员工太大意了。
　　但是我认识的老板当中也有一些人，他连你打的票上面的时间也核对，然后把属下每个员工的每月费用都记录下来，或许你报销的时候他可能不会说什么，但是到时候你丢掉的并不仅仅是金钱。



5.在工作场合中透露私事很危险
　　现在我们大部分人有太多时间跟同事一起过，我们跟同事在一起的时间有时甚至超过跟家人在一起的时间，这种情况使我们有时分不清公事和私事，有时候觉得跟同事的关系像亲人一样，跟同事分享自己的私事，孩子养育问题，个人健康问题，经济上遇到的一些困难等，但是请记住，职场就是职场，你这样做很危险。
　　我的一位同事经常在工作场合说他儿子现在是青春期，跟我们描述怎么怎么叛逆，由于儿子的叛逆，每天回家以后家里的氛围都很紧张，有可能他是想通过倾述减少来自家庭的压力，但是最近公司开始了一个重大的项目，他一直以为自己是最佳候选人负责这个项目，但是结果令人意外，公司领导层选了其他人选，为什么呢？因为公司领导层觉得“他家里的事情已经够多了，估计他没有余力做这么重要的项目”或讲得更冷静一点就是“你连自己家里的事情都解决不了，你还能负责这么重要的项目吗？”
　　如果你自己身体不太好，不需要把自己的健康情况告诉同事或上司，因为对上司来说你不健康说明你不能百分之百投入或有可能影响工作，这样你的上司会不安，他甚至会提前想对策或再额外招人，这样的话到时候即使你的身体恢复了，你有可能会面临失去自己位置的尴尬局面。

sql server 中的一些实用的sql语句

 

简介
        在这篇文章中，我列举一些sql语句来介绍数据库，数据表，视图等等。当我们在使用查询查询操作时这些sql语句都是非常有用的。虽然在sql server对象浏览器中我们也可以获得这些语句，但是如果我们写这些语句时我们可以将它自定义。这就意味着我们可以给予自己的需求来过滤结果。

 

sql语句列表
如何列举sql server当前连接的可用数据库

Method 1 : SP_DATABASES 
Method 2 : SELECT name FROM SYS.DATABASES 
Method 3 : SELECT name FROM SYS.MASTER_FILES 
Method 4 : SELECT * FROM SYS.MASTER_FILES -- Type=0 for .mdf and type=1 for .ldf
SP_DATABASES是一个可以列举数据库及其大小的存储过程

sys.databases语句中可以列举数据库名称，创建日期，修改日期，已经数据库id和其他一些信息。

SYS.MASTER_FILES语句可以查询数据的详细情况，比如数据库id，大小，物理存储路径以及列举数据库mdf和ldf.

 

如何列举数据库中的数据表

以下的sql语句都可以列表sql server数据库中的用户表.

Method 1 : SELECT name FROM SYS.OBJECTS WHERE type='U' 
Method 2 : SELECT NAME FROM SYSOBJECTS WHERE xtype='U' 
Method 3 : SELECT name FROM SYS.TABLES 
Method 4 : SELECT name FROM SYS.ALL_OBJECTS WHERE type='U' 
Method 5 : SELECT table_name FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE='BASE TABLE' 
Method 6 : SP_TABLES

如何列举数据库中的存储过程

Method 1 : SELECT name FROM SYS.OBJECTS WHERE type='P' 
Method 2 : SELECT name FROM SYS.PROCEDURES 
Method 3 : SELECT name FROM SYS.ALL_OBJECTS WHERE type='P' 
Method 4 : SELECT NAME FROM SYSOBJECTS WHERE xtype='P' 
Method 5 : SELECT Routine_name FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_TYPE='PROCEDURE'
SYS.OBJECTS数据表包含了全部的存储过程，数据表，触发器，视图等的信息，这里使用type=’p'来查询存储过程.

Information_schema.routines在sql server 7.0是一个数据视图，在其后的版本中已经变成存储过程专有的表.

 

如何列举数据库中的触发器

Method 1 : SP_HELPTRIGGER Products 
Method 2 : SELECT * FROM SYS.TRIGGERS WHERE parent_id = object_id('products')

下面我以一个products表为例列举一些对表的操作.

如何获取数据表中的列

Method 1 : SP_HELP Products 
Method 2 : SP_COLUMNS Products 
Method 3 : SELECT * FROM SYS.COLUMNS WHERE object_id = object_id('Products') 
Method 4 : SELECT COLUMN_NAME,Ordinal_position,Data_Type,character_maximum_length FROM                      INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME='Products'

如何根据数据表的列查找数据表的名称

Method 1 : SELECT O.name FROM SYS.OBJECTS O INNER JOIN SYS.COLUMNS C ON C.Object_ID = O.Object_ID  WHERE C.name LIKE '%ShipName%' 
Method 2 : SELECT OBJECT_NAME(object_id) AS [Table Name] FROM SYS.COLUMNS WHERE name LIKE '%ShipName%' 
Method 3 : SELECT TABLE_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE COLUMN_NAME LIKE '%ShipName%'

如何获得数据视图的模式定义

Method 1 :  SELECT OBJECT_NAME(id) AS [View Name],text FROM SYSCOMMENTS WHERE id IN (SELECT object_id FROM SYS.VIEWS) 
Method 2 : SELECT * FROM sys.all_sql_modules WHERE object_id IN (SELECT object_id FROM SYS.VIEWS) 
Method 3 : SP_HELPTEXT ViewName

 

总结
以上列举了一下sql server用实用的一些sql语句，希望对你在使用查询窗口操作时有用。

动态链接库的编写

在Visual C++6.0开发环境下，打开FileNewProject选项，可以选择Win32 Dynamic-Link Library建立一个空的DLL工程。

1． Win32 Dynamic-Link Library方式创建Non-MFC DLL动态链接库每一个DLL必须有一个入口点，这就象我们用C编写的应用程序一样，必须有一个WINMAIN函数一样。在Non-MFC DLL中DllMain是一个缺省的入口函数，你不需要编写自己的DLL入口函数，用这个缺省的入口函数就能使动态链接库被调用时得到正确的初始化。如果应用程序的DLL需要分配额外的内存或资源时，或者说需要对每个进程或线程初始化和清除操作时，需要在相应的DLL工程的.CPP文件中对DllMain ()函数按照下面的格式书写。

BOOL APIENTRY DllMain(HANDLE hModule,DWORD ul_reason_for_call,LPVOID lpReserved)

{

switch( ul_reason_for_call )

{

case DLL_PROCESS_ATTACH:

break;

case DLL_THREAD_ATTACH:

break;

case DLL_THREAD_DETACH:

break;

case DLL_PROCESS_DETACH:

break;

default:

break;

}

return TRUE;

}

参数中，hMoudle是动态库被调用时所传递来的一个指向自己的句柄(实际上，它是指向_DGROUP段的一个选择符)； ul_reason_for_call是一个说明动态库被调原因的标志，当进程或线程装入或卸载动态链接库的时候，操作系统调用入口函数，并说明动态链接库被调用的原因，它所有的可能值为：DLL_PROCESS_ATTACH: 进程被调用、DLL_THREAD_ATTACH: 线程被调用、DLL_PROCESS_DETACH: 进程被停止、DLL_THREAD_DETACH: 线程被停止；lpReserved为保留参数。到此为止，DLL的入口函数已经写了，剩下部分的实现也不难，你可以在DLL工程中加入你所想要输出的函数或变量了。

我们已经知道DLL是包含若干个函数的库文件，应用程序使用DLL中的函数之前，应该先导出这些函数，以便供给应用程序使用。要导出这些函数有两种方法，一是在定义函数时使用导出关键字_declspec(dllexport)，另外一种方法是在创建DLL文件时使用模块定义文件.Def。需要读者注意的是在使用第一种方法的时候，不能使用DEF文件。下面通过两个例子来说明如何使用这两种方法创建DLL文件。

1）使用导出函数关键字_declspec(dllexport)创建MyDll.dll，该动态链接库中有两个函数，分别用来实现得到两个数的最大和最小数。在MyDll.h和MyDLL.cpp文件中分别输入如下原代码：

//MyDLL.h

extern "C" _declspec(dllexport) int desinit(int mode);

extern "C" _declspec(dllexport) void desdone(void);

extern "C" _declspec(dllexport) void des_setkey(char *subkey, char *key);

extern "C" _declspec(dllexport) void endes(char *block, char *subkey);

extern "C" _declspec(dllexport) void dedes(char *block, char *subkey);

//MyDll.cpp

#include"MyDll.h"

//这里我用了比较大小的函数代替了我要实现的函数

int desinit(int a, int b)

{

if(a>=b)return a;

else

return b;

}

int desdone(int a, int b)

{

if(a>=b)return b;

else

return a;

}

该动态链接库编译成功后，打开MyDll工程中的debug目录，可以看到MyDll.dll、MyDll.lib两个文件。LIB文件中包含DLL文件名和DLL文件中的函数名等，该LIB文件只是对应该DLL文件的"映像文件"，与DLL文件中，LIB文件的长度要小的多，在进行隐式链接DLL时要用到它。读者可能已经注意到在MyDll.h中有关键字"extern C"，它可以使其他编程语言访问你编写的DLL中的函数。

LoadRunner调用动态链接库

上面完成动态链接库开发后，下面就介绍动态链接库如何被LoadRunner进行调用，其实也是很简单的。在LoadRunner中的DLL调用有局部调用与全局调用，下面介绍局部调用。

首先把你编译的DLL放在角本路径下面，这里是MyDll.dll,MyDll.lib.然后在Action中使用

lr_load_dll("MYDll.dll")，此函数可以把DLL加载进来，让你调用DLL里面的函数，而DLL中的运算是编译级的，所以效率极高，代码样例如下：

#include "lrs.h"

Action()

{

//

int nRet = 6;

char srckey[129];

memset(srckey, 'a', 128);

lr_message(lr_eval_string(srckey));

lr_load_dll("MyDLL.dll");

nRet = desinit(5,8);

lr_message("比较的结果为%d",nRet);

return 0;

}

运行结果

比较的结果为8

全局的动态链接库的调用则需要修改mdrv.dat，路径在LoadRunner的安装目录下面（LoadRunner/dat directory）；在里面修改如例：

[WinSock]

ExtPriorityType=protocol

WINNT_EXT_LIBS=wsrun32.dll

WIN95_EXT_LIBS=wsrun32.dll

LINUX_EXT_LIBS=liblrs.so

SOLARIS_EXT_LIBS=liblrs.so

HPUX_EXT_LIBS=liblrs.sl

AIX_EXT_LIBS=liblrs.so

LibCfgFunc=winsock_exten_conf

UtilityExt=lrun_api

ExtMessageQueue=0

ExtCmdLineOverwrite=-WinInet No

ExtCmdLineConc=-UsingWinInet No

WINNT_DLLS=user_dll1.dll, user_dll2.dll, ...

//最后一行是加载你需要的DLL

这样你就可以在LR中随意的调用程序员写的API函数，进行一些复杂的数据加密，准备的一些操作进行复杂的测试.同时如果你觉的有大量高复杂的运算也可以放在DLL中进行封装，以提高效率。

沉浮于LR很多天了，以前一直在WR分论坛漂。看到大家提出很多问题，不过发现大家的脚本大都已录制为主，而且经常有提出录制的脚本回放有问题，其实很多问题很好解决，LR提供了很多手段调试和优化我们的脚本。
1.设置断点
相信大家都不陌生，LR也是可以设置断点的，在需要设置断点的语句前按F9快
捷键，断点就设置好了，程序运行到断点语句后会暂停,这时我们可以用F10单步
调试程序.
2.打开EXtended Log
只是设置断点是不够的,我们还得知道具体发生了什么事情,Log告诉了我们一切,默认的Log是 standard Log,这时远远不够的.我们要extended log,打开路径
为runtime settings-->log-->extended log.把parameter substitution和data returned by server和advanced trace大家根据需要勾选吧.
3.注释掉多余的语句
很多回放时出错的脚本都是因为多余的语句.因为LR在录制的时候,LR生成的语
句很多不是我们想要的,这里结合几个网友的问题说说,曾有网友问:回放脚本的时
候socket出错,提示: Error : socket0 - Address already in use. Error code
: 10048.而且非常坚持说脚本不会有问题,因为脚本直接录制后回放,什么都没改,
是不会出错的.拿到脚本一看,有一条语句lrs_create_socket,建立了socket0,但
是之后没有任何socket0的语句，可以判断出 该语句是无效的，注释掉，问题解
决。所以大家不要过分相信LR了 ，它生成的语句也是有很多BUG的。

经常有朋友们问到，log文件在哪看，特别是controll执行后，怎么看log。这里一一说明一下：
（1）在vgen中，我们必须写输出函数输出信息，将我们所想要了解的信息用函数输出，主要有这么几个函数输出信息： lr_output_message,lr_error_message,lr_log_message。这些函数请参阅help-->function reference.
其次，我们要在runtime settings中设置，勾选always send messages,具体的做法是：runtime settings--->log-->always send messages，这样我们才能写出Log，在我们的脚本所在的文件夹中，有两个文件很重要， mdrv.log.txt和output.txt文件，lr_log_message只会把信息输到mdrv.log文件中，而lr_output_message则会写进以上两个文件。
（2）在controller中，很多朋友都会想知道多次迭代，参数是否正确的导入了呢，我们依旧查看log,我们在执行结束后，查看结果目录的Log文件夹,如果是负载生成器运行的话,则在tmp目录。 不过，还想提醒朋友们，在controller 我们也要设置runtime settings才行，而且每个用户组的runtime settings,设置的方法是：在controller的design标签页中，右下角的部分有runtime settings按钮，我们点击它，设置的方法与在vgen中一样的

经常看到某些人问LR中如何选择协议，我来谈谈这个问题

1.LR支持多种协议，请大家一定要注意，这个地方协议指的是你的Client端通过什么协议访问的Server，Client一般是面向最终使用者的，Server是第一层Server端，因为现在的体系架构中经常Server层也分多个层次，什么应用层，什么数据层等等，LR只管Client如何访问第一层Server。

2.特别要注意某些应用，例如一个Web系统，这个系统是通过ActiveX控件来访问后台的，IE只是一个容器，而ActiveX控件访问后台是通过COM/DCOM协议的，这种情况就不能使用Web协议，否则你什么也录制不到，所以，LR工程师一定要了解应用程序的架构和使用的技术。

3.谈谈多协议

LR是支持在一个脚本里面使用多协议的，不过这个多协议是有一定的限制的，我有一个LR7.6上哪些协议支持多协议，LR8.0是不是取消了这些限制我不清楚。象HTTPS，一般来讲一定要选择多协议，但在选择具体协议的时候一定只选Web协议，这时候才能作那个端口映射。

4.谈谈Web协议中Option

Web协议里面有一些Option，具体我记不清楚了，但有一个地方很重要：就是选择URL方式还是HTM方式录制，这里有一些原则

a. 尽量使用HTM方式录制

b.如果使用了Javascrīpt，并且javascrīpt里面与后台有交互，那一定要使用URL方式，例如javascrīpt用于判断用户名和密码是否正确（与后台一定会有交互），那么就要使用URL方式录制；但如果Javascipt只是判断用户名或密码的格式，那一般不会与后台发生交互，就不需要使用URL方式。至于什么情况下一定要用URL方式，我曾经写过一个文档，但现在我不记得了不好意思。

5.谈谈并发点和结果检查

很多人喜欢使用并发点和结果检查，我谈谈我自己的看法。第一我基本上从来不使用结果检查，压力测试的结果我一般是去后台检查存储层的数据是否正确的。LR只能检查协议层上的错误，但如果在大量并发用户的情况下使用返回结果检查例如reg_text_check，会极大的占用客户端的资源，我一般不这么作；至于并发点，我只有在客户强烈要求的情况下才会使用，否则基本不用。

1.   事务（Transaction）

事务（Transaction）是这样一个点，我们为了衡量某个action的性能，需要在action的开始和结束位置插入这样一个范围，这样就定义了一个transaction，LoadRunner 运行到该事务的开始点时，LoadRunner 就会开始计时，直到运行到该事务的结束点，计时结束。这个事务的运行时间在结果中会有反映。

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

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

比如一个单据,把从登录到保存成功退出整个作为一个脚本,对于需要关注的保存,输入的帮助定义为单独的事务,以取得响应时间，需要响应时间的设事务

 

脚本中事务的代码如下：

   

 

    

 

 

 

2.  集合点（Rendezvous）

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

注意：集合点经常和事务结合起来使用，常放在事务的前面，集合点只能插入到Action 部分，vuser_init和vuser_end 中不能插入集合点。集合点函数如下：

 

 

加入集合点之后，在后面运行过程中可以看到VU的状态，会等待集合。

 

3.   IP Spoofer（IP 欺骗）

   当运行场景时，虚拟用户使用它们所在的Load Generator 的固定的IP 地址。同时每个

Load Generator 上运行大量的虚拟用户，这样就造成了大量的用户使用同一IP 同时访问一个

网站的情况，这种情况和实际运行的情况不符，并且有一些网站会根据用户IP 来分配资源，

这些网站会限制同一个IP 的登陆，使用等等。为了更加真实的模拟实际情况，LoadRunner

允许运行的虚拟用户使用不同的IP 访问统一网站，这种技术称为“IP 欺骗”。

启用该选项后，场景中运行的虚拟用户将模拟从不同的IP 地址发送请求。该选项非常

的有用。注意：IP Spoofer 在连接Load Generators 之前启用。要使用IP 欺骗，各个Load Generator 机器必须使用固定的IP，不能使用动态IP（即DHCP）。

 

LoadRunner主要功能是模拟多用户对系统进行负载压力测试，默认情况下，多用户的生成器都是LocalHost，有些应用需要不同的IP访问，为了模拟真实操作，我们还必须模拟多个IP，IP Wizard工具就提供了生成多个ip的功能，IP Wizard是一个单独的程序，我们可以在开始菜单里面找到，你可以添加一个局域网内的IP段。添加后重启，在Win2k下使用Ipconfig/all查看到很多虚拟的IP，最后要在Controller里面选择enable ip spoofer.

 

4.   （Text/Image）检查点

 

对于查询类的脚本,一定要添加检查点,以保证在测试时结果的正确性.因为LR只要检测到网页的响应,就认为是pass而并不管当前网页内容的正确性．在进行压力测试时，为了检查Web服务器返回的网页是否正确，VuGen允许我们插入Text/Imag 检查点，这些检查点验证网页上是否存在指定的Text或者Image，还可以测试在比较大的压力测试环境中，被测的网站功能是否保持正确。检查点的含义和WinRunner 中的检查点功能基本上一致，这里就不再作过多的说明。

    举个例子：当我用loadrunner做压力测试的时候，
它的确能反馈给我各种服务器性能的数据，
但是在做B/S结构系统的测试的时候，
去发现如下问题：
loadrunner不能正确判断操作是否成功，
比如登录，我要测试200人同时登录，
但是我的login.jsp里面没有正确的关闭数据库的连接，
导致登录100人后，建立了100个数据库连接，
第101一个人登录的时候，由于超出数据库连接的最大数，
所以，jsp程序抛出了一个数据库异常。
但是页面的走向是正确的，所以loadrunner会认为程序是正确执行的，但是事实却并非如此

 

5.   LR脚本复用问题

 

    作为一款优秀的负载测试工具，LR的测试脚本有很好的复用性，参数化后的脚本，在应用没什么大的变化的情况下，一直是可以用的。甚至你在A服务器录制的脚本，如果做测试的时候，需要转移到B服务器上，你只需要用查找替换的功能将A服务器的IP地址换成B服务器就可以使用。

 

6.  理解Correlation（关联）

 

关联是用来解决脚本中存在的动态数据问题的.在7.8中,当你回放一次后,LR会自动录找你录制的时候和回放时候的差别,找出动态数据,并作成参数。举个我作的动态数据的例子，当用户登录时，会产生一个Sessionid号，访问结束后，该Sessionid便会失效。我录制的时候，在脚本里面获取到了该Sessionid，但当我再回放的时候，这个Sessionid已经无效了，所以，我需要把这个Sessionid作为一个动态数据，当我一登录的时候，便获取一个新的有效的Sessionid，然后通过web_reg_save_param("WCSParam_Text2",
"LB=ProcessID=",
"RB=;",
"Ord=1",
"RelFrameId=1",
"Search=body",
LAST);
函数把它保存下来。那么后面用到的页面中就可以调用WCSParam_Text2这个参数使用这个新的Sessionid号。这是个动态数据很典型的例子，

web_submit_data("w_onload_check.asp",
"Action=http://gsserver3/cwbase/sys/userlogin/w_onload_check.asp",
"Method=POST",
"TargetFrame=",
"RecContentType=text/html",
"Referer=http://gsserver3/cwbase/sys/userlogin/index.asp",
"Snapshot=t3.inf",
"Mode=HTML",
ITEMDATA,
"Name=hdclentip", "Value=chenjing", ENDITEM,
"Name=hdProcessID", "Value=F8E5ACCD372845C38C7E1981A342F703", ENDITEM,
"Name=selInstanceid", "Value=T01", ENDITEM,
"Name=TxtUserID", "Value={RYBH}", ENDITEM,
"Name=TxtPassword", "Value=cwpass", ENDITEM,
"Name=Txtkjdate", "Value=2003.01.06", ENDITEM,
"Name=selInstancetxt", "Value=性能测试用(中型数据库)", ENDITEM,
"Name=selInstance", "Value=T01", ENDITEM,
LAST);
web_url("loginpage.aspx",
"URL=http://gsserver3/cwbase/sys/menushow/loginpage.aspx?ProcessID={WCSParam_Text2}",
"TargetFrame=",
"Resource=0",
"RecContentType=text/html",
"Referer=",
"Snapshot=t4.inf",
"Mode=HTML",
LAST);

左边界，右边界到底是个什么概念，

理解web_reg_save_param函数，

int web_reg_save_param (const char *ParamName, <List of Attributes>, LAST);

 

第一部分：参数名字，用双引号括起，逗号分开；

第二部分：List of Attributes，包括：LB、RB、RelFrameID、Ord、Search、SaveOffset、SaveLen等，

第三部分：LAST，结束标志。

LB是左边界，RB是右边界，比如说吧，程序中有这么一个赋值，ProcessID =A53625E18440FCE81F26DCE712E65EBA;如果ProcessID的值是动态的，我想使用动态变量，那我设定查找左边界为LB=ProcessID=,右边界为;的字符，如果找到了，就替换成变量.

Search是指查找范围，就是说在哪里查找这些值，可以取这样几个值，我们一般设为ALL，Body等即可。

Headers (Search only the headers),

Body (search only Body data, not headers),

Noresource (search only the html body, excluding all headers and resources),

ALL (search Body and headers). The default value is ALL.

 

RelFrameID: The hierarchy level of the HTML page relative to the requested URL.一般取1

 

ORD: This parameter, also known as Instance, indicates the ordinal or instance of the match. 一般取 1

LR7.8已经为用户定义好了很多类型的关联，我们可以自己定义New rule，不过我在录制脚本的时候一般把系统的那些都关掉，定义自己的，只是有的时候，它不能自动关联，就干脆手工作了。需要关联的地方：一般是在有主键，不允许记录重复，和一些主程序中传递过来的参数，在后面要用到等情况才使用关联的，你可以先执行一遍，如果有些地方不允许重复可参数值无效，就会出错的，根据错误提示你可以判断出来，就知道需要关联了。一般需要关联的不多，我现在遇到的就是进程号，以及表的主键。我这里有个Correlation的官方文档，大家下去可以自己看看。