下面分享一部分如何减少功能缺陷漏测的干货吧，与各位共勉：    

            功能内子功能的场景插入法

1.在测试过程中发现严重的bug同时告知开发人员，让其优先处理。免得影响后面的测试用例的执行以及整个项目的进度。

2.多次修改数据后看前台相关位置的显示是不是正确的？可能前台显示会有问题，因为写法不一样。如广西项目中的新产品行业属性被多次修改后，会显示为空，显示不正确。但在后台中显示是正确的。平时测试需多注意操作流方面的测试。如修改后进行新增，修改后删除，修改后搜索等。连续新增，连续修改操作。在这种操作流中，会发现一些存在的bug.

3.程序员改bug的时候写下此bug产生的原因，修改的内容，这样有利于测试在回归bug时清楚需要测试的范围和有影响的功能。


4.回归测试与兼容性测试结合起来，有时会带来兼容性问题，需要注意。


5.写bug时，写明bug的相关位置（该bug存在多个位置），什么不该包括，以便修改bug时，能尽量在一轮次中搞定。

6.测试过程不能只满足于发现bug,需要分析bug,定位bug,分析bug的频繁处，从而改进测试用例的深度。对自己是一个提升。

问题出现：
n    VuGen替代浏览器，脚本是hard-coded
n    HTTP是一种无状态的连接
n    同一用户两次登录的差异
n    单用户和多用户的差异(验证机制：session）
 
关于session
 
n    记录用户的状态
n    验证用户的身份
n    在服务端创建并保存（永久的和临时的）
n    Session也保存在客户端，提交到服务器端验证（URL重写和cookies)
问题分析
n    用一种方法来满足服务器的验证。
n    保存来自服务器端的session，并传递给提交语句以保证验证通过。
 
 
需要关联的数据的特征
 
 
n    1,数据是从服务器传过来的。
 
n    2,数据是可变的。
 
VuGen与服务器的交互
关联的主要条件
n    1,简化或者优化代码。
n    2,动态数据。
n    3,提供唯一的数据。
如何鉴定什么样的错误需要关联
n    会出现什么错误讯息，与系统实做的错误处理机制有关。
n    错误讯息有可能会提醒您要重新登入，但是也有可能直接就显示HTTP 404的错误讯息。
n    在LR的LOG中也有些错误的提示:比如：27979等的错误（错误的原因是多种的，关联只是引起错误的一种原因）。
LR中需要用到的关联函数
n      web_create_html_param Saves dynamic information on an HTML page to a parameter. (Obsolete: use only for LR 6.5 and below)
n      web_create_html_param_ex Saves recurring dynamic information on an HTML page to a parameter. (Obsolete: use only for LR 6.5 and below)
n       web_reg_save_param Saves non-NULL terminated dynamic data from an HTML page to a parameter.
n      web_save_param_length Saves the length of a parameter
n      web_save_timestamp_param Saves the current timestamp. web_set_max_html_param_len Sets the maximum length of retrieved dynamic HTML information.
VuGen的关联方法
 
 
n    自动关联
 
n    手动关联
自动关联
n    record options--->correlation中启用enable correlation during recording recording.LR会用自已的关联规则来匹配需要关联的脚本

手动关联
n    步骤：
1,录制。
2,回放。
3,回放出错后开启LOG。
4,出错后查看LOG。（定位到某一行）
5,再重新录制一下脚本，把两份脚本对比。
 
 
 
录制回放
n    回放出错如下：
Action.c(37): Error -27979: Requested form. not found     [MsgId: MERR-27979]

Action.c(37): web_submit_form("com.mercurytours.servlet.IteneraryServlet") highest severity level was "ERROR", 0 body bytes, 0 header bytes         [MsgId: MMSG-26388]

 

开启LOG查找需要关联的数据
n    run-time settings-->Log，设置Extened log.
n    再次回放。
n    定位需要关联的数据。（单协议在recording log，多协议在Generation Log中查到数据）
 
写关联函数
n      char GlParam1_Text1;//定义变量
 
n      web_reg_save_param("GlParam1_Text1",
n                "LB= name=\"",
n                "RB=\"",
n                "Ord=all",
n                "RelFrameId=1",
n                "Search=Body",
n                "IgnoreRedirections=Yes",
n                LAST);
n      在下面的语句中来调用： GlParam1_Text1
 
 
 
 
关联函数的位置
n     It registers a request to find and save a text string within the server response. The operation is performed only after executing the next action function, such as web_url. （from help).
n     定位到变量的那一行的上面。
 
Note:引用web_reg_save_param中的变量时，要用｛｝。
要打印出来，用lr_evel_string取值。
一些说明：
n     开启WinDiff时出现File no longer available的错误信息
WinDiff这个工具有些限制，脚本路径不能有空格。
n     ctrl+F8可以扫描脚本中需要关联的地方

 

 你的Web服务器和应用到底能够支持多少并发用户访问？在出现大量并发请求的情况下，软件会出现问题吗？这些问题靠通常的测试手段是无法解答的。本文介绍 了Microsoft为这个目的而提供的免费工具WAS及其用法。另外，本文介绍了一种Web应用的性能优化方法，并利用WAS测试了它的性能改善程度。

   随着服务器端处理任务的日益复杂以及网站访问量的迅速增长，服务器性能的优化也成了非常迫切的任务。在优化之前，最好能够测试一下不同条件下服务器的性能表现。找出性能瓶颈所在是设计性能改善方案之前的一个至关紧要的步骤。

