Web测试

Web测试

　　随着Internet的日益普及，现在基于B/S结构的大型应用越来越多，可如何对这些应用进行测试成为日益迫切的问题。有许多测试人员来信问我B/S的测试如何做，由于工作较繁忙，对大家提出的问题也是头痛医头脚痛医脚，没有对WEB的测试过程做一个整体的概述。希望通过本篇能够让大家了解大型Web应用是如何来进行测试的。

B/S下的功能测试比较简单，关键是如何做好性能测试。目前大多数的测试人员认为只要跑一些测试工具证明我的产品是可以达到性能的就ok了，为了证明而去测试是没有任何价值的，关键是要发现产品性能上的缺陷，定位问题，解决问题，这才是测试要做的。

首先我们从两个方面分析如何进行WEB测试，从技术实现上来讲一般的B/S结构，无论是.NET还是J2EE,都是多层构架，有界面层，业务逻辑层，数据层。而从测试的流程上来说，首先是发现问题，分析问题，定位问题，再由开发人员解决问题。那么B/S的结构的测试如何来做？

如何发现问题是我首先要介绍的，在做WEB测试之前你需要一些资料，比如产品功能说明书，性能需求说明书，不一定很完善，但一定要有，明确测试目标，这是基本的常识，可是我往往看到的是已经开始动手测了，但还不知自己的系统要达到的性能指标是什么。这里我简单讲一下测试的性能指标：

1、通用指标（指Web应用服务器、数据库服务器必需测试项）:
* ProcessorTime: 指服务器CPU占用率，一般 平均达到70%时，服务就接近饱和；
* Memory Available Mbyte : 可用内存数，如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重；
* Physicsdisk Time : 物理磁盘读写时间情况；

2、Web服务器指标：
* Avg Rps: 平均每秒钟响应次数＝总请求时间 / 秒数；
* Avg time to last byte per terstion （mstes）:平均每秒业务角本的迭代次数 ,有人会把这两者混淆；
* Successful Rounds：成功的请求；
* Failed Rounds ：失败的请求；
* Successful Hits ：成功的点击次数；
* Failed Hits ：失败的点击次数；
* Hits Per Second ：每秒点击次数；
* Successful Hits Per Second ：每秒成功的点击次数；
* Failed Hits Per Second ：每秒失败的点击次数；
* Attempted Connections ：尝试链接数；

3、数据库服务器指标：
* User 0 Connections ：用户连接数，也就是数据库的连接数量；
* Number of deadlocks：数据库死锁；
* Butter Cache hit ：数据库Cache的命中情况；

上面的指标只是一些通用的指标，起到抛砖引玉的作用，对于不同的应用你还必需作相应的调整，比如程序使用的是.NET技术的，则必需加入一些针对性的测试指标。对于这些指标的详细了解，你可以参考Windows 下面的 SystemMonitor的帮助与LoadRunner、ACT的帮助。对于发现问题，指标的设置非常重要，它会帮你定性的发现一些错误。对于定性的压力测试我就不做过多的分析，工具很多，流行的主要有LoadRunner、ACT、WAS、WebLoad 各个工具有它的使用范围；其中我各个认为：

LoadRunner 最全面，它提供了多种协议的支持，对复杂的压力测试都可以胜任；
WAS与ACT则对微软的技术支持的比较好，其中WAS支持分布式机群测试；
ACT则是与.NET集成比较好，支持ViewState （.NET 下控件缓存的支持）的测试。

