Web测试工具WAS使用方法.docx

Web测试工具WAS使用方法.docx

《Web测试工具WAS使用方法.docx》由会员分享，可在线阅读，更多相关《Web测试工具WAS使用方法.docx（25页珍藏版）》请在冰点文库上搜索。

Web测试工具WAS使用方法

Web测试工具WAS认识实验

一、实验目的

1、了解WAS服务器负载测试软件的安装过程，进行安装实验。

2、了解WAS服务器负载测试软件的用途和简单的操作。

3、掌握WAS服务器负载测试软件测试过程。

4、能够使用WAS服务器负载测试软件进行简单的测试工作。

二、实验环境

操作系统：

windows2000Pro+SP4

应用系统：

WAS服务器负载测试软件

三、实验过程

随着网络服务器端处理任务的日益复杂，以及网站访问量的迅速增长，服务器性能的优化已成为非常迫切的任务。

在性能优化之前，测试不同条件下服务器的性能表现，并找出影响性能瓶颈所在，将是Web设计性能改善方案的重要依据。

在构造一个Intranet网站时，负载测试是任何Web应用开发周期中一个重要的环节。

在构造一个为大量用户服务的应用之前，搞清楚产品配置能够承受多大的负载十分重要，测试能够暴露出最终会导致服务器崩溃的内存泄漏、访问阻塞等情况。

但是在实际的构建过程中，若要按照系统真实运行的情况，组织成千上万的用户来进行压力测试，无论从那个方面进行实施，都是不现实的。

因为一旦发现了问题，不仅需要重复的进行这种耗费资源巨大的测试，而且问题并一定能够重现，并不能方便的找出性能的瓶颈或问题所在。

解决这个问题的办法是通过使用软件的办法解决，通过进行软件模拟的方法进行，这就是负载的压力测试。

无论哪种情形，对运用软件进行负载测试可以获得重要的基准性能数据，为未来的代码优化、硬件配置以及系统软件、硬件更新与升级带来依据和提供数据。

1Web服务器负载测试软件介绍

WAS（MicrosoftWebApplicationStressTool，Web应用负载测试工具）提供了一种简单的方法模拟大量用户进行访问目标网站。

这个测试工具能够提供Web应用程序工作时对硬件和软件的使用情况。

为了有效的对Web应用程序进行负载（压力）测试，Microsoft发布了简单易用，功能强大的工具WAS。

WAS要求具备的操作系统必须是WindowsNT4.0SP4或者Windows2000Server，InternetExplorer4.0以上版本。

为了对网站进行负载测试，WAS可以通过一台或者多台客户机模拟大量用户访问Web网站的活动。

WAS支持身份验证、加密和Cookies，也能够模拟各种浏览器类型和Modem速度，它的测试功能和性能表现良好。

使用WAS时，为了更加接近真实的进行压力测试，通常推荐运行WAS的测试机和Web服务器分开。

2WebApplicationStressTool的设置及其操作

2．1主界面窗口

第一次安装完WAS后，可在本机操作系统（以Windows2000Server为例）中找到主界面，通过单击执行，其步骤是：

开始->程序->MicrosoftWebApplicationStressTool。

第一次执行时会出现一个Createnewscript的界面。

2．2制作生成脚本

1．开始使用WAS

要对网站进行负载测试首先必须创建WAS脚本模拟用户的活动。

可以用下面四种方

法之一创建脚本：

●通过记录浏览器的活动。

●通过导入IIS日志。

●通过把WAS指向Web网站的内容。

●手工制作。

这里通过最常用的方法——通过记录浏览器的活动来讲解。

其他三种方法在后面将会提到。

图1简单的Script（脚本）界面

2．录制测试脚本

在录制测试脚本前，需要首先关闭IE的缓冲区。

（1）在工具菜单，点Internet选项

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

如果使用IE5.0或以上版本则不需要修改代理设置，因为5.0以上版本的IE允许WAS改变这些设置。

而对于IE4.0或早期版本，WAS使用一个内置的代理服务器来记录浏览器活动。

按WAS的需要指定代理设置:

●在工具菜单，点Internet选项。

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

●不选“对于本地地址不使用代理服务器”选项。