　 　本文介绍Microsoft的Web Application Stress Tool（WAS，Web应用负载测试工具）在Web服务器性能测试中的应用（注：Stress基本含义为“重压；压力”等，本文称之为“负载”）。另 外，我们还将通过WAS评估一种相对简单的网站性能改善方法，这种方法的基本思想是在服务器上生成静态的HTML页面、避免过多的数据库调用。

　　负载测试是任何Web应用的开发周期中一个重要的步骤。如果你在构造一个为大量用户服务的应用，搞清楚你的产品配置能够承受多大的负载非常重要。如果你在构造一个小型的Intranet网站，测试能够暴露出最终会导致服务器崩溃的内存漏洞以及竞争情况。

    无论是哪种情形，花些时间对应用进行负载测试可以获得重要的基准性能数据，为未来的代码优化、硬件配置以及系统软件升级带来方便。即使经费有限的开发组 织也可以对它们的网站进行负载测试，因为Microsoft的WAS是可以免费下载的。WAS要求Windows NT 4.0 SP4或者更高，或者Windows 2000。为了对网站进行负载测试，WAS可以通过一台或者多台客户机模拟大量用户的活动。WAS支持身份验证、加密和Cookies，也能够模拟各种浏 览器类型和Modem速度，它的功能和性能可以与数万美元的产品相媲美。如果你对WAS和Microsoft的另外一个测试工具Web Capacity Analysis Tool （WCAT）之间的差别感兴趣，可以访问Microsoft Web工具的比较页面。 

   要对网 站进行负载测试首先必须创建WAS脚本模拟用户活动。我们可以用下面四种方法之一创建脚本：通过记录浏览器的活动；通过导入IIS日志；通过把WAS指向 Web网站的内容；或者手工制作。图1所显示的是通过记录浏览器事件生成的脚本的一部分，网站是Microsoft的Duwamish Book Store。Duwamish是Microsoft开发的电子商务Web应用示例，从Duwamish网站的“Phase 4”链接可以下载这个软件包。下载包中包含了它自己的WAS测试脚本。 

 

     
    【图1】 

    制作WAS脚本是相当简单的，不过要制作出模拟真实用户活动的脚本有点儿复杂。如果你已经有一个运行的Web网站，可以使用Web服务器的日志来确定Web网站上的用户点击分布。如果你的应用还没有开始运行，那么只好根据经验作一些猜测了。

　 　图1这个脚本中我们假定有30个会员在浏览书店，同时又有一个会员正在购买。要模拟两者混合而成的行为，首先必须创建页面组并在脚本的Page Group分枝确定点击分布情况。在Page Group分枝中我们可以增加、修改或删除页面组，也可以为各个组修改流量的分布。

　　图2显示了grp_browse和grp_buy这两个页面组以及30比1的流量分布

       【图2】

   创建了页面组之后，我们就可以在主脚本视图中赋予各个请求不同的页面组，如图3所示。为每个请求指定页面组相当于告诉WAS如何分布流量。记住在本例中对grp_buy组页面的请求约占总数的3%，而对grp_browse组页面的请求约占97%。

 

     【图3】

    如果需要在查询字符串中传递“名字-值”对，可以用WAS的查询字符串编辑器来定义各个变量的所有可能的值。在输入变量值后，既可以要求WAS顺序地使用 变量的各个值，也可以要求WAS在请求时随机选择变量值。这在一定程度上增加了脚本所模拟行为的真实性，也可以帮助避免缓冲对测试结果的影响准备好测试脚 本之后，我们可以调整测试配置以便观察不同条件下的应用性能。图4是WAS的设置界面

【图4】
      

   Stress Level和Stress multiplier这二个项决定了访问服务器的并发连接的数量。Microsoft建议不要选择超过100的Stress Level值。如果要模拟的并发连接数量超过100个，可以调整Stress multiplier或使用多个客户机。在负载测试期间WAS将通过DCOM与其他客户机协调。有关在测试中使用多个客户机的更多信息，参见http://webtool.rte.microsoft.com/kb/hkb13.htm。

　 　如果网站提供个性化服务，要进行身份验证或使用Cookies，我们还要为WAS提供一个用户目录。WAS中的用户存储了发送给服务器的密码以及服务器 发送给客户端的Cookies。增加用户数量并不增加Web服务器的负载。必须提供足够数量的用户以满足并发连接的要求（Stesss Level乘以Stress Multiplier）。有关线程、用户、Cookies相互作用的更多信息请参见http://webtool.rte.microsoft.com/Threads/WASThreads.htm。 

    WAS允许设置warmup（热身）时间，一般可以设置为1分钟。在warmup期间WAS开始执行脚本，但不收集统计数据。warmup时间给 MTS、数据库以及磁盘缓冲等一个机会来做准备工作。如果在warmup时间内收集统计数据，这些操作的开销将影响性能测试结果。

　　设置页 面提供的另外一个有用的功能是限制带宽（throttle bandwidth）。带宽限制功能能够为测试模拟出Modem（14.k K，28.8 K，56 K）、ISDN（64 K，128 K）以及T1（1.54 M）的速度。使用带宽限制功能可以精确地预测出客户通过拨号网络或其他外部连接访问Web服务器所感受的性能。