在这一阶段测试你要不断的跟据系数的测试目标进行变化，一开始由于系统过于庞大，所以我们要分成若干个子系统，各个子系统的性能目标必需明确，主要是并发指标定一个阈值，同时设定一些与系统相关的测试参数，应用服务器，数据库服务器都要有，对达不到阈值的与一些通用参数有问题的子系统进行深入分析。比如它的并发达不到你的要求，证明子系统性能有问题，或是数据库用户连接过高，程序没有释放用户连接等等。这个我们要对子系统进行详细测试，由于B/S 结构下,图片的请求对性能的影响较大，所以我们对子系统测试时要分两个部分进行：
一、非程序部分，即图片等等；
二、应用程序本身。
通过事务或函数的分离，可以把这两块实现单独的测试，具体做法参考各个工具的手册，我这里就不做说明。对子系统的测试参数的设置要求则更高，它有助你后面精确的定位问题，比如对异常、死锁、网络流量等等前面没有注意到的情况的增加；同时你要注意增加测试参数的收集对系统的性能影响比较大，所以一般不要超过10个。刚刚介绍的整体的性能测试指标也不要增加很多，这样影响会小一点。最后在这一阶段要说明的是数据库的数据量会很大程度的影响性能，所以要根据前面的性能需求说明书向数据库中模拟相应的数据量，来进行测试，这样才有更高的可信度。

上面所说的是对问题的发现，下面就是分析问题原因，这一步的要求比较高，一般由测试人员与程序员配合完成，当然如果你有相当的开发经验，再做这方面的测试，就更为难得。下面我们说说如何精确定位问题，出现问题的可能性可能有很多种，大致分以下几种：
一、性能达不到目标；
二、性能达到目标，但有一些其它的问题，比如异常、死锁。缓存命中过低，网络流量较大；
三、服务器稳定性的问题，比如内存泄漏……。

　　要发现这些问题起马的要求要有一款使用的比较称心的性能分析与优化工具，比如微软的.NET下就有自己开发的工具，对Borland的Java开发工具中也有类似的工具，但我个人认为更好的工具是Rose下的Purify与Quantify，主要是他对.net 与java 、C++都有支持，而且分析效果特别专业。我们先了解一下 Rational Purify。

Rational Purify 能自动找出Visual C/C++ 和Java 代码中与内存有关的错误，确保整个应用程序的质量和可靠性。在查找典型的Visual C/C++ 程序中的传统内存访问错误，以及Java，C# 代码中与垃圾内存收集相关的错误方面；Rational Quantity 则是一款针对函数级的性能分析利器，使用它你可以从图形化的界面中得到函数调用的时间，百分比与次数，以及子函数所占时间，使你可以更快的定位性能瓶颈。

我们先说性能优化与异常的处理，性能优化有一个原则 —— 即用时间比例最大的进行优化，效果才最明显。比如有个函数它的执行时间为30秒，如果你优化了一百倍则执行时间为0.3秒，提升了29.7秒；而如果它的执行时间为0.3秒，优化后为0.003秒，实际提升了0.297秒，提升的效果并不明显而且写过程序的人都知道，后者性能优化的代价更大。

　　在性能优化的过程中，一般是先数据库，后程序。因为数据库的优化不需要修改程序，修改的风险很小。但如何才能确定是数据库的问题，这就需要技巧，在使用Quantity时，你一路分析下去，大多数最终会发现，是数据库查询函数占用时间比较大，比如什么，SqlCmd.ExecuteNoQuery等等数据库执行函数，这时你就需要分析数据库，呵呵。

数据库的分析原则是先索引，后存储过程，最后表结构视图的优化。索引的优化是最简单也是通常最有效的方法，如果合理的使用会带来意想不到不到的效果。在这里我要给大家简单的介绍一下我的最爱：SQLProfile、SQL查询分析器。
Precise SQLProfile是一个SQL语句跟踪器，可以跟踪程序流程使用的SQL语句与存储过程，结合查询分析器对SQL的分析，可以对索引的优化做出很好的判断，但索引也不是万能的，在增删改较多的表，索引过多会引起这些操作的性能下降，所以判断还是需要一定的经验。同时针对用户使用频度最高的SQL进行优化也是最行之有效的，这时我则需要Precise，它可以观测某一个较长时间内的SQL语句的执行情况。