●打开菜单，选择Scripts|Create|Record创建一个测试脚本。

选取要记录的内容，有下面3种。

图2

Recorddelaybetweenrequest：

记录了请求之间的延迟。

由于用户实际上在浏览网站时，对于请求之间存在几秒甚至几分钟的延迟，这种录制方法在执行时会模仿用户之间的延迟发送请求，所以会是一个更加实际的测试。

如果测试的目的是要发现Web应用程序的承受极限，就不要选择该项；如果只是想模拟一个特定数量的用户场景，那么选择该项进行测试捕捉请求延迟。

Recordbrowsercookies&Recordthehostheader：

只记录用户的会话，不记录延迟时间。

一般情况下，不需要选择这两项，可以让WAS创建cookies和hostheader，这就如同用户登录某个网站一样。

然而，如果有网站的回归信息时（比如一个用户的主要特征信息或者与一个永久性cookies相连的其他信息），在模拟一个新的用户登录网站和进行必要的用户配置测试前，必须保证清除cookies，如果Web应用程序需要用户接受cookies，那么需要选中该选项。

目前这个版本的WAS软件对基于浏览器IE录制脚本的方式还不支持HTTP/SSL请求。

一般情况下，只选择后二种会增加压力的强度。

根据压力测试实际的情况，选择合适的选项，然后点“Next|Finish”，WAS会打开一个IE

窗口，在IE中输入要测试的站点地址，然后就可以按照实际的情况开始浏览站点了，浏览的同时也就是执行测试用例的过程。

图3测试前确定站点地址

等测试用例执行完成后，切换到WAS窗口，点“StopRecording:

”按钮，停止录制脚本。

图4录制结果

WAS回到了视图页面，在该页面中可以看到在录制过程中WAS收集的每一个链接，并且

还可编辑GET、POST以及HEAD信息。

制作WAS脚本较为简单，但要制作出模拟真实用户活动的脚本有些复杂。

如果已经有一个

运行的Web网站，可以使用Web服务器的日志来确定Web网站上的用户点击分布。

如果应

用还没有开始运行，那么只好根据经验作一些猜测了。

图5使用Web服务器日志来确定Web网站上的用户点击分布

3负载参数设置

测试脚本录制完成后，下一步要作的就是配置运行脚本的负载选项，可以调整测试配置以便观察不同条件下的应用性能。

3.1目录树（ContentTree）

由于WAS和WebServer是分开的，所以这里不需要进行设置。

3.2负载选项的设置（Setting）

点击“Setting”即可开始负载选项的设置。

1.ConCurrentConnections

StressLevel（threads）的数值决定了所有客户机创建的Windows的线程的数值。

每一个线程创建多个Socket连接（具体多少Socket连接数取决于Stressmultiplier（socketsperthread）），每个Socket连接就是一个并发的请求（request）。

图6创建多个Socket连接

下面这个公式表示了它们之间的关系：

总的并发请求数=StressLevel*Stressmultiplier=总的Socket连接数

StressLevel和Stressmultiplier这二项决定了访问服务器的并发连接的数量。

Microsoft建议不要选择超过100的StressLevel值。

如果要模拟的并发连接数量超过100个，可以调整Stressmultiplier或使用多个客户机。

在负载测试期间WAS将通过DCOM与其他客户机协调。

2.TestRunTime

设定持续运行多长时间的测试。

可以设定让WAS持续运行多少天、多少个小时、多少分钟、多少秒。

3.RequestDelay（inmilliseconds）

设定请求延迟时间的最大、最小值，当然也可以选择“Userandomdelay”使用随机的延迟时间。

一般情况下，常常会浏览一页，发现一个链接后，点击它。

即使是对该网站熟悉的人，

4.Suspend

WAS允许设置warmup（热身）的时间，一般可以设置为1分钟。

在热身期间WAS开始执行脚本，但不收集统计数据。

热身时间给MTS、数据库以及磁盘缓冲等一个机会来做准备工作。

如果在热身时间内收集统计数据，这些操作的开销将影响性能测试结果。

WAS也允许设置CoolDown时间。

在WAS执行的时间达到设定的TestRunTime时，进入CoolDownTime，这时WAS并没有停止执行脚本，同样也不会收集统计数据。