　　要理解这些不同的设置对应用的影响，有必要了解如何使用WAS收集性能数据。

   使用WAS，从远程Windows NT和Windows 2000机器获取和分析性能计数器（Performance Counter）是很方便的。加入计数器要用到图5所示的Perf Counters分枝。

  

  【图5】

   一般情况下，这里需要添加的性能计数器有：
  1 WEB Server:

    · 处理器：CPU使用百分比（% CPU Utilization）
    · 内存：  内存使用百分比（%Memory Utilization）
    · 线程：  每秒的上下文切换次数（Context Switches Per Second (Total)） 
    · ASP：每秒请求数量（Requests Per Second） 
    · ASP：请求执行时间（Request Execution Time） 
    · ASP：请求等待时间（Request Wait Time） 
    · ASP：置入队列的请求数量（Requests Queued）

   2 各个WAS测试机 

   · 处理器：CPU使用百分比（% CPU Utilization）
   · 内存：  内存使用百分比（%Memory Utilization）

    在测试中选择哪些计数器显然跟测试目的有关。虽然下面这个清单不可能精确地隔离出性能瓶颈所在，但对一般的Web服务器性能测试来说却是一个好的开始。 
    
    · 线程：每秒的上下文切换次数（Context Switches Per Second (Total)） 
    · ASP：每秒请求数量（Requests Per Second） 
    · ASP：请求执行时间（Request Execution Time） 
    · ASP：请求等待时间（Request Wait Time） 
    · ASP：置入队列的请求数量（Requests Queued）

　　CPU使用百分比反映了处理器开销。CPU使用百分比持续地超过75%是性能瓶颈在于处理器的一个明显的迹象。每秒上下文切换次数指示了处理器的工作效率。如果处理器陷于每秒数千次的上下文切换，说明它忙于切换线程而不是处理ASP脚本。

    每秒的ASP请求数量、执行时间以及等待时间在各种测试情形下都是非常重要的监测项目。每秒的请求数量告诉我们每秒内服务器成功处理的ASP请求数量。执行时间和等待时间之和显示了反应时间，这是服务器用处理好的页面作应答所需要的时间。

　  我们可以绘出随着测试中并发用户数量的增加每秒请求数量和反应时间的变化图。增加并发用户数量时每秒请求数量也会增加。然而，我们最终会达到这样一个 点，此时并发用户数量开始“压倒”服务器。如果继续增加并发用户数量，每秒请求数量开始下降，而反应时间则会增加。要搞清楚硬件和软件的能力，找出这个并 发用户数量开始“压倒”服务器的临界点非常重要。

　　置入队列的ASP请求数量也是一个重要的指标。如果在测试中这个数量有波动，某个COM对象所接收到的请求数量超过了它的处理能力。这可能是因为在应用的中间层使用了一个低效率的组件，或者在ASP会话对象中存储了一个单线程的单元组件。

　　运行WAS的客户机CPU使用率也有必要监视。如果这些机器上的CPU使用率持续地超过75%，说明客户机没有足够的资源来正确地运行测试，此时应该认为测试结果不可信。在这种情况下，测试客户机的数量必须增加，或者减小测试的Stress Level。

   每次测试运行结束后WAS会生成详细的报表，即使测试被提前停止也一样。WAS报表可以从View菜单选择Reports查看。下面介绍一下报表中几个重要的部分。

　　如果这是一个新创建的测试脚本，你应该检查一下报表的Result Codes部分。这部分内容包含了请求结果代码、说明以及服务器返回的结果代码的数量。如果这里出现了404代码（页面没有找到），说明在脚本中有错误的页面请求。

　 　页面摘要部分提供了页面的名字，接收到第一个字节的平均时间（TTFB），接收到最后一个字节的平均时间（TTLB），以及测试脚本中各个页面的命中次 数。TTFB和TTLB这两个值对于计算客户端所看到的服务器性能具有重要意义。TTFB反映了从发出页面请求到接收到应答数据第一个字节的时间总和（以 毫秒计），TTLB包含了TTFB，它是客户机接收到页面最后一个字节所需要的累计时间。

　　报表中还包含了所有性能计数器的信息。这些数据显示了运行时各个项目的测量值，同时还提供了最大值、最小值、平均值等。报表实际提供的信息远远超过了我们这里能够介绍的内容。为了给你一个有关表所提供信息种类的印象，图6摘录了一个报表实例。

 

【图6】

    随 着Internet应用的日益广泛，用户的要求和期望也在不断地发展。今天的客户期待个性化的可定制的方案，期待这些方案不仅简单，而且快速、可靠、成本 低廉。对于能够适应用户需求不断变动的可定制页面来说，静态HTML已经退出了舞台，比如内容根据客户请求变化的页面就是其中一例。这一切都要求系统保存 相关的数据，例如有关用户本身以及用户可能请求哪些信息的数据。

　　紧跟这些趋势的Web开发者已经开始提供可定制的Web网站。象搜索数据之类的任务现在可以由服务器执行而无需客户干预。然而，这些变革也导致了一个结果，这就是许多网站都在使用大量的未经优化的数据库调用，从而使得应用性能大打折扣。

我们可以使用以下几种方法来解决这些问题： 
    1. 优化ASP代码。 
    2. 优化数据库调用。 
    3. 使用存储过程。 
    4. 调整服务器性能。

　　优秀的网站设计都会关注这些问题。然而，与静态页面的速度相比，任何数据库调用都会显著地影响Web网站的响应速度，这主要是因为在发送页面之前必须单独地为每个访问网站的用户进行数据库调用。