数据库优化的潜能挖光后，如果还是达不到性能要求或是还有问题，则要从程序来进行优化，这是程序员做的事。测试人员要做的，就是告诉他们，哪个函数执行过多引起了性能下降，比如异常过多，某个循环过多，或是DCOM调用过多等等，但说服程序员也是一件不容易的事，你要在这一阶段做的出色一定要有几年的编程经验，并且要让程序员感到听你的性能会有提升，这是一件很不容易的事情哦。

内存的分析，一般是一个长期分析的过程，要做好不容易，首先要有长期奋战的准备，其次内存泄漏的分析最好是放在单元测试之中同步进行，而不是要等到最后再去发现问题，当然出了问题也只好面对，一般这类问题都是在服务器运行了很久才暴露出来，一旦发现问题后，则需要定位问题，分析的原则采用子系统相互独立运行，找到最小问题的系统集,或是借助内存分析工具观察内存对象情况，初步定位问题，再用Purify进行运行时分析，通常C++ 内存问题比较多，Java与.NET比较少，一般由GC不合理引起。C++的内存错误就比较多了，主要常见的有:
1、 Array Bounds Read (ABR) ：数组越界读
2、 Array Bounds Write (ABW)：数组越界写
3、 Beyond stack Read (BSR)：堆栈越界读
4、 Free Memory Read(FMR)：空闲内存读
5、 Invalid pointer Read(IPR)：非法指针阅读
6、 Null Pointer Read(NPR)： 空指针阅读
7、 Uninitialized Memory Read(UMR)：未初始化内存读写　　
8、 Memory Leak：内存泄漏
注：如果需要更多的信息，可以参见Purify的帮助信息。
顺便提一句，为什么我要说做单元测试时做内存分析比较好，由于单元测试针对的是单一功能，这时结合单元测试案例做内存分析会更快的定位问题，同时由于问题较早的发现，则后期的风险则会减少，当然如果结合代码覆盖工具PureCoverage 来做就更完美了。
注：本篇只是对B/S应用的测试过程作一个整体的描述，对某一个阶段使用的工具只是作大概的介绍，你也可使用你比较熟悉的工具达到相同的目标。

性能管理

说到Windows环境下的性能管理，许多人首先想到的可能就是无处不在的Performance Monitor工具。早在Windows NT时代，Performance Monitor就是获取性能信息的主要工具，当然，任务管理器和Windows管理规范（Windows Management Instrumentation）也属于常用工具之列，它们不仅能够提供性能数据，而且还能提供其他与性能有关的管理信息。本文介绍了一些充分发挥这些经典工具潜能的技巧，同时介绍了Windows XP新增的工具，探讨如何运用它们来评估系统的性能情况。

一、什么是性能管理？

　　对于许多管理员来说，Windows的性能管理不外乎打开控制面板→管理工具中的“性能”程序，即Performance Monitor程序，然后检查一下CPU利用率、磁盘忙闲状况、内存压力，而且通常只有在出现性能问题时才会去检查，例如服务器响应突然变慢，或者用户不能访问服务器。这种性能管理方式完全属于事后补救的方式，只起到了救火队员的作用，由于缺乏详尽、明确的事前评估、规划，算不上优秀的策略。要实现有效的性能管理，一定要在出现问题之前掌握系统的性能情况。

　　只有事先采取有效的性能管理策略，才能全面掌握系统的性能特征，在此基础上，就可以估计何时可能出现性能问题以及问题的具体表现。预先收集的性能数据还可以用来规划未来的运算能力需求，例如，假设有一个IIS Web服务器，当并发用户数量是200时CPU的利用率是60%，据此可以推断系统负载何时达到极限，以及达到负载极限时能够支持的并发用户数量。另外，根据网站的增长情况，还可以估计出何时需要增添硬件设备。

　　系统的整体性能由许多因素决定，例如CPU利用率，CPU队列长度（即，有多少任务正在等待CPU的服务），磁盘忙闲程度（即，磁盘驱动器有多少时间用于响应请求），可用的物理内存，网络接口的利用情况，等等，表一概括了最常用的性能计数器。

 

 