下图表示了它们的先后关系。

图7WAS进行工作的三个阶段

WarmUp：

不收集统计数据

TestRunTime：

收集统计数据

CoolDown：

不收集统计数据

5.Bandwith（带宽）

设置页面提供的另外一个有用的功能是限制带宽（throttlebandwidth）。

带宽限制功能能够为测试模拟出Modem（14.kK，28.8K，56K）、ISDN（64K，128K）以及T1（1.54M）的速度。

使用带宽限制功能可以精确地预测出客户通过拨号网络或其他外部连接访问Web服务器所感受的性能。

6.Redirects、Throughput、Nameresolution

这几个选项一般情况下采用默认情况即可。

选中FollowHTTPredirects选项将会支持重定向。

选中Throughput中的两项，WAS将会收集活动用户的cookies，以及收集网站的统计数字。

默认情况下都会选中这两项，如果不选择，将会增加压力测试的强度。

Nameresolution默认情况下没有选中。

选中该选项，会让每一个客户测试机执行查询，只有在使用多个子网时才需要选中该项。

3.3PerfCounters（性能计数器）

使用WAS，从远程WindowsNT和Windows2000机器获取和分析性能计数器

（PerformanceCounter）是很方便的。

加入计数器要用到下图所示的PerfCounters分枝。

图8PerfCounters分枝

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

1．WebServer

·处理器：

CPU使用百分比（%CPUUtilization）

·内存：

内存使用百分比（%MemoryUtilization）

·线程：

每秒的上下文切换次数（ContextSwitchesPerSecond（Total））

·ASP：

每秒请求数量（RequestsPerSecond）

·ASP：

请求执行时间（RequestExecutionTime）

·ASP：

请求等待时间（RequestWaitTime）

·ASP：

置入队列的请求数量（RequestsQueued）

2．各个WAS测试机

·处理器：

CPU使用百分比（%CPUUtilization）

·内存：

内存使用百分比（%MemoryUtilization）

在测试中选择哪些计数器显然跟测试目的有关。

虽然下面这个清单不可能精确地隔离出

性能瓶颈所在，但对一般的Web服务器性能测试来说却是好的开始。

•处理器：

CPU使用百分比（%CPUUtilization）

•线程：

每秒的上下文切换次数（ContextSwitchesPerSecond（Total））

•ASP：

每秒请求数量（RequestsPerSecond）

•ASP：

请求执行时间（RequestExecutionTime）

•ASP：

请求等待时间（RequestWaitTime）

•ASP：

置入队列的请求数量（RequestsQueued）

CPU使用百分比反映了处理器开销。

CPU使用百分比持续地超过75%是性能瓶颈在于

处理器的一个明显的迹象；

每秒上下文切换次数指示了处理器的工作效率。

如果处理器陷于每秒数千次的上下文切换，说明它忙于切换线程而不是处理ASP脚本。

每秒的ASP请求数量、执行时间以及等待时间在各种测试情形下都是非常重要的监测项目。

每秒的请求数量表明每秒内服务器成功处理的ASP请求数量。

执行时间和等待时间之和显示了反应时间，这是服务器用处理好的页面作应答所需要的时间。

可以绘出随着测试中并发用户数量的增加每秒请求数量和反应时间的变化图。

增加并发用户数量时每秒请求数量也会增加。

然而，最终会达到这样一个点，此时并发用户数量开始“压倒”服务器。

如果继续增加并发用户数量，每秒请求数量开始下降，而反应时间则会增加。

要搞清楚硬件和软件的能力，找出这个并发用户数量开始“压倒”服务器的临界点非常重要。

置入队列的ASP请求数量也是一个重要的指标。

如果在测试中这个数量有波动，某个COM对象所接收到的请求数量超过了它的处理能力。

这可能是因为在应用的中间层使用了一个低效率的组件，或者在ASP会话对象中存储了一个单线程的单元组件。

运行WAS的客户机CPU使用率也需要监视。

如果这些机器上的CPU使用率持续地超过75%，说明客户机没有足够的资源来正确地运行测试，此时应该认为测试结果不可信。

在这种情况下，测试客户机的数量必须增加，或者减小测试的StressLevel。