　 这里提出的性能优化方案正是基于以下事实：访问静态HTML页面要比访问那些内容依赖于数据库调用的页面要快。它的基本思想是：在用户访问页面之前，预 先从数据库提取信息写入存储在服务器上的静态HTML页面。为了保证这些静态页面能够及时地反映不断变化的数据库数据，必须有一个调度程序管理静态页面的 生成。

　　当然，这种方案并不能够适应所有的情形。例如，如果是从持续变化的大容量数据库提取少量信息，这种方案是不合适的。不过可以适用该方案的场合还是很多。
为了保证能够在合适的时间更新静态HTML页面，把下面的代码加入到相应的ASP页面前面：
<%
lastUpdated=Application("LastUpdated")
presentTime=now

if DATEDIFF("h",LastUpdated,presentTime)>=1 then

Application("LastUpdated")=presentTime
response.redirect
"Update.asp?physicalpath="&Request.ServerVariables("PATH_TRANSLATED")
end if

%>
<html>
Static content goes here
</html>

    每当该页面被调用，脚本就会提取最后的更新时间并将它与当前时间比较。如果两个时间之间的差值大于预定的数值，Update.asp脚本就会运行；否则，该ASP页面把余下的HTML代码发送给浏览器。

　　最后更新时间从Application变量得到，它的第一次初始化由global.asa完成。具体的更新时间间隔应根据页面内容的更新要求调整。

　　如果每次访问ASP页面的时候都要提供最新的信息，或者输出与用户输入密切相关，这种方法并不实用，但这种方法可以适应以固定的时间间隔更新信息的场合。

　　如果数据库内容由客户通过适当的ASP页面更新，要确保静态页面也能够自动反映数据的变化，我们可以在ASP页面中调用Update脚本。这样，每当数据库内容改变时服务器上也有了最新的静态HTML页面。
另一种处理频繁变动数据的办法是借助Microsft SQL Server 7.0的Web助手向导（Web Assistant Wizard），这个向导能够利用Transact-SQL、存储过程等从SQL Server数据生成标准的HTML文件。
　　利用SQL Server任务，Web助手向导能够用来定期地生成HTML页面。正如前面概要介绍的方案， Web助手可以通过触发子更新HTML页面，比如在指定的时间执行更新或者在数据库数据变化时执行更新。

　 　SQL Server使用名为sp_makewebtask的存储过程创建HTML页面，它的参数是目标HTML文件的名字和待执行存储过程的名字，查询的输出发 送到HTML页面。另外，也可以选择使用可供结果数据插入的模板文件。 从前面的代码可以看出，当ASP页面HtmlMain.asp需要更新时，控制以ASP文件的物理路径为参数转到了Update页面。Update脚本的 任务是用新的HTML数据刷新发出调用的ASP文件，并把调度ASP代码加入到文件的开头。为此，Update脚本打开调度模板文件，拷贝调度ASP代 码，然后控制转到了另一部分脚本，这部分脚本主要任务是执行数据库操作。Update用路径参数以写模式打开HtmlMain.asp文件，数据库操作的 输出以HTML格式写入这个文件。

　　万一用户访问页面的时候正好在执行更新，我们可以利用锁或者其他类似的机制把页面延迟几秒钟。 HtmlMain.asp（纯HTML加调度ASP代码）和main.asp（普通的ASP文件）在WAS下进行了性能测试。main.asp文件要查找 5个不同的表为页面提取数据。为了和这两个文件相比较，一个只访问单个表的ASP页面（SingleTableTest.asp）和一个纯HTML文件 （PlainHtml.html）也进行了测试。

 测试结果如下表所示：
文件名字 命中数 平均TTFB（ms） 平均TTLB（ms）
PlainHtml.html 8 47 474
SingleTableTest.asp 8 68.88 789.38
Main.asp 9 125.89 3759.56
HtmlMain.asp 9 149.89 1739.89

     其中TTFB是指Total Time to First Byte，TTLB是指Total Time to Last Byte。

　 　这些测试在一台Windows NT Workstation 4.0 SP6 运行Personal Web Server的机器上实施。为了使性能指标更明显，带宽限制到了14.4 K。在实际环境中数值变化可能很大，但这个结果精确地反映了各个页面在性能上的差异。

　　测试结果显示访问单个表的ASP页面的处理时间是 720.5ms，而纯HTML文件则为427ms。Main.asp和HtmlMain.asp的输出时间相同，但它们的处理时间分别为 3633.67ms和1590ms。也就是说，在这个测试环境下我们可以把处理速度提高43%。 

    如果我们要让页面每隔一定的访问次数更新，比如100次，那么这第100个用户就必须等待新的HTML页面生成。不过，这个代价或许不算太高，其他99个用户获得了好处。

　　静态页面方法并不能够适合所有类型的页面。例如，某些页面在进行任何处理之前必须要有用户输入。但是，这种方法可以成功地应用到那些不依赖用户输入却进行大量数据库调用的页面，而且这种情况下它将发挥出更大的效率。

　　在大多数情况下，动态页面的生成将在相当大的程度上提高网站的性能而且无需在功能上有所折衷。虽然有许多大的网站采用了这个策略来改善性能，也有许多网站完全由于进行大量没有必要的数据库调用而表现出很差的性能。

　　Microsoft的WAS是一个功能非常丰富的服务器性能测试工具，可以帮助我们准确地判断什么方案将适合于提升网站性能；是否某个方案（比如本文第二部分的静态页面方案）能够显著地改善性能。