表一：重要的性能计数器
性能对象	计数器	提供的信息
Memory	Available Bytes	Available Bytes显示出当前空闲的物理内存总量。当这个数值变小时，Windows开始频繁地调用磁盘页面文件。如果这个数值很小，例如小于5 MB，系统会将大部分时间消耗在操作页面文件上。
Memory	% Committed Bytes in Use	% Committed Bytes In Use 是 Memory: Committed Bytes 与Memory: Commit Limit之间的比值。(Committed memory指如果需要写入磁盘时已在分页文件中保留空间的处于使用中的物理内存。Commit Limit是由分页文件的大小而决定的。如果扩大了分页文件，该比例就会减小)。这个计数器只显示当前百分比；而不是一个平均值。
Memory	Page Faults/sec	Page Faults/sec是指处理器处理错误页的综合速率。用错误页数/秒来计算。当处理器请求一个不在其工作集(在物理内存中的空间)内的代码或数据时出现的页错误。这个计数器包括硬错误(那些需要磁盘访问的)和软错误(在物理内存的其它地方找到的错误页)。许多处理器可以在有大量软错误的情况下继续操作。但是，硬错误可以导致明显的拖延。这个计数器显示用上两个实例中观察到的值之间的差除以实例间隔的持续时间所得的值。
Network Interface	Bytes Total/sec	Bytes Total/sec是发送和接收字节的速率，包括帧字符在内。
Network Interface	Packets/sec	Packets/sec为发送和接收数据包的速率。
Physical Disk	% Busy Time	% Busy Time指磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。
Physical Disk	Avg. Disk Queue Length	Avg. Disk Queue Length 指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。
Physical Disk	Current Disk Queue Length	Current Disk Queue Length指在收集操作数据时在磁盘上未完成的请求的数目。它包括在快照内存时正在为其提供服务中的请求。这是一个即时长度而非一定间隔时间的平均值。多主轴磁盘设备可以一次有多个请求操作，但是其它同时发生的请求为等候服务。这个计数器可能会反映一个暂时的高或低的列队长度，但是如果在磁盘驱动器存在持续负载，可能值会总是很高。请求等待时间与这个列队的长度减去磁盘上的主轴成正比。这个差值应小于2才能保持良好的性能。
Processor	% Processor Time	% Processor Time指处理器执行非闲置线程时间的百分比。这个计数器设计成用来作为处理器活动的主要指示器。它通过在每个范例间隔中衡量处理器用于执行闲置处理线程的时间，并且用100%减去该值得出。(每个处理器有一个闲置线程，该线程在没有其它线程可以运行时消耗周期)。可将其视为范例间隔用于做有用工作的百分比。
Processor	% User Time	% User Time指用于用户模式的非闲置处理器时间的百分比(用户模式是为应用程序、环境分系统和整数分系统设计的有限处理模式。另一个模式为特权模式，它是为操作系统组件设计的并且允许直接访问硬件和所有内存。操作系统将应用程序线程转换成特权模式以访问操作系统服务)。这个计数值将平均忙时作为实例时间的一部分显示。
Server Work Queues	Queue Length	Queue Length指CPU当前的服务器作业队列长度。队列长度长时间超过四可能表示处理器堵塞。此值为即时计数，不是一段时间的平均值。
System	Processor Queue Length	Processor Queue Length是指处理队列中的线程数。即使在有多个处理器的计算机上处理器时间也会有一个单队列。不象磁盘计数器，这个计数器仅计数就绪的线程，而不计数运行中的线程。如果处理器队列中总是有两个以上的线程通常表示处理器堵塞。这个计数器仅显示上一次观察的值；而不是一个平均值。
TCP	Segments Retransmitted/sec	Segments Retransmitted/sec指程序段重新传输的速率，即传输的程序段中包含一个或多个以前传输过的字节。