3.4PageGroups

对于一个Web应用而言，同一时刻用户点击的分布是不一样的。

WAS允许设置用户点击

流量的分布比例。

图9用户点击流量的分布比例

这里假设在一个Web应用程序中，有650个人同时在线，其中100人正在添加提交数据，占15.38%；有150人正在查询，占23.08%。

按照不同的Web应用，可以根据实际的情况再定制这个比例关系，来更加符合实际的情况。

3.5Users（用户）

现在很多Web应用程序为了提供个性化的服务，都设计了登录过程。

每个用户都有自己的登录名和密码。

WAS考虑到这种情况，只要在Users分支中添加用户名和对应的密码即可。

图10用户登录界面

3.6Clients（客户）

添加多个WAS客户机。

在运行期间，各个WAS客户机是通过DCOM来协调的。

各个

WAS客户机只要正确安装了WAS软件，启动了WebTool服务，它们就可以自己协调操作。

只要在Clients分支内添加WAS客户机即可。

图11添加WAS客户机

3.7Cookies

这里显示的是用户名以及对应的cookies。

这里不需要设置。

4运行测试脚本

所有的设置完成以后，就可以运行WAS来进行压力测试了。

要运行测试脚本很简单，只要选中测试脚本的名称，然后点击工具栏上的“运行”按钮，即可。

建议第一次运行测试脚本时，TestRunTime不要太长，StressLevel以及Stress

multiplier不要太大，因为，第一次运行的目的只是为了检验测试脚本正确的运行。

图12运行测试脚本

5测试结果

每次测试运行结束后，WAS会生成详细的报表，即使测试被提前停止也一样。

WAS报

表可以从View菜单选择Reports查看。

下面介绍报表中几个重要的部分。

5.1摘要

页面摘要部分提供了页面的名字，接收到第一个字节的平均时间（TTFB），接收到最后

一个字节的平均时间（TTLB），以及测试脚本中各个页面的命中次数。

TTFB和TTLB这两

个值对于计算客户端所看到的服务器性能具有重要意义。

TTFB反映了从发出页面请求到接收到应答数据第一个字节的时间总和（以毫秒计），TTLB包含了TTFB，它是客户机接收到页面最后一个字节所需要的累计时间。

只要选中页面的名字，即可显示页面摘要。

图13页面摘要

5.2ResultCodes（结果代码）

如果是一个新创建的测试脚本，应该检查一下报表的ResultCodes部分。

这部分内容包含了请求结果代码、说明以及服务器返回的结果代码的数量。

如果这里出现了404代码（页面没有找到），说明在脚本中有错误的页面请求。

具体的错误代码表示的意义，可以参考IIS的说明文档。

图14测试结果代码

5.3PerfCounters（性能统计）

报表中还包含了所有性能计数器的信息。

这些数据显示了运行时各个项目的测量值，同

时还提供了最大值、最小值、平均值等。

报表实际提供的信息远远超过了这里介绍的内容。

5.4ScriptSettings（脚本设置）

这里显示的是运行本次测试时的设置，也就是前面讲到的Setting部分的内容。

图15运行本次测试时的设置

5.5TestClients（测试客户机）

这里显示的是各个WAS客户机的情况。

先总体说明在测试中使用了那些WAS客户机，

在使用的WAS客户机中显示。

●执行了多少线程。

●模拟了多少用户。

●点击的次数。

●连接失败的次数。

图16测试客户机

5.6PageSummary（页面概要）

显示了在测试中各个请求内容的TTFB和TTLB，以及点击的次数等信息。

具体的说明

已经包含在上面的摘要中了。

5.7PageGroups（页面组）

显示不同的用户组在测试中的执行情况。

这里提供的信息包括

●用户组的分布情况，以及在所有用户组中所占的比例。

●点击的次数，以及在所有点击次数中所占的比例。

●ResultCodes情况。

●Socket连接的信息。

图17用户组在测试中的执行情况

5.8PageData（页面数据）

显示了各个请求内容的更加详细的信息。

一般技术需求中的运行效率信息可以在这里验证。

6其他方式编写测试脚本

前边提到，编写测试脚本有4种方法，现在对其他三种方法进行简单的介绍。