　　本文对WAS的介绍应当说是相当粗略和肤浅的。WAS还提供了一个对象模型，我们可以通过脚本扩展它的功能。访问http://webtool.rte.microsoft.com/?ObjModel/default.htm可以看到一个脚本示例。这个脚本将登记Web服务器的每秒最大请求数量，自动地增加Stress Level值直到服务器处理器利用率达到90%为止。

　　WAS能够为你提供有关ASP应用和它所运行的硬件的丰富的信息。在WAS上花费一些时间，你就能够更深入地了解你的应用的性能、稳定性、瓶颈和局限性。花费这种时间是值得的。

· 建立页面组和点击百份比

· 建立用户帐号

· 建立客户端

· 建立性能计数器

调节脚本项
 

在修改一个测试脚本的脚本项时需要考虑几点，我们将在下面介绍。

去掉不需要的脚本项
去掉冗余项以减少在测试中的噪声因素，或者去掉那些无效的URL。当要调整一项特殊的功能时，去掉所有指向图象，样式表单和其他辅助静态文件的脚本项。

为脚本项指定思考时间
脚本项表单的最后一项叫做“延迟”。这项允许你在执行脚本项之前指定特定的延迟时间（也叫思考时间）。

对于性能测试来说，如何定义思考时间并没有一个单独的标准。有些人使用零思考时间，有些人考虑使用30秒为思考时间。

主要取决于站点的内容和测试的目的。例如，有长页面内容的站点需要比简单页面的站点使用长一点的时间，因为用户需要使用多点的时间来读页面内容。

另外，如果你的目的是快速地决定一个只有少量客户端的Web服务器的吞吐量，你可以考虑零思考时间。没有思考时间的话，WAS的每个线程以最快速度对Web服务器施加压力。

为脚本项设置一系列的值
WAS允许你为一个脚本项的一对名字-值赋值，而不是对每一个请求都使用相同的值。这个特性对于模拟真实情形很重要，没有用户会不停的以相同的数据值请求同一页面吧？

例如，其中一项测试脚本是请求一个ASP页面展示一个产品的详细信息。我们可以设置WAS随机地从一列预先定义的产品ID选取不同的值，而不是每次都用相同的产品ID请求ASP页面。

为脚本项建立一列值

1. 在WAS窗口的脚本项，双击脚本项最前面的方型按钮（在表单的第一列）打开这项的详细菜单。

2. 在Querystring标签里（也叫Querystring Editor,如Figure 3所示），选定Format data to CGI standard。相应的名字-值对会出现在check box下的表单里。

Figure 3. Querystring Editor screen

3. 点选定的名字-值对的值，一个新的按钮会出现

4. 点这个按钮打开Field Values对话框

5. 在Field values对话框输入一串值，每一行一个值。你也可以通过剪切，粘贴一个电子表格的数据文件来输入。

6. 在Querystring Editor里，在表单中点有相同名字-值对的Distribution一列。在下拉菜单选择Random。

为脚本项设置SSL
为特定的脚本项激活SSL，需要作以下操作：

1. 在WAS窗口的脚本项，双击脚本项最前面的方型按钮（在表单的第一列）打开这项的详细菜单。

2. 在 SSL标签里，选Use SSL. (注意在你激活SSL时确保端口值应该在80到 443之间)。

调整脚本设置
为了您能满意地运行你的性能测试，你需要修改你的测试脚本的设置。通过双击左边的脚本名展开脚本的信息，你会找到一个Settings标签，在这里你可以为你的测试脚本指定很多设置。点击它将在右边窗口打开Settings视图，如Figure 4所示。

Figure 4. Settings view screen

指定目标Web服务器
默认地，目标服务器是“localhost”，应该替换为IP地址或目标服务器的域名。

改变设置

1.在左边的窗口点测试脚本的名字

2.在右边窗口顶部的Server输入目标服务器的IP地址或域名

注意  如果你想对有Network Load Balancing（网络负载均衡）的服务器群组进行测试，就像Duwamish Online一样，则需要输入IP地址群。

设置并发连接数
在设置里的Concurrent Connections部分，你可以指定Stress level (threads)的值和Stress multiplier (sockets per thread)来控制对目标服务器的压力/负载程度。Stress level是全部客户端所产生的Windows NT线程的总数。每个线程能产生多个socket而每个socket就是一个并发的请求。

以下公式解释了他们之间的关系：

Total Concurrent Requests = Stress level (threads) x Stress multiplier
(sockets per thread) = Total Number Sockets

在我们的实验室，我们使用不同的Stress层次来 性能测试。例如，我们使用过100, 200, 300, 400, 500, 750, 1000, 1500,和2000的值来连续测试以研究我们的服务器群组是如何对连续增长的负载作出反应的。

你应该在初步测试的结果基础上调整这些数值。通常来说，你需要在低负载度时收集更多的数据点，因为这时候系统的吞吐量会随线程的增长而线性增长。另一方面，你可以在高负载度时运行较少的测试以节省时间和精力，尤其是系统吞吐量已经高于峰值时。

注意我们的第一次测试将设定在1000个线程。目的是运行足够的请求以建立我们程序的数据缓冲。因为程序的性能会因为有没有缓冲而表现大不相同，这将帮助我们为负载测试保持一个一致的环境。