Pages Input/sec 是为了解决硬错误页，从硬盘上读取的页数，而Page Reads/sec 是为了解决硬错误，从硬盘读取的次数。如果 Page Reads/Sec 比率持续保持为 5，表示可能内存不足。

   Page Faults/sec 是指处理器中“页面错误”的数量。当一个进程引用不在主存储器“集”中的虚拟内存页时，就会发生页面错误。如果该页面在 Standby 列表上，因而已在主存储器中，或者如果另一个与其共享该页面的进程正在使用该页，那么发生“页面错误”时，不会从磁盘读取该页面。

   Pages Input/sec 是指内存引用时页面不在内存，为解决这种情况而从磁盘读取的页面数量。此计数器包含页面流量，它代表为应用程序访问文件数据分配的系统缓存。如果您担心过 量的内存压力（即，系统颠簸）以及可能造成的过量调页，那么这是个需要查看的重要计数器。

   Pages Output/sec 是指因主存储器中的页面已修改而写入磁盘的页面数量。

   Pages/sec 是指引用不在内存中的页面时，为解决这一问题，从磁盘读取或写入到磁盘的页面数量。它是 Pages Input/sec 与 Pages Output/sec 之和。此计数器包含页面流量，它代表为应用程序访问文件数据分配的系统缓存。该值还包括取自或保存到非高速缓存的映射内存文件的那些页面。如果您担心过量 的内存压力（即，系统颠簸），以及可能造成的过量调页，那么，这是个需要查看的主要计数器。在 WTS 中 观察到的结果表明，内存瓶颈对系统性能的影响比 CPU 瓶颈的影响严重得多。出现 CPU 瓶颈时，仍会处理所有的客户请求，但处理速度变慢。受 CPU 限制的机器上的所有客户均可以继续操作，只是在处理过程中，会有持续几秒的定期暂停。   在受内存限制的 WTS 中，测试已表明，只要可用的物理系统 RAM 已达到某个水平，系统就会开始从转换文件读取页面和写入页面。在物理系统 RAM 的数量达到临界水平后，WTS 就会充斥大量转换文件的调页信息。由于影响很大，所以应密切观察内存的使用情况。

   最重要的两个性能计数器是 Available Bytes 和 Page Inputs/sec。如果观察到 Page Outputs/Sec 和 Page Inputs/Sec 有上升的趋势，则系统中可能存在内存瓶颈。当处理器向内存指定的位置请求一页（可能是数据或代码）出现错误时，这就构成一个Page Fault。如果该页在内存的位 置，该错误被称为软错误（用Transition Fault/sec 计数器衡量）；如果该页必须从硬盘上重新读取时，被称为硬错误。许多处理器可以在有大量软错误的情况下继续操作。但是，硬错误可以导致明显的拖延。 Page Faults/sec 是处理器每秒钟处理的错误页（包括软错误和硬错误）。

二、定制性能监视器

　　在Windows 2K/XP中，Performance Monitor仍是最常用的性能管理工具。当然，新版的工具不少地方已经改进，增添了不少功能。在Win 2K中，性能监视器以一个管理控制台（MMC）单元的形式实现。启动Win 2K/XP的性能监视器，可以看到类似图一的界面。

 

图一

　　在Win XP中，性能监视器默认装入三个计数器：Pages/sec，Avg. Disk Queue Length，% Processor Time。这三个计数器无法直接删除，但一直留着又降低了监视器启动速度。如果要让监视器启动时不装入任何计数器。（让监视器启动时不装入任何计数器）首先要清除\%systemroot%\system32目录下perfmon.msc文件的只读属性：进入命令窗口，转到system32目录，执行命令attrib r perfmon.msc。然后重新启动计数器，选中一个计数器，点击工具栏上黑色的“X”按钮即可删除一个计数器。选择菜单“文件”→“保存”，将更改后的管理控制台保存到磁盘。如果要将管理控制台执行标记成只读，只需在命令行上执行attrib +r perfmon.msc即可。