6.1手动编写测试脚本

打开菜单，选择Scripts|Create|Manual手动创建一个测试脚本,然后出现了NewScript，[server]中输入要进行测试的服务器IP地址或计算机名称；在脚本的内容表格中[verb]项选择脚本运行方式get、post、head；[path]中输入向服务器提交的文件或字符串。

图18手动创建测试脚本

图19手动创建测试脚本参数设置

6.2导入IIS日志

这种方法适合于开始投入运行的Web应用程序。

IIS日志记录了用户访问系统的所有信

息。

通过导入IIS日志的方法建立的测试脚本，是最符合实际运行情况的方法。

如果有IIS

日志，推荐使用这种方法。

图20导入IIS日志的方法建立测试脚本

这种方法也比较简单。

打开菜单，选择Scripts|Create|Log导入IISs日志创建一个测试

脚本。

然后出现导入IIS日志的第一步，选择IIS日志的路径，默认情况下的路径如图所示。

图21选择IIS日志的路径

（1）

Next进入第二步，一般情况下不用做改动，取默认即可。

图22选择IIS日志的路径

（2）

点击Finish后，WAS自动生成脚本。

6.3导入网站内容文件

这种方法通过导入网站上具体的文件来生成测试脚本。

一般情况下，不推荐使用这种方

法。

下面简单说明这种方法的使用。

打开菜单，选择Scripts|Create|Contents，WAS自动新建一个测试脚本，并且切换到ContentsTree节点。

图23导入网站内容文件

然后回到NewScript的主页面，会看到选择的内容文件自动添加到表格中。

图24选择的内容文件自动添加到表格中

7设计测试方案时的一些注意点

7.1大规模测试时需要大量WAS客户端

为了充分利用资源，可以在项目组每个人的机器上都安装WAS软件（只要正确安装，启动WebTool服务即可）。

这样在测试时，WAS会自动协调，自动分配线程。

7.2系统中有很多的角色

虽然WAS可以将不同角色执行请求的顺序进行混合，但是不知道WAS是如何混合的，因此不能随时控制角色的状态。

建议将不同的角色分组，每个角色放到一个WAS测试机（充当控制器）上，这样可以分角色而又集中的对WebServer进行压力测试，同时又能随意的控制各个WAS客户机的状态。

这种思想是模仿LoadRunner软件，具体实施还需要不断的学习和实验。

7．3测试的顺序

在集成测试时，先注重性能方面的测试，逐步的加压，寻找WebServer的最大负载量。

进而对照技术需求，不断改进。

WAS首先是性能测试工具，然后才是压力测试工具。

具体测试时，可以先在正常的条件下（满足技术需求）进行性能测试，然后才是异常情况（增加压力到技术需求规定的1.5-2倍）的测试。

7．4利用WAS更深入地了解应用

不断的研究学习，利用WAS更深入地了解应用的性能、稳定性、瓶颈和局限性。

8使用WAS的优势和不足

8.1使用WAS的优势

首先，讨论使用WAS测试应用程序的好处。

1．简单

WAS允许以不同的方式创建测试脚本：

你可以通过使用浏览器走一遍站点来录制脚本，可以从服务器的日志文件导入URL，或者从一个网络内容文件夹选择一个文件。

当然，也可以手工地输入URL来创建一个新的测试脚本。

不像其它的工具，你可以使用任何数量的客户端运行测试脚本，全部都有一个中央主客户端来控制。

在每一个测试开始前，主客户机透明地执行以下任务：

●与其他所有的客户机通讯。

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

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

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

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

2．高可用性

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

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

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

●允许为每个用户存储cookies和ActiveServerPages（ASP）的session信息。

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

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

●支持SecureSocketsLayer（SSL）协议。

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

提供一个对象模型，可以通过MicrosoftVisualBasic®ScriptingEdition（VBScript）处理或

者通过定制编程来达到开启，结束和配置测试脚本的效果。

8．2使用WAS的缺陷和不足

除了优势外，WAS的确也有一些缺陷和不足，当前知道的bug和有关事项都以列在WAS的网站上了。

以下是当前WAS不支持的特性：

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

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

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

●对拥有不同IP地址或