设定测试运行时间
在设置视图的Test Run Time部分，你可以以日，小时，分钟，秒来设定总的运行时间。取决于你的脚本项的预期反应时间，建议你运行测试脚本至少若干分钟以便产生足够的请求，避免变形的测试结果。你的程序的反应时间越高，测试进行的时间就应该越长，以便产生大量的数据。

你可以运行短而密集的测试以便监测你的站点的任何问题。另外，你需要运行更长的测试时间（例如，30天），看看你的站点的性能是否随时间而退化，尤其是在中级或高级的负载压力下。

在Duwamish Online这个站点，大多数的性能测试都运行7到10分钟，以便有足够时间来稳定测试结果。

设置随机延迟时间
在设置视图的Request Delay部分，你可以在执行测试前为每个脚本项选择加入随机延迟时间（或思考时间）。如果Use random delay选项框被选中，每个WAS线程会空转一段随机的时间（在最大值和最小值之间）加上为每个脚本项指定的固定的思考时间。

下面的公式解释了延迟时间的计算方法：

每项的延迟时间=随机延迟时间+每项的固定延迟时间

随机延迟时间的特性在固定延迟时间被指定给脚本项时尤为重要。如果没有使用随机延迟时间，所有的线程会在几乎相同的时间发送请求到Web服务器，然后等待几乎相同的固定延迟时间然后发送下一个请求。随机延迟时间在向Web服务器施加负载时有助于压平峰值和谷值，因此为所需的负载水平呈现一个更为精确的环境。

设定挂起时间
在设置视图的Suspend部分，你可以以日，小时，分钟，秒来设定warmup 和cooldown时间。Warmup时间就是初始化测试运行时间，在这段时间里不会收集和计算性能数据。类似地，cooldown时间就是指定结束阶段的测试时间，也不收集数据。Warmup 和 cooldown被用于最小化测试结果的失真。

通常，在一个新测试运行的初始化阶段，很多系统资源是被特定的活动所消耗，像组件或应用程序的缓冲初始化。Warmup时间有助于在任何测试数据被收集之前稳定系统的环境。

另一方面，cooldown时间有助于在测试运行的结束阶段避免数据的变形，这时额外的系统资源被用于停止测试和开始从客户端收集数据。另外，socket连接可能会过早地停止，造成大量的socket错误。

在Duwamish Online，我们使用30 到 60秒作为大多数性能测试的warmup 和 cooldown时间

指定带宽瓶颈
在设置视图里的Bandwidth部分，WAS允许你模拟从14.4 Kbps的modem连接到T1 (1.5 Mbps)的Local Area Network (LAN)连接的网络带宽。这个特性的最大好处是可以支撑大量的并发连接到目标服务器。这是大多数Web站点（用户使用低速modem连接）所体验的情形。

激活带宽瓶颈

1.在设置视图里的Bandwidth部分，选择Throttle bandwidth选项框。

2.在下拉菜单，选择一个代表大多数用户的连接吞吐量的带宽。

在Duwamish Online里，我们试过不同的带宽瓶颈的设置。初始化时。我们把用户连接设在56 Kbps，想明白我们的程序在大多数Web站点的情况下是如何表现的。我们也试过把用户连接设在ISDN Dual Channel (128 Kbps)以模拟未来宽带趋势下，我们的大多数用户通过快速的连接访问我们的站点。最后，我们以没有带宽瓶颈的情形测试我们的站点。有趣的是，我们发现这种设置产生的负载条件与用128 Kbps连接的一样。

不管你如何设置带宽瓶颈，务必要在你想比较测试结果的所有测试中保持一致性。

指定其他设置
在设置视图的其他部分，我们保持默认值，除HTTP重定向外。我们故意去掉Follow HTTP redirects选项。这在创建脚本过程中你录制脚本时已经录制了URL的重定向的时候是必须的。你不需要重复两次地运行那些URL。

设置页面组
在WAS里，你可以把一系列的脚本项组织成所谓的页面组。这个特性允许你把所有的页面元素（包括HTML文件，图象文件，样式表单等）或多个相连的页面组织成一个逻辑单元。你可以为每个页面组指定不同的点击率，那样就能控制哪个页面或相连的页面会访问更多或更少。如果你有你的网站的使用方法—像目录浏览或购物车—页面组允许你以你希望你的站点会获得的点击率来运行。

建立页面组

1. 展开左边窗口的脚本的信息

2. 点Page Groups节点在右边窗口打开相应的视图

你会看到默认的以100%分布率的页面组已经创建好了。所有的脚本项默认都初始化为这个组。

3. 在组表单的空白行，在Group列输入新的组名（像"Home"作为主页），在Distribution列输入数值。分布率会被用于计算这个页面组的点击率，见Percent列。重复这个步骤添加更多的页面组。

4.点左边窗口的脚本名回到该脚本项的视图

5.在脚本项表单的Group列，从下拉菜单选择其中一个页面组。为每个脚本项重复这个步骤。所有关联的页面都应该选同样的页面组。

Figure 5. Example of page groups definition

6.点左边窗口的脚本名回到该脚本项的视图

7. 在脚本项的表单的Group一列，从下拉菜单选则其中一个页面组，见Figure 6。

Figure 6. Script. Items view screen showing group selection

8. 重复6到7为每一个脚本项选择一个页面组。所有相关项（像ASP 页面，样式表单和图象文件）应该选择相同的页面组。

另一种创建和指定页面组的方法是在录制脚本时指定页面组。要使用这种方法，在浏览器跳到新的页面之前返回到WAS窗口（见Figure 2）。点Change Group按钮然后在New Group对话框输入组名。以后录制的脚本项都会被指定到这个新的组。