　　在NT 4.0中，性能监视器包含一个实时图表，另外还有记录日志和报警功能，但在Win 2K和XP的中，这些功能分开了。在Win 2K/XP中，实时性能图表变成了“系统监视器”，系统监视器之下是日志和警报工具。系统监视器可以看作一个纯粹的实时性能数据察看工具，只能看，不能保存，点击工具栏上的“+”按钮可以添加新的性能计数器。性能日志和警报工具则具有操作历史数据的功能。

　　如果要创建一个只有系统监视器、不带性能日志和警报工具的管理控制台，可按如下步骤操作：执行“MMC”命令，打开一个空白的MMC窗口，选择菜单“文件”→“添加/删除管理单元”，点击“添加”，选择“ActiveX控件”，再点击“添加”，在向导中选择System Monitor Control，确认即可。

 

三、性能日志和警报工具

　　系统监视器只能简单地查看实时性能数据，如果需要长期的、持久化的性能数据，必须使用性能日志和警报工具。性能日志工具能够在一个日志文件中集中记录来自本地或远程的多个系统的性能数据，这些日志数据可以用系统监视器查看或用其他工具处理。扩展控制台中的“性能日志和警报”节点，可以看到它的三个分支：计数器日志，跟踪日志，警报。警报工具的功能很简单，就是当某个计数器的性能数据达到指定的值时，执行一定的动作，例如发送Email或用Net Send命令发送消息。下面我们主要讨论的是日志工具。

　　为了说明如何使用计数器日志，我们要新建一个日志会话。右击“计数器日志”节点，选择“新建日志设置”，指定日志设置的名称，点击“确定”，出现图二的对话框，在这里设定要在日志中记录的计数器。

 

图二

　　日志文件的默认保存路径是C:\perflogs目录，可以在对话框的“日志文件”页修改，但首先要设置待记录的对象和计数器才能转到“日志文件”页。点击“添加对象”按钮，将某个监视对象的所有计数器加入日志记录，或者点击“添加计数器”按钮加入单个计数器。无论选择哪种加入选项，监视目标（对象或计数器）都可以是本地的，也可以是远程机器的。

　　如果要长期收集性能数据，最好调整一下采样间隔时间——特别地，如果要监视的计数器很多，而且来自不同的机器，如果采样间隔时间设置得太小，日志文件很快会变得很大。从每隔15分钟采样一次开始，试运行一段时间，看看日志文件变得多大了，然后再作相应的调整。

　　如果要连接远程机器，可以在“运行方式”输入框提供登录远程机器的用户名字。

　　收集性能监视数据需要一定的权限，HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib注册子键控制着对性能监视数据的访问，性能监视数据正是通过该注册子键流到系统监视器之类的工具。用右键点击该注册子键，选择菜单“权限”，如图三，调整这里的权限分配也就调整了有权访问性能数据的用户。

 

图三

 

设置好要监视的对象和计数器之后，可以在“日志文件”页调整日志文件的格式，在“计划”页设置启动、停止日志的时间。如果设置成手工启动，启动方式是在MMC窗口中右击日志会话并选择“启动”。

　　在“日志文件”页中，如图四，性能计数器日志除了默认的二进制.blg格式之外，还可以保存为其他多种格式，例如逗号分隔的文本文件（即CSV文件），甚至还可以保存到SQL Server表——这是Windows Server 2003和XP才有的功能。如果选择了SQL Server，还要指定一个SQL Server数据源和保存数据的表，虽然麻烦一点，不过如果要收集大量的性能数据并进行分析，SQL Server还是一种不错的选择。

 

图四

　　启动日志之后，可以看到日志目录中生成了一个65 KB的日志文件。每次关闭和重新启动日志，都会生成一个新的日志文件，文件名字中的序号依次增加。Win XP和2K支持一项非常实用的功能，即使在性能监视器工具不运行的时候，也能继续将性能数据写入日志。如果是NT 4.0，则需要安装NT 4.0 Resource Kit的DataLog服务才能使用这个无人值守日志记录功能。Win 2K和XP本身就有Performance Logs and Alerts服务，该服务在日志会话启动时自动启动，日志会话结束时自动停止。

