-
小布老师 LoadRunner系列培训视频
2010-06-30 15:07:16
-
LoadRunner 中如何进行关联
2007-07-05 10:23:51
http://zhidao.baidu.com/question/19338536.html
为了避免该网页失效，内容粘贴如下，以备自己在做关联时遇到问题有所准备。该内容来自网络。
什么是在 LoadRunner 脚本中做关联
悬赏分：0 - 解决时间：2007-2-6 09:31网上的教程看不太懂，能否具体说说再什么情况下该做关联 
最佳答案如何在 LoadRunner 脚本中做关联 (Correlation)
当录制脚本时，VuGen会拦截client端（浏览器）与server端（网站服务器）之间的对话，并且通通记录下来，产生脚本。在VuGen的Recording Log中，您可以找到浏览器与服务器之间所有的对话，包含通讯内容、日期、时间、浏览器的请求、服务器的响应内容等等。脚本和Recording Log最大的差别在于，脚本只记录了client端要对server端所说的话，而Recording Log则是完整纪录二者的对话。
当执行脚本时，您可以把VuGen想象成是一个演员，它伪装成浏览器，然后根据脚本，把当初真的浏览器所说过的话，再对网站伺服器重新说一遍，VuGen企图骗过服务器，让服务器以为它就是当初的浏览器，然后把网站内容传送给VuGen。
所以纪录在脚本中要跟服务器所说的话，完全与当初录制时所说的一样，是写死的（hard-coded）。这样的作法在遇到有些比较聪明的服务器时，还是会失效。这时就需要透过「关联（correlation）」的做法来让VuGen可以再次成功地骗过服务器。
何谓关联（correlation）？
所谓的关联（correlation）就是把脚本中某些写死的（hard-coded）数据，转变成是撷取自服务器所送的、动态的、每次都不一样的数据。
举一个常见的例子，刚刚提到有些比较聪明的服务器，这些服务器在每个浏览器第一次跟它要数据时，都会在数据中夹带一个唯一的辨识码，接下来就会利用这个辨识码来辨识跟它要数据的是不是同一个浏览器。一般称这个辨识码为Session ID。对于每个新的交易，服务器都会产生新的Session ID给浏览器。这也就是为什么执行脚本会失败的原因，因为VuGen还是用旧的Session ID向服务器要数据，服务器会发现这个Session ID是失效的或是它根本不认识这个Session ID，当然就不会传送正确的网页数据给VuGen了。
下面的图示说明了这样的情形：
当录制脚本时，浏览器送出网页A的请求，服务器将网页A的内容传送给浏览器，并且夹带了一个ID=123的数据，当浏览器再送出网页B的情求时，这时就要用到ID=123的数据，服务器才会认为这是合法的请求，并且把网页B的内容送回给浏览器。
在执行脚本时会发生什么状况？浏览器再送出网页B的请求时，用的还是当初录制的ID=123的数据，而不是用服务器新给的ID=456，整个脚本的执行就会失败。
要对付这种服务器，我们必须想办法找出这个Session ID到底是什么、位于何处，然后把它撷取下来，放到某个参数中，并且取代掉脚本中有用到Session ID的部份，这样就可以成功骗过服务器，正确地完成整个交易了。
哪些错误代表着我应该做关联（correlation）？
假如脚本需要关联（correlation），在还没做之前是不会执行通过的，也就是说会有错误讯息发生。不过，很不幸地，并没有任何特定的错误讯息是和关联（correlation）有关系的。会出现什么错误讯息，与系统实做的错误处理机制有关。错误讯息有可能会提醒您要重新登入，但是也有可能直接就显示HTTP 404的错误讯息。
要如何做关联（correlation）？
关联（correlation）函数
关联（correlation）会用到下列的函数：
• web_reg_save_param：这是最新版，也是最常用来做关联（correlation）的函数。
语法：
web_reg_save_param ( “Parameter Name” , < list of Attributes >, LAST );
• web_create_html_param、web_create_html_param_ex：这二个函数主要是保留作为向前兼容的目的的。建议使用 web_reg_save_param 函数。
详细用法请参考使用手册。在VuGen中点选【Help】>【Function reference】>【Contexts】>【Web and Wireless Vuser Functions】>【Correlation Functions】。
如何找出要关联（correlation）数据
简单的说，每一次执行时都会变动的值，就有可能需要做关联（correlation）。
VuGen提供二种方式帮助您找出需要做关联（correlation）的值：
1. 自动关联
2. 手动关联
自动关联
VuGen内建自动关联引擎（auto-correlation engine），可以自动找出需要关联的值，并且自动使用关联函数建立关联。
自动关联提供下列二种机制：
• Rules Correlation：在录制过程中VuGen会根据订定的规则，实时自动找出要关联的值。规则来源有两种：
o 内建（Built-in Correlation）：
VuGen已经针对常用的一些应用系统，如AribaBuyer、BlueMartini、BroadVision、InterStage、mySAP、NetDynamics、Oracle、PeopleSoft、Siebel、SilverJRunner等，内建关联规则，这些应用系统可能会有一种以上的关联规则。您可以在【Recording Options】>【Internet Protocol】>【Correlation】中启用关联规则，则当录制这些应用系统的脚本时，VuGen会在脚本中自动建立关联。
您也可以在【Recording Options】>【Internet Protocol】>【Correlation】检视每个关联规则的定义。
o 使用者自订（User-defined Rules Correlation）：
除了内建的关联规则之外，使用者也可以自订关联规则。您可以在【Recording Options】>【Internet Protocol】>【Correlation】建立新的关联规则。
• Correlation Studio：有别于Rules Correlation，Correlation Studio则是在执行脚本后才会建立关联，也就是说当录制完脚本后，脚本至少须被执行过一次，Correlation Studio才会作用。Correlation Studio会尝试找出录制时与执行时，服务器响应内容的差异部分，藉以找出需要关联的数据，并建立关联。
Rule Correlation
请依照以下步骤使用Rule Correlation：
1. 启用auto-correlation
1. 点选VuGen的【Tools】>【Recording Options】，开启【Recording Options】对话窗口，选取【Internet Protocol】>【Correlation】，勾选【Enable correlation during recording】，以启用自动关联。
2. 假如录制的应用系统属于内建关联规则的系统，如AribaBuyer、BlueMartini、BroadVision、InterStage、mySAP、NetDynamics、Oracle、PeopleSoft、Siebel、SilverJRunner等，请勾选相对应的应用系统。
3. 或者也可以针对录制的应用系统加入新的关联规则，此即为使用者自订的关联规则。
4. 设定当VuGen侦测到符合关联规则的数据时，要如何处理：
【Issue a pop-up message and let me decide online】：跳出一个讯息对话窗口，询问您是否要建立关联。
【Perform correlation in sceipt】：直接自动建立关联
2. 录制脚本
开始录制脚本，在录制过程中，当VuGen侦测到符合关联规则的数据时，会依照设定建立关联，您会在脚本中看到类似以下的脚本，此为BroadVision应用系统建立关联的例子，在脚本批注部分可以看到关联前的数据为何。
3. 执行脚本验证关联是OK的。
Correlation Studio
当录制的应用系统不属于VuGen预设支持的应用系统时，Rule Correlation可能既无法发挥作用，这时可以利用Correlation Studio来做关联。
Correlation Studio会尝试找出录制时与执行时，服务器响应内容的差异部分，藉以找出需要关联的数据，并建立关联。
使用Correlation Studio的步骤如下：
1. 录制脚本并执行
2. 执行完毕后，VuGen会跳出下面的【Scan Action for Correlation】窗口，询问您是否要扫描脚本并建立关联，按下【Yes】按钮。
3. 扫描完后，可以在脚本下方的【Correlation Results】中看到扫描的结果。
4. 检查一下扫瞄的结果后，选择要做关联的数据，然后按下【Correlate】按钮，一笔一笔做，或是按下【Correlate All】让VuGen一次就对所有的数据建立关联。
注意：由于Correlation Studio会找出所有有变动的数据，但是并不是所有的数据都需要做关联，所以不建议您直接用【Correlate All】。
5. 一般来说，您必须一直重复步骤1~4直到所有需要做关联的数据都找出来为止。因为有时前面的关联还没做好之前，将无法执行到后面需要做关联的部份。
有可能有些需要做关联的动态数据，连Correlation Studio都无法侦测出来，这时您就需要自行做手动关联了。
手动关联
手动关联的执行过程大致如下：
1. 使用相同的业务流程与数据，录制二份脚本
2. 使用WinDiff工具协助找出需要关联的数据
3. 使用web_reg_save_param函数手动建立关联
4. 将脚本中有用到关联的数据，以参数取代
接下来将详细的说明如何执行每个步骤
使用相同的业务流程与数据，录制二份脚本
1. 先录制一份脚本并存档。
2. 依照相同的操作步骤与数据录制第二份脚本并存盘。注意，所有的步骤和输入的数据一定都要一样，这样才能找出由服务器端产生的动态数据。
有时候会遇到真的无法使用相同的输入数据，那您也要记住您使用的输入数据，到时才能判断是您输入的数据，还是变动的数据。
使用WinDiff工具协助找出需要关联的数据
1. 在第二份脚本中，点选VuGen的【Tools】>【Compare with Vuser…】，并选择第一份脚本。
2. 接着WinDiff会开启，同时显示二份脚本，并显示有差异的地方。WinDiff会以一整行黄色标示有差异的脚本，并且以红色的字体显示真正差异的文字。（假如没看到红色字体，请点选【Options】>【View】>【Show Inline Differences】）。
3. 逐一检视二份脚本中差异的部份，每一个差异都可能是需要做关联的地方。选取差异的脚本，然后复制。
在复制时，有时并不需要取整行脚本，可能只会选取脚本中的一部分。
注意：请忽略lr_thik_time的差异部份，因为lr_thik_time是用来模拟每个步骤之间使用者思考延迟的时间。
4. 接着要在Recording Log（单一protocol）或是Generation Log（多重protocol）中找这个值。将鼠标光标点到Recording Log的第一行开头，按下Ctrl+F，开启【Find】窗口，贴上刚刚复制的脚本，找出在Recording Log第一次出现的位置。
结果会有二种：
o 在Recording Log中找不到要找的数据，这时请先确认您找对了脚本，毕竟现在开启了二个几乎一样的脚本，很容易弄错。
o 在Recording Log中找到了要找的数据，这时要确认数据是从服务器端传送过来的。首先可以先检查数据的标头，从标头的Receiving response可以知道数据是从服务器端传送到client端的。假如此数据第一次出现是在Sending request中，则表示此数据是由client端产生，不需要做关联，但是有可能需要做参数化（parameterized）。
您要找的标头格式如下：
*** [tid=b9 Action1 2] Receiving response from host astra.merc-int.com:80 ( 25/11/2002 12:04:00 )
5. 现在您已经找到录制二次都不一样，而且是由服务器所产生的动态数据了，而此数据极有可能需要做关联。
使用web_reg_save_param函数手动建立关联
在找到是由服务器所产生的动态数据之后，接下来要做的就是找出适当的位置，使用web_reg_save_param函数，将这个动态数据撷取到某个参数中。
1. 要在哪里使用web_reg_save_param函数？
在之前的步骤，我们已经在Execution Log找到可能需要关联的动态数据。在Execution Log中选取动态数据前的文字然后复制，我们将会利用这段文字，来帮助我们找出要关联的动态数据。
不过在这之前我们要先找出使用web_reg_save_param函数的正确位置，所以我们要再重新执行一遍脚本，而且这次会开启所有的Log。
1. 在VuGen中点选【Vuser】>【Run-Time Settings】。
2. 点选【General】>【Log】。
3. 勾选【Enable logging】、【Always sends messages】、【Extended log】，以及【Extended log】下的所有选项。
4. 按下【OK】就可以执行脚本了。
执行完脚本之后，在Execution Log中搜寻刚刚复制的字符串。找到字符串后，在字符串前面会有A.tion1.c(7)，这个7就是到时候要插入web_reg_save_param函数的位置，也就是要插入到脚本的第7行。
在脚本的第7行前插入一行空白行，然后输入
web_reg_save_param(“UserSession”,
“UserSession” 这个 “UserSession” 就是到时要使用的参数名称，建议给个有意义的名字。
注意：到这里整个web_reg_save_param函数还没完成。
2. 找出web_reg_save_param中要用到的边界
web_reg_save_param函数主要是透过动态数据的前面和后面的固定字符串，来辨识要撷取的动态数据的，所以我们还需要找出动态数据的边界字符串。
找出左边界字符串
再回到Execution Log中，选取动态数据前的字符串并且复制它。
这时会有个问题，到底要选取多少字符串才足以唯一识别要找的动态数据呢？建议是越多越好，但是尽量不要包含到特殊字符。
在这边我们选取「input type=hidden name=userSession value=」字符串。选好之后，还要再确认一次这段字符串真的是可以唯一识别的，所以我们在Execution Log中透过Ctrl+F的搜寻，找找看这段字符串是否可以找到要找的动态数据。假如找不到，web_reg_save_param函数还有个ORD参数可以使用，ORD参数可以设定出现在第几次的字符串才是要找的字符串。
将这个边界字符串加到未完成的web_reg_save_param函数中：
web_reg_save_param(“UserSession”, “LB= input type=hidden name=userSession value=”,
找出右边界字符串
接下来要找出动态数据的右边界字符串，这个字符串就比较好找了，从动态数据的最后一个字符开始，通常就是我们要找的右边界字符串了。
以这个例子来看，就是「>」，所以再把右边界字符串加入，web_reg_save_param函数中，这时web_reg_save_param函数已经快完成了。最后再加上「LAST);」就完成整个web_reg_save_param函数了。
web_reg_save_param(“UserSession”, “LB= input type=hidden name=userSession value=”, “RB=>”, LAST);
将脚本中有用到关联的数据，以参数取代
当使用web_reg_save_param建立参数后，接下来就是用“UserSession”参数去取代脚本中写死的（hard-coded）资料。
范例：
将
“Name=userSession”, “Value=75893.0884568651DQADHfApHDHfcDtccpfAttcf”, ENDITEM,
换成
“Name=userSession”, “Value={UserSession}”, ENDITEM,
到这里您已经完成了一个关联了，接下来就是执行脚本，是否能成功运行，假如还是有问题，就要检查看看是否还需要再做另一个关联。
关于 web_reg_save_param 函数
对于关联(correlation)来说，web_reg_save_param是最重要的一个函数，其功能是在下载的网页内容中，透过设定的边界字符串，找出特定的数据并将其储存在一个参数中，以供后续脚本使用。
接下来将针对web_reg_save_param做比较详细的说明。
Service and registration type function
web_reg_save_param是一个Service function。service function主要是用来完成一些特殊的工作的，如关联、设定proxy、提供认证信息等，当其作用时，不会对网页的内容做任何的修改。
web_reg_save_param同时也是一个registration type function (只要函数名称中包含_reg_的字眼，表示其为registration type function)。registration type function意味着其真正作用的时机是在下一个action function完成时执行的。举例来说，当某个web_url执行时所接收到的网页内容中包含了要做关联的动态数据，则必须将web_reg_save_param放在此web_url之前，则web_reg_save_param会在web_url执行完毕后，也就是网页内容都下载完后，再执行web_reg_save_param找寻要做关联的动态数据并建立参数。
所以要记住一点，要使用registration type function时，要注意其放置的位置必须在要作用的action function之前。
语法
int web_reg_save_param(const char *ParamName, <list of Attributes>, LAST);
参数说明
ParamName:存放动态数据的参数名称
list of Attributes:其它属性，包含 Notfound, LB, RB, RelFrameID, Search, ORD, SaveOffset, Convert, 以及 SaveLen。属性值不分大小写，例如 Search=all。以下将详细说明每个属性值的意义:
• Notfound:指定当找不到要找的动态数据时该怎么处置。
o Notfound=error:当找不到动态数据时，发出一个错误讯息。假如没设定此属性，此为LoadRunner的默认值。
o Notfound=warning:当找不到动态数据时，不发出错误讯息，只发出警告，脚本也会继续执行下去不会中断。在对角本除错时，可以使用此属性值。
• LB:动态数据的左边界字符串。此属性质是必须要有的，而且区分大小写。
• RB:动态数据的右边界字符串。此属性质是必须要有的，而且区分大小写。
• RelFrameID:相对于URL而言，欲搜寻的网页的Frame。此属性质可以是All或是数字，而且可有可无。
• Search:搜寻的范围。可以是Headers(只搜寻headers)、Body(只搜寻body部分，不搜寻header)、Noresource(只搜寻body部分，不搜寻header与resource)或是All(搜寻全部范围，此为默认值)。此属性质可有可无。
• ORD:指明从第几次出现的左边界开始才是要撷取的数据。此属性质可有可无，默认值是1。假如值为All，则所有找到符合的数据会储存在数组中。
• SaveOffset:当找到符合的动态数据时，从第几个字符开始才开始储存到参数中。此属性质不可为负数，其默认值为0。
• Convert:可能的值有二种:
o HTML_TO_URL: 将HTML-encoded数据转成URL-encoded数据格式
o HTML_TO_TEXT:将HTML-encoded数据转成纯文字数据格式
• SaveLen:从offect开始算起，到指定的长度内的字符串，才储存到参数中。此参数可有可无，默认值是-1，表示储存到结尾整个字符串。
范例
web_reg_save_param("A", "LB/ic=<a href=", "RB='>", "Ord=All", LAST);nner会搜寻网页中所有以 「<a href=」 开头，且以 「’>」结束，当中包含的字符串，并且储存在「A」参数中。
Tips and Tricks
以下提供一些关联的常见问题：
• 如何打印出参数值？
lr_output_message这二个函数来做到。例如：
lr_output_message(“Value Captured = %s”, lr_eval_string(“{ParameterName}”));
lr_eval_string与lr_output_message函数的使用说明请参考LoadRunner Online Function Reference。
• 在脚本的data目录下找不到路制时的快照（snapshot）
造成在脚本的data目录下找不到路制时的快照（snapshot）的可能原因如下：
o 脚本是由VuGen 6.02或更早的版本所录制的
o 汇入的Action不会包含快照（snapshot）的档案
o 脚本是储存在只读的目录下，早成VuGen无法储存执行时撷取的快照（snapshot）
o 某些步骤并不会产生快照（snapshot），如浏览某个资源
o 快照（snapshot）功能被取消
【Tools】>【General options】>【Correlation】tab >【Save correlation information during replay】
• 开启WinDiff时出现「File no longer available」的错误讯息
WinDiff这个工具有些限制，无法开启包含空格符的目录或是脚本，所以建议命名时不要使用空格符，并且尽可能将名称取短一点。
• 录制时突然跳出【Correlation warning】对话窗口
当你有勾选自动关联的【Issue a popup message and let me decide online】选项，当VuGen发现有可能要做关联的数据时，就会跳出【Correlation warning】的窗口，询问你要做关联（Correlation in scrīpt）还是要忽略（Ignore）。
另外你也可以勾选【Perform correlation in scrīpt】，让VuGen自动作关联，不会再跳出询问窗口。
或是勾选【Disable correlation engine】，关闭自动关联的功能。
• 如何手动启动「Scan action for correlation」的功能
要手动启动「Scan action for correlation」的功能，请先执行脚本一次后，点选【Vuser】>【Scan Action for Correlation】。
• 执行完脚本后并未出现【Scan Action for Correlation】窗口
要启用【Scan Action for Correlation】功能， -
关于计数器的解释
2007-04-10 15:24:49
-
基于C/S结构的应用程序的性能测试（转）
2007-04-03 13:40:22
-
性能测试及性能调整概述（转贴）
2007-04-03 13:32:56
明确了具体的性能要求后，可以开始进行测试，确定应用程序是否满足这些要求。性能测试假定应用程序稳定、可靠地运行。因此，在测试中消除尽可能多的变数很重要。例如，代码中的错误可以导致出现性能问题，甚至掩盖性能问题。要精确地比较不同性能测试的结果，应用程序必须正确地工作。如果调整过程修改了组件的实现，则重新测试应用程序的功能尤其重要。应用程序必须通过功能性测试后才可以测试性能。除了应用程序更改外，硬件、网络通信量、软件配置、系统服务等诸多方面也会发生意外的更改。控制应用程序更改很重要。
测量性能
要正确地调整性能，必须准确完整地记录每次测试的结果并进行维护。记录应包括：
- 精确的系统配置，尤其是与前几次测试的不同之处
- 原始数据和性能监视工具计算的结果
这些记录不仅指示应用程序是否达到性能目标，而且有助于识别未来性能问题的潜在原因。
性能调整是与性能管理相关的主要活动。当性能降到最基本的水平时，性能调整由查找和消除瓶颈组成，瓶颈是在服务器中的某个硬件或软件接近其容量限制时发生和显示出来的情况。
在开始性能调整循环之前，必须做一些准备工作，为正在进行的性能调整活动建立框架。您应该：
- 识别约束 － 站点的业务实例确定优先级，而优先级又设立边界。约束（如可维护性和预算限制）在寻求更高的性能方面是不可改变的因素。必须将寻求性能提高的努力集中在不受约束的因素上。
- 指定负载 － 这涉及确定站点的客户端需要哪些服务，以及对这些服务的需求程度。用于指定负载的最常用度量标准是客户端数目、客户端思考时间以及负载分布状况；其中客户端思考时间是指客户端接收到答复到后面提交新请求之间的时间量，负载分布状况包括稳定或波动负载、平均负载和峰值负载。
- 设置性能目标 － 性能目标必须明确，包括识别用于调整的度量标准及其对应的基准值。总的系统吞吐量和响应时间是用于测量性能的两个常用度量标准。识别性能度量标准后，必须为每个度量标准建立可计量的基准值与合理的基准值。 51testing软件测试博客:j*r^p|e j!h"^
注意 由于性能和容量的关系如此密切，因此您识别的约束、负载和目标也适用于容量规划。
建立了性能调整的边界和期望值后，可以开始调整循环，这是一系列重复的受控性能试验。
调整循环
重复以下所示的四个调整循环阶段，直到获得在开始调整过程前建立的性能目标。
调整循环
收集
收集阶段是任何调整操作的起点。在此阶段，只是使用为系统特定部分选择的性能计数器集合来收集数据。这些计数器可用于网络、服务器或后端数据库。
不论调整的是系统的哪一部分，都需要根据基准测量来比较性能改变。需要建立系统空闲以及系统执行特定任务时的系统行为模式。因此，可以使用第一遍数据收集来建立系统行为值的基准集。基准建立在系统的行为令人满意时应该看到的典型计数器值。
注意 基准性能是一个主观的标准：必须设置适合于工作环境且能最好地反映系统工作负荷和服务需求的基准。
分析
收集了调整选定系统部分所需的性能数据后，需要对这些数据进行分析以确定瓶颈。记住，性能数字仅具有指示性，它并不一定就可以确定实际的瓶颈在哪里，因为一个性能问题可能由多个原因所致。某个系统组件的问题是由另一系统组件的问题导致的，这种情况也很普遍。内存不足是这种情况的最好示例，它表现为磁盘和处理器使用的增加。
以下几点来自“Microsoft Windows 2000 资源工具包”，提供了解释计数器值和消除可能导致设置不适当的调整目标值的错误数据或误导数据的指南。
- 监视名称相同的进程 — 监视某个实例而没有监视另一个实例的异乎寻常大的值。有时，系统监视器将多个实例的组合值报告为单个实例的值，这就错误地报告了同名进程的不同实例的数据。可通过按进程标识符对进程进行跟踪来解决此问题。
- 监视多个线程 － 当监视多个线程而其中一个线程停止时，一个线程的数据可能似乎被报告成了另一个线程的数据。这是由于线程的编号方式所导致的。可通过将进程线程的线程标识符包含在日志或显示中来解决此问题。为此，请使用“线程/线程 ID”计数器。
- 数据值中的不连续峰值 － 不必太重视数据中偶尔的峰值。这些峰值可能是由于进程的启动，并不是该进程随时间改变的计数器值的准确反映。尤其是平均计数器可以导致峰值随时间停留的效果。
- 监视一段延长的时期 － 建议使用图形代替报告或直方图，因为后两种视图仅显示最后的值和平均值。结果，当查找峰值时，可能得不到这些值的准确反映。
- 排除启动事件 － 除非有特殊的原因需要将启动事件包含在数据中，否则排除这些事件，因为它们产生的临时性高峰值往往歪曲了整体性能结果。
- 零值或缺少的数据 － 调查所有出现的零值或缺少的数据。这些零值或缺少的数据会妨碍建立有意义的基准。
配置
收集了数据并完成结果分析后，可以确定系统的哪部分最适合进行配置更改，然后实现此更改。
实现更改的最重要规则是：一次仅实现一个配置更改。看起来与单个组件相关的问题可能是由涉及多个组件的瓶颈导致的。因此，分别处理每个问题很重要。如果同时进行多个更改，将不可能准确地评定每次更改的影响。
测试
实现了配置更改后，必须完成适当级别的测试，确定更改对调整的系统所产生的影响。在这一点上，这是确定更改是否有如下影响的问题：
- 性能提高 － 更改提高了性能吗？如果是，提高了多少？
- 性能下降 － 更改在其他位置导致了瓶颈吗？
- 对性能没有影响 － 更改对性能到底有何显著的影响？
如果幸运，性能提高到预期的水平，这时便可以退出。如果不是这样，则必须重新逐步进行调整循环。
提示 可以从监视日志文件（可导出到 Microsoft Excel）和事件日志中获取测试所产生的监视结果。
测试时务必要：
- 检查用于测试的应用程序的正确性和性能，查找内存泄漏和不正常的客户端请求响应延迟。
- 确保所有测试都正常进行。
- 确保可以使用相同的事务混合和相同的客户端生成相同的负载来重复所有测试。
- 文档更改和结果。
在每遍测试中，运行一系列完全相同的性能测试；否则，无法分辨不同的结果是由于测试中的改动还是应用程序更改造成的。使尽可能多的性能测试操作自动进行有助于消除因操作者造成的差异。
其他表面上是良性的因素影响性能测试的结果，如应用程序在测试开始前运行的时间。正如冷的汽车引擎与热引擎的性能不同，长时间运行的应用程序由于内存碎片这样的因素，其性能可能与刚启动的应用程序不同。
定义性能测试
性能测试期间，测量和记录性能目标中指定的度量标准值。达到全部性能度量标准（如思考时间、事务混合等）很重要。在这些约束下，测试应尽可能实际。例如，对应用程序进行测试，确定它在许多客户端同时访问它时的性能。多线程测试应用程序可以用可复制的方式模拟多个客户端，每个线程表示一个客户端。如果应用程序访问数据库，则数据库应包含实际数目的记录，并且测试应使用数据项的随机（但有效）值。如果测试数据库太小，数据库服务器的缓存效果将产生不符合实际情况的测试结果。如果输入或访问数据的方式不符合实际情况，则结果也可能不符合实际情况。例如，在主键上按字母顺序创建新数据是不太可能的。
通常，测试装置必须接受用户指定的输入参数，如事务混合、思考时间、客户端数目等。然而，测试装置本身可以规定创建实际的随机数据的规则。
创建了驱动应用程序的测试装置后，应该将所有运行测试的不变条件记入文档。最起码，这些条件应包括运行测试装置所需的输入参数。另外，应将如何设置运行测试的数据库记入文档。说明中应指定数据库不应包含前一遍测试所做的更改。说明中还应指定用于测试的计算机配置。在不同于应用程序所在的另一台计算机上运行测试装置，因为这样设置更接近生产环境。
确定基准性能
确定了性能目标并制定了性能测试后，运行一次测试以建立基准。验证环境与生产环境越相似，应用程序部署后的性能令人满意的可能性就越大。因此，一开始有一个符合实际情况的验证环境很重要。
幸运的话，基准性能将符合性能目标，并且应用程序不需要任何调整。但更可能的情况是，基准性能不令人满意。然而，记录初始测试环境和基准结果可以为调整工作提供坚实的基础。
压力测试
压力测试是性能测试的一种专门形式，它与其他工程领域的破坏性测试相似。压力测试的目的是使应用程序产生故障，通过增加处理负载使其超过性能的降低，直到由于资源饱和或发生错误而使应用程序开始出问题。压力测试有助于揭示细微的错误，这些错误本来要到部署应用程序时才会被发现。由于此类错误通常是因设计缺陷所致，压力测试应该早在开发阶段便在应用程序的每个区域上开始进行。在其源头修复这些细微的错误，而不是忽视这些错误，直到它们可能在应用程序中的其他位置表现出症状时才修复它们。
解决性能问题
通常可将性能问题归结于不止一个因素。因此，查找性能恶化的解决方案与进行科学实验极为相似。科学实验传统上遵循一个分六步进行的过程，包括观察、初步假设、预测、测试、控制和结论。结论由该过程积累的最佳证据集合所支持的假设组成。可以遵循同样的过程来解决性能问题。
当观察到 ASP 应用程序的性能比期望的低时，您假定 ASPProcessorThreadMax 元数据库属性设置得太低。当“ASP 排队请求”性能计数器上下移动，并且处理器的运行效率低于 50% 时，可能会发生这种情况。您预测增加 ASPProcessorThreadMax 元数据库属性的数值可以提高性能。
活动线程设置现在已经变成控件。一次仅进行一个设置更改，直到观察到满意的性能改变。如果在几次调整 ASPProcessorThreadMax 元数据库属性之后获得了更令人满意的性能，则结论是某个属性设置与所有当前变量（所需内存的总量、正在运行的应用程序数、已升级的软件等）组合，可提供最佳服务器性能。变量中的任何更改就会形成进一步的实验。
-
性能测试之协议分析（转贴）
2007-04-03 13:30:39
-
Java性能（转贴）
2007-04-03 13:28:07
-
ajax的技术应用在性能中适用情况初步分析（转贴）
2007-04-03 13:22:28
-
LoadRunner的一个解决方案 （转贴）
2007-04-03 12:49:06
-
再谈谈性能测试vs负载测试[中文翻译（转）
2007-04-03 12:41:53
源文来源：http://agiletesting.blogspot.com/2005/04/more-on-performance-vs-load-testing.html
作者：Grig Gheorghiu
作者联系方式：http://agiletesting.blogspot.com/
译者：AlexanderIII
译文联系方式：http://blog.51testing.com/?61747
相关文章连接：
性能测试VS负载测试VS压力测试[中文翻译]
［译者注］欢迎转载! 转载请尊重一下作者及译者，请把作者，译者及联系方式也转上，谢谢！同时如果有建议或者认为有什么不妥之处，欢迎来信交流，大家一起提高测试水平。
在一些翻得不太准确的地方，本人在都打上了*号，请注意！[]中的内容为本人自己为了中文意思的流畅性自行加入的，若造成与原文作者的意思有出入的，还请海涵！
＊禁止将内容用于商业用途！请在得到允许之后再进行，谢谢合作．
［源文&译文内容］Thursday, April 14, 2005
More on performance vs. load testing
再谈谈性能测试vs负载测试
I recently got some comments/questions related to my previous blog entry on performance vs. load vs. stress testing. Many people are still confused as to exactly what the difference is between performance and load testing. I've been thinking more about it and I'd like to propose the following question as a litmus test to distinguish between these two types of testing: are you actively profiling your application code and/or monitoring the server(s) running your application? If the answer is yes, then you're engaged in performance testing. If the answer is no, then what you're doing is load testing.
最近我得到了一些关于先前发表在博客上的贴子“performance vs. load vs. stress testing”的意见和疑问。我发现仍然还有很多人对于这两个概念有所混淆。近来，我又仔细想了一下它们的区别，然后得到了用以下这个“试金石”的区分方法：你是否积极*的去剖析应用程序的代码和（或者）运行着程序的服务器（群的状况）？如果答案是“YES”，那你就是在进行性能测试。假若答案是“NO”，那就可以说明你所做的就是负载测试了。
Another way to look at it is to see whether you're doing more of a white-box type testing as opposed to black-box testing. In the white-box approach, testers, developers, system administrators and DBAs work together in order to instrument the application code and the database queries (via specialized profilers for example), and the hardware/operating system of the server(s) running the application and the database (via monitoring tools such as vmstat, iostat, top or Windows PerfMon). All these activities belong to performance testing.
另外一种可以分辨的方法就是看测试人员做的是白盒测试多还是黑盒测试多。在走白盒的路子的时候，测试人员，开发人员，系统管理员和DBA都要通力合作才可以使用工具来解决问题*，比如说通过使用特定的探测器*来识别应用代码及数据库查询，通过vmstat,iostat,top或者Windows PerfMon工具来监测运行了应用程序和数据库的服务器上的硬件及操作系统（资源数据*），所有的这些都属于性能测试。
The black box approach is to run client load tools against the application in order to measure its responsiveness. Such tools range from lightweight, command-line driven tools such as httperf, openload, siege, Apache Flood, to more heavy duty tools such as OpenSTA, The Grinder, JMeter. This type of testing doesn't look at the internal behavīor of the application, nor does it monitor the hardware/OS resources on the server(s) hosting the application. If this sounds like the type of testing you're doing, then I call it load testing.
黑盒的路子就是在客户端运行负载工具来看应用程序的反应如何。这类型的工具范围从功能少的命令行运行的工具，httperf,openload,siege,Apache Flood，到功能比较强大的工具OpenSTA,The Grinder,JMeter. 这种类型的测试不看应用程序的内部的运作，也不监视运行着被测试程序的服务器硬件及操作系统的资源情况。假如你所做的看上去和这种情况相似的话，那么我觉得它就可定义为负载测试。
In practice though the 2 terms are often used interchangeably, and I am as guilty as anyone else of doing this, since I called one of my recent blog entries "HTTP performance testing with httperf, autobench and openload" instead of calling it more precisely "HTTP load testing". I didn't have access to the application code or the servers hosting the applications I tested, so I wasn't really doing performance testing, only load testing.
然而，在实际中这两个术语又常常被互相的代替使用，就连我自己也有点心虚，因为我和其它人一样，在之前写的一篇文章"HTTP performance testing with httperf, autobench and openload"标题命名得不太准确，其实用"HTTP load testing"的话，反而会更准确点，因为我在里面又没有接触到代码，也没有接触到运行着被测程序的服务器。所以说，其实我并没有做性能测试，做的其实就是负载测试。
I think part of the confusion is that no matter how you look at these two types of testing, they have one common element: the load testing part. Even when you're profiling the application and monitoring the servers (hence doing performance testing), you still need to run load tools against the application, so from that perspective you're doing load testing.
我想混淆两者的部分原因是因为不管你对它们的看法是怎么样的，它们都有一个共同之处，就是负载测试的部分。即使你的确是正在分析*应用程序[代码51testing]和监视服务器（在做性能测试），但你仍然还是要使用负载工具给应用程序加压，所以从这一观点来讲，是可以讲你正在做负载测试。
As far as I'm concerned, these definitions don't have much value in and of themselves. What matters most is to have a well-established procedure for tuning the application and the servers so that you can meet your users' or your business customers' requirements. This procedure will use elements of all the types of testing mentioned here and in my previous entry: load, performance and stress testing.
到目前为止，我所提及到的这些定义其实都是没有什么太大的价值。实际上最应该关注的是为了可以达到你的用户或者你的商业客户的需求，而去调整应用程序及服务器的一个好流程。整个流程会涉及到的元素*包括了这篇文章及先前我写的那篇“load performance and stress testing.”里所讲过的所有测试类型的内容。
Here's one example of such a procedure. Let's say you're developing a Web application with a database back-end that needs to support 100 concurrent users, with a response time of less than 3 seconds. How would you go about testing your application in order to make sure these requirements are met?
我举个例子来讲讲这个流程。比如说你正在开发一个有数据库后台的WEB应用程序，要求它可以支持100个并发用户，反应时间要小于3秒。在这个情况下，你会怎么样测试这个程序，让它可以达到需求？
1. Start with 1 Web/Application server connected to 1 Database server. If you can, put both servers behind a firewall, and if you're thinking about doing load balancing down the road, put the Web server behind the load balancer. This way you'll have one each of different devices that you'll use in a real production environment.
1. 将一台Web或者一台Application服务器和一台数据库服务器连在一起。如果可以的话，可以把两个服务器放在一个防火墙后面。假如你想以后要应用负载平衡的技术的话，你可以考虑在Web服务器前放个负载平衡器。这种方法就可以让你在一种更贴近实际环境[的情况下进行测试了*51testing]。2. Run a load test against the Web server, starting with 10 concurrent users, each user sending a total of 1000 requests to the server. Step up the number of users in increments of 10, until you reach 100 users.
2. 对Web 服务器开始进行负载测试，先上10个并发用户，每个用户向服务器发1000个请求，然后再逐步10个10个的增加并发用户，直到100个并发用户。
3. While you're blasting the Web server, profile your application and your database to see if there are any hot spots in your code/SQL queries/stored procedures that you need to optimize. I realize I'm glossing over important details here, but this step is obviously highly dependent on your particular application.
3.你可以在轰炸WEB服务器的时候[意指对WEB服务器加不同负载的整个过程]，分析应用程序/SQL查询/存储过程*中是否存在需要优化改善的地方。我意识到在这一点有点过于强调了（*），这一步明显的取决于具体的项目（*）。
Also monitor both servers (Web/App and Database) via command line utilities mentioned before (top, vmstat, iostat, netstat, Windows PerfMon). These utilities will let you know what's going on with the servers in terms of hardware resources. Also monitor the firewall and the load balancer (many times you can do this via SNMP) -- but these devices are not likely to be a bottleneck at this level, since they usualy can deal with thousands of connections before they hit a limit, assuming they're hardware-based and not software-based.
同时还可以通过前面提到过的命令行工具（top,vmstat,iostat,netstat,Windows PerfMon）来监视web/app和database的服务器。这些工具可以让你了解服务器硬件资源的状况。同时也可以监视防火墙及负载平衡器[可以使用SNMP来做这种事]，但由于这种设备具有很高的处理连接的能力，它们在这一层上并不会有瓶颈的问题出现，因此我们可以假设它们不是基于软件，而是基于硬件的。
This is one of the most important steps in the whole procedure. It's not easy to make sense of the output of these monitoring tools, you need somebody who has a lot of experience in system/network architecture and administration. On Sun/Solaris platforms, there is a tool called the SE Performance Toolkit that tries to alleviate this task via built-in heuristics that kick in when certain thresholds are reached and tell you exactly what resource is being taxed.
现在这一步就是整个流程中最重要的一环。要清楚的理解这些监控工具输出数据并不是一个容易的事情，这需要一些很有系统/网络 结构和管理经验的人的帮助。[让我挥挥小手，]举个例子来讲（译者注：让我想起51峰哥上课意气风发的挥挥小手，我就自己打上前面的[]里的内容了，呵呵！峰哥不要生气！）在SUN/SOLARIS平台上，就有一个叫SE Performance Toolkit的工具可以减轻这种痛苦。它可以通过内建的试探法*[启发式法？]当系统到极限的时候开始工作并告诉你具体承受着负载的资源情况*。
4. Let's say your Web server's reply rate starts to level off around 50 users. Now you have a repeatable condition that you know causes problems. All the profiling and monitoring you've done in step 3, should have already given you a good idea about hot spots in your applicationm about SQL queries that are not optimized properly, about resource status at the hardware/OS level.
4. 唔。。。假设现在你的WEB服务器的回应速度已经平稳在50个用户的情况下*，你重现了一个会导致问题的环境条件*。通过上面的第三步的分析与监控，应该已经让你清楚的了解到你的应用程序内的问题点，没有被充分优化的SQL查询语句，以及硬件及操作系统的资源状况。
At this point, the developers need to take back the profiling measurements and tune the code and the database queries. The system administrators can also increase server performance simply by throwing more hardware at the servers -- especially more RAM at the Web/App server in my experience, the more so if it's Java-based.
到了这里，开发人员就需要取消*掉分析测量而开始调试代码及数据库的查询语句了。系统的管理员则同时可以通过简单的增加更多的硬件资源来提高服务器的性能，从我的经验上来看，特别要给WEB/APP服务器增加RAM，假如它是基于JAVA的则应该更多*。
5. Let's say the application/database code, as well as the hardware/OS environment have been tuned to the best of everybody's abilities. You re-run the load test from step 2 and now you're at 75 concurrent users before performance starts to degrade.
5. 好了，现在application/database代码，以及硬件/操作系统的环境都已经被调整得各个器件都发挥出它最大的功能了。然后你就应该从上面的第二步重新开始进行增加负载的测试，然后你就发现系统在性能开始下降前就，已经可以上到75个并发用户了。
At this point, there's not much you can do with the existing setup. It's time to think about scaling the system horizontally, by adding other Web servers in a load-balanced Web server farm, or adding other database servers. Or maybe do content caching, for example with Apache mod_cache. Or maybe adding an external caching server such as Squid.
在这一时刻，基于现在的这种优化过的硬件设备，你也没什么可以再做的了。也许是时候通过在负载平衡WEB服务器群组内增加其它的WEB服务器，或者增加其它的数据库服务器，也许还可以使用内容高速缓存技术（如使用Apache mod_cache），或者增加一个外部的高速缓存服务器（如Squid）等方法，来扩展一下你的系统了。
One very important product of this whole procedure is that you now have a baseline number for your application for this given "staging" hardware environment. You can use the staging setup for nightly peformance testing runs that will tell you whether changes in your application/database code caused an increase or a decrease in performance.
这整个的流程引出了一个非常重要的产物，就是一组在特定硬件条件下，针对你的应用程序基线化了的标准数值*。而你则可以通过每个阶段的设备来跑每晚的性能测试，而这个又可以让你得知你所改动的应用程序/数据库代码是否会引起性能上的消长*。
6. Repeat above steps in a "real" production environment before you actually launch your application.
6. 你可以在正式应用程序发布前，重复以上的步骤。
All this discussion assumed you want to get performance/benchmarking numbers for your application. If you want to actually discover bugs and to see if your application fails and recovers gracefully, you need to do stress testing. Blast your Web server with double the number of users for example. Unplug network cables randomly (or shut down/restart switch ports via SNMP). Take out a disk from a RAID array. That kind of thing.
这里所讨论的话题都是以你想得到你的应用程序的性能/基准的数值为假设，如果你是想要真正去发现bugs而且去看一下你的应用程序是不是可以在失效后，正常的恢复*，那么你所要做的是压力测试。比如说给你的WEB服务器加上两倍的用户数量，随机的拔掉网线（或者通过SNMP关掉/重启switch ports），从RAID阵列里拿个磁盘出来，等等。
The conclusion? At the end of the day, it doesn't really matter what you call your testing, as long as you help your team deliver what it promised in terms of application functionality and performance. Performance testing in particular is more art than science, and many times the only way to make progress in optimizing and tuning the application and its environment is by trial-and-error and perseverance. Having lots of excellent open source tools also helps a lot.结尾了？其实到了最后，你将你的测试命名为什么都无关紧要，只要你可以帮助你们团队交付出曾经承诺过的功能及性能就行了。[说实在的，]性能测试是一种艺术活，而不是一种科学技术活。很多时候，能够使应用程序及它的运行环境的优化及调试，可以有所进展，只能靠持续不断的反复试验。同时一些优秀的开源工具也可以帮助很多。
SQLSERVER系统数据库tempdb的储存空间已满（转贴）
2007-04-03 12:37:24
性能测试经验分享 （转贴）
2007-04-03 12:17:35
性能测试经验分享
1 性能测试目标 鼀T﹉4町?
• 系统是否满足预期的性能要求 絎E?猭珡a
• 作为对系统进行调优的参考 锽淦3^裤<?
• 系统的可扩展性 檝F?才j(?
• 用性能测试手段发现系统存在的问题 �]Q芏耝g?
• 提供部署方案的参考2 性能指标 )?ψ?8?
• 常用的性能指标如下： N紑?活抖
• CPU利用率 髽f磿]?褕
• 内存占用率 ?咺 ?
• 磁盘I/O Rn餂? Ll7
• 响应时间3 影响性能的因素 ~W崞琚悩
• 网络状况（隔离的网络环境） 镹O鉉\>?
• 硬件设备（CPU数、内存大小、总线速度） -帑躵#5>
• 系统/应用服务器/数据库配置 ?z肠??
• 数据库设计和数据库访问实现（SQL语句） Z稝嚩铍蠀
• 系统架构（同步/异步）6dt塏NG昂
4 性能测试步骤 v徤摥?^}
• 分析性能需求（需求规格说明书） 嬗EX馰緿y%
• 性能测试计划 冪r颚+M蕽?
• 性能测试方案 ?牋lD圮?
• 建立数据模型 椎??芬悥
• 性能测试报告5 性能测试方案应包含的内容 `?>蓝
• 对软件系统架构的分析（了解输入、输出数据的类型、数据量） LR 昒耵?
• 性能测试组网图（网络环境说明） ?輠岑!
• 硬件环境说明 蘓璯酌菌?
• 测试范围、目的与方法 U α匳??
• 性能测试工具的选型[测试工具组成图]
麻 熣嚶
<9??薅揓
• 测试的启动/退出条件 =＠&ЦuX?
• 测试场景详细说明 pE罟3棋{鷧
• 测试执行及测试结果分析6 性能测试场景的选取 ょ邉雪0P?
• 分析性能测试需求 斾袣B舗L
• 选择关键场景 豈瓰�f p?
• 分析输入、输出数据7 大数据量的产生 计:螄 e?
• 在详细分析性能需求的基础上 _靵27讆
• 数据量尽量与实际情况一致腙?$/-7俘
8、性能测试经验 ?s>�渨?
• 测试开始前与产品/开发人员充分协商 {廢=逃态緸
• 测试过程中与开发人员紧密合作 e.崝岟 膆`
• 测试工具：不要迷信LoadRunner 昙7??语
1、针对特定系统的加压工具比LoadRunner更加实用 岪z韖v駷?
2、 尽量考虑使用操作系统本身要点的命令来监测系统资源、完成性能测试 瘶b?:q?
• 对测试人员的要求： ︼J?跃衠T
• 1、熟悉系统架构 罈棿o伊
• 2、熟悉数据库 饔?r�?y枨
• 3、熟悉操作系统LoadRunner与Winsock协议（转贴）
2007-04-03 11:32:20
标题搜索
我的存档
数据统计
- 访问量: 19690
- 日志数: 38
- 建立时间: 2007-02-08
- 更新时间: 2010-06-30