指定用户
测试需要署名登录的Web站点时，WAS提供一个特性叫做Users，可用于存储多个用户的用户名，密码和cookie信息。

当一个测试开始时，所有的用户被分配到给定压力系数设置的各线程中。当请求开始时，每个线程使用从与该线程连接的共享池中获得的用户名，密码，和cookie。如果WAS配置的用户数比线程少，一些线程就会没有用户—所有的署名登录页面会登录取失败，任何与cookies的交互会被禁止。所以，当测试需要个人认证的网站时，拥有的用户数比线程多是很重要的。

对于可以在WAS中创建的用户数没有硬性的规定和限制。然而，因为每个用户都会需要一定的内存和资源，所以如果使用大量的用户，将会使你的测试启动和停止时间更长些。

创建新用户

1.在左边窗口展开脚本的信息

2.点Users节点在右边窗口打开相应的视图

3. 双击Default用户组打开用户视图。

注意默认已经创建了200个用户。你可以简单地修改用户名和密码就行了。

你也可以做以下操作来创建一系列新的用户

1.点Remove All清除所有的记录

2. 在Number of new users，输入你想创建的新用户的数量

3. 在User name prefix，你可以在用户编号的前面输入前缀值，例如“User.”

4. 在Password，输入密码。相同的密码会赋给所有用户。

5. 最后，点Create按钮。用户表单就会填满指定数量的用户

如果你想使用定制的用户名和密码列表，你可以从一个预定格式的文本文件导入它们。参考WAS帮助文件的“Importing user names and passwords”部分。

 

 

内容
介绍
使用WAS的好处
WAS的缺陷
安装WAS
创建测试脚本
配置测试脚本
运行测试脚本
结论：最好的习惯

介绍
性能测试是成功发布一个网络应用的关键因素。当越来越多的用户访问你的站点时，清楚地知道你的应用程序和你的服务器群是怎样工作的就显得非常重要了。

为了给你的网络应用程序模拟出那种类型的使用，你可以协同几百甚至上千的真实用户在一段设计好的时间段里访问你的站点，你也可以只与一个能复制这么多用户负载的测试工具一起工作，

许多性能测试工具可以帮你的忙。基本上，这些工具都允许你以有限的客户端模拟大量的虚拟用户，并发地访问预先确定的页面或网站的URLs (Uniform. Resource Locators)。每一个虚拟用户都能精确地仿效在真实浏览器和网站服务器之间进行通讯协议。

在这篇文章里，我们将专注于其中一个这样的工具：Microsoft® Web Application Stress (WAS)工具。你可以在微软的Microsoft Windows® 2000 Resource Kit CD (WAS version 288)里面找到这个工具。

注意      WAS不能再从Microsoft的网站下载了，Visual Studio .net 的企业架构 和 企业开发版本都包含一个新的网络压力测试工具，这个工具叫做Application Center Test，是受Microsoft技术支持的工具。这个工具包含在Visual Studio .NET安装时的EntERPrise Development Tools部分。在写这篇文章时，Application Center Test还没有正式公开发表。关于如何得到Visual Studio .NET，请访问Visual Studio网站。

使用WAS的好处
首先，我们来讨论一下使用WAS测试你的应用程序的好处。

它简单
WAS允许你以不同的方式创建测试脚本：你可以通过使用浏览器走一遍站点来录制脚本，可以从服务器的日志文件导入URL，或者从一个网络内容文件夹选择一个文件。当然，你也可以手工地输入URL来创建一个新的测试脚本。

不像其它的工具，你可以使用任何数量的客户端运行测试脚本，全部都有一个中央主客户端来控制。在每一个测试开始前，主客户机透明地执行以下任务：

·与其他所有的客户机通讯

·把测试数据分发给所有的客户端

·在所有客户端同时初始化测试

·从所有的客户端收集测试结果和报告

这个特性非常重要，尤其对于要测试一个需要使用很多客户端的服务器群的最大吞吐量时非常有用。

它的高可用性

WAS是被设计用于模拟Web浏览器发送请求到任何采用了HTTP1.0或1.1标准的服务器，而不考虑服务器运行的平台。

除了它的易用性外，WAS还有很多其它的有用的特性，包括：

·对于需要署名登录的网站，它允许创建用户帐号。

· 允许为每个用户存储cookies 和Active Server Pages (ASP) 的session信息

·支持随机的或顺序的数据集，以用在特定的名字-值对

·支持带宽调节和随机延迟（“思考的时间”）以更真实地模拟显示情形。

·支持Secure Sockets Layer (SSL)协议

·允许URL分组和对每组的点击率的说明

·提供一个对象模型，可以通过Microsoft Visual Basic® Scripting Edition (VBScript)处理或者通过定制编程来达到开启，结束和配置测试脚本的效果。

WSA的缺陷
除了优势外，WAS的确有一些缺陷存在。当前知道的bug和有关事项都列在WAS的网站上了。以下是当前WAS不支持的特性：

· 以前面所发请求返回的结果为基础，修改URL参数的能力。

· 运行或模仿客户端逻辑的能力

· 为所分配的测试指定一个确定数量的测试周期的能力。

· 对拥有不同IP地址或域名的多个服务器的同时测试能力

注意   你可以使用多个主客户端来同时测试多个服务器。然而，如果你想把所有测试结果联系起来成为一个整体，则需要整理从各个WAS数据库得到的数据