　　Win 2K/XP性能日志的另一个改进之处是保存日志会话功能。在NT 4.0中，如果要为某个日志会话重新使用一组选定的性能对象和计数器，必须为每一台想要监视的服务器重新创建工作台文件，如果要将一组日志配置分别在多台服务器上本地运行，必须重复执行繁琐的配置操作。但在Win 2K/XP中，所有配置文件（包括日志和警报）都以HTML文件的形式保存，很容易修改和重用。要保存一个日志会话配置，只要在MMC窗口中右击会话，然后选择菜单“将设置另存为”即可。

　　四、命令行工具

　　XP提供了一个叫做Logman的新工具，它不仅能够在命令行上启动和停止日志会话，而且能够从命令行创建新的日志会话。

　　例如，下面的第一Logman命令新建了一个iislogging会话，日志文件保存在默认c:\perflogs\IISLogging.blg，日志中加入了本地服务器上inetinfo.exe进程的Process\% Processor Time计数器，收集性能数据的时间间隔是15分钟。第二个命令启动了iislogging日志会话。运行这些命令之后，如果启动MMC性能监视工具，可以看到计数器日志中已经列出了刚才创建的日志会话。

logman create counter iislogging -c "\Process(inetinfo)\% Processor Time" -si 15:00logman start iislogging

用Logman的-s选项可以启动远程机器上的日志，使用形式类如“-s \\ServerName”。使用该选项时，Logman启动的日志将在远程服务器上运行，而不是执行Logman命令的本地机器。

　　五、WMIC

　　WMIC即Windows管理规范的命令行工具，在命令上执行执行wmic，即可启动WMIC环境。第一次执行wmic命令时，WMIC首先把自己安装到WMI名称空间。虽然微软推出WMIC的意图是简化WMI的使用，不过WMIC的命令行语法还是显得比较复杂。WMIC依靠别名来描述经常要访问的WMI类，例如，WMIC的别名pagefile相当于WMI查询Select * from Win32_PageFileUsage，如果在wmic提示符下输入pagefile命令，WMIC将显示出当前的页面文件使用情况。

　　遗憾的是，WMIC没有为基于WMI的性能监视数据提供别名，所以要查询性能监视器数据，必须直接调用相应的WMI类。例如，如果要查看服务器当前的物理内存使用情况，可以在WMIC命令行上执行path win32_perfformatteddata_perfos_memory，该命令要求WMIC返回WMI类win32_perfformatteddata_perfos_memory的数据，输出结果包含了指定WMI内存对象的每一个属性。如果只想查看Available Bytes属性，可以将命令改为path win32_perfformatteddata_perfos_memory get AvailableBytes。

　　另外，WMIC命令还可以从Windows命令行直接执行，例如，要查看Available Bytes，可以执行wmic path win32_perfformatteddata_perfos_memory get AvailableBytes命令，如果要返回多个属性值，只要依次列出各个属性，属性之间用逗号分隔，例如“AvailableBytes,AvailableMBytes,CacheBytes”。

　　那么，如何获得各种性能监视器计数器的WMI类名称呢？最好的办法是使用WMI Tools。WMI Tools是微软提供的一个免费工具，可以从http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=6430F853-1120-48DB-8CC5-F2ABDC3ED314下载，如图五所示，它能够清楚地显示出各个类的名称、属性、方法。

 

图五

　　在多层应用环境中，如果要查找性能瓶颈的具体位置，性能监视数据无疑是极其宝贵的依据，只要充分运用Win 2K/XP提供的性能工具，我们可以构造出功能丰富的性能管理系统。

使用Microsoft Web Application Stress Tool对web进行压力测试

Web压力测试是目前比较流行的话题，利用Web压力测试可以有效地测试一些Web服务器的运行状态和响应时间等等，对于Web服务器的承受力测试是个非常好的手法。Web 压力测试通常是利用一些工具，例如微软的Web Application Stress、Linux下的siege、功能全面的Web-CT等等，这些都是非常优秀的Web压力测试工具。

虽然这些工具给我们测试服务器承受能力带来方便，但是它们的危害却更是惊人，甚至于利用随便一种比较全面的测试工具就可以对一台小型的 Web服务器发动灾难性的拒绝式攻击。下面我就带大家利用微软的Web Application Stress进行一次Web压力测试，其目的是为了让大家看到它的巨大危害。

一、工具简单介绍

Microsoft Web Application Stress Tool 是由微软的网站测试人员所开发，专门用来进行实际网站压力测试的一套工具。透过这套功能强大的压力测试工具，您可以使用少量的客户端计算机仿真大量用户上线对网站服务所可能造成的影响，在网站实际上线之前先对您所设计的网站进行如同真实环境下的测试，以找出系统潜在的问题，对系统进行进一步的调整、设置工作。就是因为这些特性，才使它具备了D.O.S轰炸的功能。

小提示：D.O.S（拒绝服务攻击）通过使你的服务计算机崩溃或把它压跨来阻止你提供服务。简单来说，就是让你的计算机提供可能多的服务从而使你的计算机陷入崩溃的边缘或崩溃。

二、工具简单设置

打开Web Application Stress Tool，很简洁的一个页面（如图1），上面是工具栏，左下方是功能选项，右下方是详细设置选项。在对目标Web服务器进行压力测试之前，先对它进行一些必要的设置。

图1

1. 在“settings”的功能设置中（如图2），一个是Stress level (threads)这里是指定程序在后台用多少线程进行请求，也就是相当于模拟多少个客户机的连接，更加形象的就是说设置多少轰炸的线程数。一般填写 500～1000，因为这个线程数是根据本机的承受力来设置的，如果你对自己的机器配置有足够信心的话，那么设置的越高，轰炸的效果越好。

图2

2.在“Test Run Time”中来指定一次压力测试需要持续的时间，分为天、小时、分、秒几个单位级别，你根据实际情况来设置吧！

3.其余的选项不太重要，这里就不再浪费笔墨，朋友们可以自己尝试一下设置。

三、压力测试

工具介绍完了，下面来准备条件：这里与一个朋友商量好进行测试，他是单机上网，机器配置是CPU:Athlon XP2500+、内存512MB、硬盘80GB等，机器配置还不错。他在机器上安装了IIS，架设了一台对外的Web服务器，Web服务中的程序是动网 7.0。我就利用压力测试工具对这台服务器进行测试。

步骤1：在工具中点右键，选择Add命令，增加了一个新的测试项目：New script，对它进行设置，在主选项中的server中填写要测试的服务器的IP地址。在下方选择测试的Web连接方式，这里的方式Verb选择 get，path选择要测试的Web页面路径，这里填写/Index.asp,即动网的首页文件（如图3）。

图3

步骤2：在“Settings”的功能设置中将Stress level (threads)线程数设置为1000。完毕后，点工具中的灰色三角按钮即可进行测试（如图4）。测试完毕，等待朋友把任务管理器以及连接查看的截图发过来！

图4

攻击开始后，朋友从任务管理器中可以看到CPU使用率已经达到100%，损耗率达到最大（如图5）。在CMD窗口中使用命令netstat -an,可以看到我的IP地址在朋友服务器上的80端口进行了非常多的连接（如图6）。而且它的Web网站已经打不开了，提示过多用户连接，达到了跟 D.O.S攻击一样的目的。

图5

图6

试想，如果利用多台肉鸡对一台服务器进行Web压力测试，那么对这台服务器来说将是灭顶之灾，所以朋友们在使用它之前一定要慎重考虑。