· 支持页面在不同IP地址或域名间的重定向的能力

· 从Web浏览器直接记录SSL页面的能力

注意    WSA已经支持SSL页面的测试，但是没有记录它们。你需要在脚本录制完后，手工地为每个设计好的URL打开SSL支持

虽然对这些限制有一些相应的解决办法，但是如果你的应用依赖一个或多个这样的功能的话，你也许不能完全享受WAS带来的好处。

安装WAS
WAS要求Microsoft Windows NT® 4.0 Service Pack 4或以上版本，包括Windows 2000平台。还要求Internet Explorer 4.0以上版本，与Internet Explorer 5.0工作更好。

要安装WAS，首先下载最新版本的setup.exe程序，按照安装向导的指示。拷贝并在你的测试机器上安装。

注意   在本文介绍的所有步骤均以WAS version 293为蓝本。

创建测试脚本
虽然你可以手动地创建测试脚本，WAS可以通过记录浏览器活动，导入服务器日志文件或评估Web文件夹的内容来帮助你创建测试脚本。在本文，我们将主要通过记录览器活动的方式来创建测试脚本。采用这个方法而不用其它的方法有几个原因，包括：

· 记录览器活动的方式以精确的方式捕捉所有用户的交互活动。任何从浏览器发往服务器的URL指向，应用程序参数和HTTP头部信息都会被自动地记录在新的测试脚本里。

· 导入服务器日志文件的方法在站点已经进入投入使用阶段，有了真实的用户流量的情况下使用最好。但是，一个新的站点未必有这么多的真实用户使用数据，进一步说，可能还需要合并大量的日志文件来达到较好地体现用户活动的目的，这将需要创建大量的测试脚本，将需要客户端更多的系统资源。

· 选取Web内容文件夹的方法最好用在测试多数是静态HTML文件的站点。这种方法允许在已有服务器的Web页面的基础上快速创建测试脚本。然而，这种方法并不捕捉任何由大多数应用程序文件产生的参数，像Common Gateway Interface (CGI)程序或Active Server Pages (ASP).

你只需要在主客户机器创建和存储你的测试脚本，当测试由主客户端初始化时，测试脚本会自动地分发到其他的测试客户端。

准备测试客户端机器
如果你正在你的内部网通过代理服务器使用WAS ，并且从内部网外的客户端发送请求页面，而且你的公司使用Microsoft Proxy Server，那么按照以下的步骤建立你的客户端：

1. 从开始菜单，指向设置\控制面板。双击管理工具图标，然后是服务图标。

2. 双击WebTool服务打开属性对话框

3. 点Log On As标签，然后点This account选择按钮添加你的网络用户名和密码。使用domain\user name的格式

4. 停止并重起WebTool服务

5. 然后，安装Microsoft Windows Proxy client 2.0，也叫Winsock Proxy 客户端，可以在Microsoft Proxy Server CD里找到（更多有关怎样安装和设置这个软件的信息，请参考包含在CD里面的文档）

6. 对于希望使用代理服务器的每个测试客户端，重复步骤1-5。

如果你的公司使用其他的代理服务器，就要安装该代理服务器的代理客户端。

准备浏览器
在开始录制一个脚本前，你需要准备好你的浏览器，清除你的浏览器的缓冲cache。否则，WAS也许不能记录所需的浏览器活动，因为浏览器可能从缓冲区而不是从所请求的服务器取得请求页面。

关掉IE的缓冲区

1. 在工具菜单，点Internet选项

2. 点常规标签，然后点删除文件。。。按钮。

如果使用IE5。0或以上版本则不需要修改代理设置，因为5。0以上版本的IE允许WAS改变这些设置。然而，对于IE4。0或早期版本，WAS使用一个内置的代理服务器来记录浏览器活动。

按WAS的需要指定代理设置

1. 在工具菜单，点Internet选项

2. 在连接标签里，修改代理设置以使代理服务器指向Localhost并且使用端口8000

3. 不选对于本地地址不使用代理服务器

记录脚本
在你的浏览器和客户端已经准备好记录后，做下面的操作：

1. 当你第一次运行WAS时，你会看到一个Create new script的对话框（Figure 1）,询问你以什么样的方式创建一个新的测试脚本。

Figure 1. Creating the script.

2. 点Record 按钮 。如果之前你选择了Don't display at startup，Create new script将不会显示出来。你可以在Script菜单选择Record 然后 Create.

3. 在Browser Recorder — Step 1 of 2对话框，你会被要求指定一些记录设置。在这里，清除所有的选择框点Next继续。

4. 在Browser Recorder — Step 2 of 2对话框，点Finish。一个新的IE窗口会出现以便记录浏览器活动，同时WAS会被置于记录模式。

5. 在新出现的IE窗口的地址栏，输入你的目的站点的地址。在WAS的窗口你将看到HTTP 信息在跟随你的浏览活动而实时改变着。

6. 当完成了你的站点浏览后，转回WAS窗口—还处于记录状态—点Stop Recording按钮。就会终止记录并产生一个新的测试脚本，如Figure 2所示。

Figure 2. The WAS program window after recording is finished

在右边窗口的底部，你将看到一个列出所有脚本的列表。

对于需要安全连接的站点，WAS支持SSL页面。然而不允许SSL的记录。要解决这些限制，你可以在服务器端关掉SSL，记录脚本，然后再重新激活服务器上的SSL。