为了有效的对Web应用程序进行压力测试，Microsoft发布了这个简单易用，功能强大的工具WAS。WAS要求Windows NT
4.0 SP4或者更高，或者Windows
2000。为了对网站进行负载测试，WAS可以通过一台或者多台客户机模拟大量用户的活动。WAS支持身份验证、加密和Cookies，也能够模拟各种浏览器类型和Modem速度，它的功能和性能可以与数万美元的产品相媲美。
使用WAS时，为了更加接近真实的进行压力测试，我们推荐运行WAS的测试机和Web Server分开。
要对网站进行负载测试首先必须创建WAS脚本模拟用户活动。我们可以用下面四种方法之一创建脚本：
l 通过记录浏览器的活动
l 通过导入IIS日志
l 通过把WAS指向Web网站的内容
l 手工制作
在这里我们拿最常用的方法——通过记录浏览器的活动 来讲解。其他三种方法在后面将会提到。
3.1 录制测试脚本
打开菜单，选择Scripts|Create|Record 创建一个测试脚本
选取要记录的内容，有下面3种
[attach]76400[/attach]
l Record delay between request：记录了请求之间的延迟。由于用户实际上在浏览网站时，请求之间存在几秒甚至几分钟的延迟，这种录制方法在执行时会模仿用户之间的延迟发送请求，所以会是一个更加实际的测试。如果我们的目的是要发现Web应用程序的承受极限，就不要选择该项；如果只是想模拟一个特定数量的用户场景，那么选择该项进行测试捕捉请求延迟。
l Record browser cookies & Record the host header：只记录用户的会话，不记录延迟时间。一般情况下，我们不需要选择这两项，可以让WAS创建cookies和host header，就好像用户登陆你的网站一样。然而，如果你有网站的回归信息时（比如一个用户的主要特征信息或者与一个永久性cookies相连的其他信息），在模拟一个新的用户登陆网站和进行必要的用户配置测试前，必须保证清除 cookies，如果Web应用程序需要用户接受cookies，那么需要选中该选项。
目前这个版本的WAS软件对基于浏览器IE录制脚本的方式还不支持HTTP/SSL请求。一般情况下，只选择后二种会增加压力的强度。
根据压力测试实际的情况，选择合适的选项，然后点“Next | Finish”，WAS会打开一个IE窗口，在IE中输入要测试的站点地址，然后我们就可以按照实际的情况开始浏览站点了，浏览的同时也就是执行测试用例的过程。
等测试用例执行完成后，切换到WAS窗口，点“Stop Recording:”按钮，停止录制脚本
[attach]76402[/attach]
WAS回到了视图页面，在该页面中你可以看到在录制过程中WAS收集的每一个链接，而且还可以编辑GET、POST以及HEAD信息。
[attach]76403[/attach]
制作WAS脚本是相当简单的，不过要制作出模拟真实用户活动的脚本有点儿复杂。如果你已经有一个运行的Web网站，可以使用Web服务器的日志来确定Web网站上的用户点击分布。如果你的应用还没有开始运行，那么只好根据经验作一些猜测了。
3.2 负载参数设置测试脚本录制完成后，下一步我们要作的就是配置运行脚本的负载选项，我们可以调整测试配置以便观察不同条件下的应用性能。
3.2.1 Content Tree
由于我们的WAS和Web Server是分开的，所以这里我们不需要设置
我们只要点击“Setting”就开始负载选项设置。
[attach]76404[/attach]
1. ConCurrent
Connections：
Stress Level（threads）的数值决定了所有客户机创建的Windows的线程的数值。每一个线程创建多个Socket连接（具体多少Socket连接数取决于Stress multiplier (sockets per thread)），每个Socket连接就是一个并发的请求(request)。下面这个公式表示了它们之间的关系：
总的并发请求数 = Stress Level * Stress multiplier = 总的Socket连接数
Stress Level和Stress
multiplier这二个项决定了访问服务器的并发连接的数量。Microsoft建议不要选择超过100的Stress
Level值。如果要模拟的并发连接数量超过100个，可以调整Stress
multiplier或使用多个客户机。在负载测试期间WAS将通过DCOM与其他客户机协调。
2. Test Run Time：设定持续运行多长时间的测试。我们可以在这里设定让WAS持续运行多少天、多少个小时、多少分钟、多少秒
3. Request Delay（in milliseconds）：设定请求延迟时间的最大、最小值，当然我们也可以选择“Use random delay”使用随机的延迟时间。一般情况下，我们常常会浏览一页，发现一个链接后，我们点击它。即便对该网站熟悉的人，
4. Suspend： WAS允许设置warmup（热身）时间，一般可以设置为1分钟。在warmup期间WAS开始执行脚本，但不收集统计数据。warmup时间给MTS、数据库以及磁盘缓冲等一个机会来做准备工作。如果在warmup时间内收集统计数据，这些操作的开销将影响性能测试结果。WAS也允许设置CoolDown时间。在WAS执行的时间达到设定的Test Run Time时，进入CoolDown Time，这时WAS并没有停止执行脚本，同样也不会收集统计数据。下图表示了它们的先后关系。
file:///e:/Temp/ksohtml/wps_clip_image-10240.pngWarmUp 不收集统计数据 | file:///e:/Temp/ksohtml/wps_clip_image-4198.pngTest Run Time 收集统计数据 | CoolDown 不收集统计数据 |
5. Bandwith：设置页面提供的另外一个有用的功能是限制带宽（throttle bandwidth）。带宽限制功能能够为测试模拟出Modem（14.k K，28.8
K，56 K）、ISDN（64 K，128 K）以及T1（1.54
M）的速度。使用带宽限制功能可以精确地预测出客户通过拨号网络或其他外部连接访问Web服务器所感受的性能。
6. Redirects、Throughput、Name resolution：
这几个选项一般情况下采用默认情况即可。
选中Follow HTTP redirects选项将会支持重定向。
选中Throughput中的两项，WAS将会收集活动用户的cookies，以及收集网站的统计数字。默认情况下都会选中这两项，如果不选择，将会增加压力测试的强度。
Name resolution默认情况下没有选中。选中该选项，会让每一个客户测试机执行查询，只有在使用多个子网时才需要选中该项。（帮助原文：have each individual test client perform a lookup，this is useful when using multiple subnets）
使用WAS，从远程Windows NT和Windows 2000机器获取和分析性能计数器（Performance
Counter）是很方便的。加入计数器要用到下图所示的Perf Counters分枝。
[attach]76405[/attach]
一般情况下，这里需要添加的性能计数器有：
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服务器性能测试来说却是一个好的开始。
· 处理器：CPU使用百分比（% CPU Utilization）
· 线程：每秒的上下文切换次数（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。
对于一个Web应用而言，同一时刻用户点击分布是不一样的。WAS允许设置用户点击流量的分布比例。
这里我们假设在一个Web应用程序中，有650个人同时在线，其中100人正在添加提交数据，占15.38%；有150人正在查询，占23.08%。
按照不同的Web应用，我们可以根据实际的情况在定制这个比例关系，来更加符合实际的情况。
3.2.5 Users
现在很多Web应用程序为了提供个性化的服务，都设计了登陆过程。每个用户都有自己的登陆名和密码。WAS也考虑到了这种情况，我们只要在Users分支中添加用户名和对应的密码即可。
[attach]76407[/attach]
添加多个WAS客户机。在运行期间，各个WAS客户机是通过DCOM来协调的。各个WAS客户机只要正确安装了WAS软件，启动了WebTool服务，它们就可以自己协调操作。
我们只要在Clients分支内添加WAS客户机即可。
[attach]76408[/attach]
这里显示的是用户名以及对应的cookies。这里不需要设置。
所有的设置完成以后，我们就可以运行WAS来进行压力测试了。要运行测试脚本很简单，只要选中测试脚本的名称，然后点工具栏上的“运行”按钮，即可。
建议：第一次运行测试脚本时，Test Run Time不要太长，Stress Level以及Stress multiplier不要太大。第一次运行的目的只是为了检验测试脚本正确的运行。
[attach]76409[/attach]
每次测试运行结束后WAS会生成详细的报表，即使测试被提前停止也一样。WAS报表可以从View菜单选择Reports查看。下面介绍一下报表中几个重要的部分。
页面摘要部分提供了页面的名字，接收到第一个字节的平均时间（TTFB），接收到最后一个字节的平均时间（TTLB），以及测试脚本中各个页面的命中次数。TTFB和TTLB这两个值对于计算客户端所看到的服务器性能具有重要意义。TTFB反映了从发出页面请求到接收到应答数据第一个字节的时间总和（以毫秒计），TTLB包含了TTFB，它是客户机接收到页面最后一个字节所需要的累计时间。
只要选中页面的名字，即可显示页面概要。
[attach]76410[/attach]
如果这是一个新创建的测试脚本，你应该检查一下报表的Result
Codes部分。这部分内容包含了请求结果代码、说明以及服务器返回的结果代码的数量。如果这里出现了404代码（页面没有找到），说明在脚本中有错误的页面请求。具体的错误代码表示的意义，可以参考IIS的说明文档。
[attach]76411[/attach]
报表中还包含了所有性能计数器的信息。这些数据显示了运行时各个项目的测量值，同时还提供了最大值、最小值、平均值等。报表实际提供的信息远远超过了我们这里能够介绍的内容。
[attach]76412[/attach]
这里显示的是运行本次测试时的设置，也就是前面讲到的Setting部分的内容。
5.5 Test Clients
这里显示的是各个WAS客户机的情况。先总体说明在测试中使用了那些WAS客户机，在使用的WAS客户机中显示
l 执行了多少线程
l 模拟了多少用户
l 点击的次数
l 连接失败的次数
[attach]76413[/attach]
显示了在测试中各个请求内容的TTFB和TTLB，以及点击的次数等信息。具体的说明已经包含在5.1摘要中
显示不同的用户组在测试中的执行情况。这里提供的信息包括
l 用户组的分布情况，以及在所有用户组中所占的比例
l 点击的次数，以及在所有点击次数中所占的比例
l Result Codes情况
Socket连接的信息
[attach]76414[/attach]
显示了各个请求内容的更加详细的信息。技术需求中的运行效率信息可以在这里验证。
25%、50%、75%的数字还没有弄明白什么意思？？？？？平均值还不知道怎样计算出来的
在前边提到，编写测试脚本有4种方法，现在对其他三种方法进行简单的介绍
打开菜单，选择Scripts|Create|Manual
手动创建一个测试脚本
[attach]76415[/attach]
然后出现了NewScript，[server]中输入要进行测试的服务器IP地址或计算机名称；在脚本的内容表格中[verb]项选择脚本运行方式 get、post、head；[path]中输入向服务器提交的文件或字符串。
[attach]76416[/attach]
这种方法适合于开始投入运行的Web应用程序。IIS日志记录了用户访问系统的所有信息。通过导入IIS日志的方法建立的测试脚本，是最符合实际运行情况的方法。如果有IIS日志，我们推荐使用这种方法。
这种方法也比较简单。打开菜单，选择Scripts|Create|Log 导入IISs日志创建一个测试脚本。
[attach]76417[/attach]
然后出现导入IIS日志的第一步，选择IIS日志的路径，默认情况下的路径如图所示
[attach]76418[/attach]
Next进入第二步，一般情况下不用做改动。取默认即可
[attach]76420[/attach]
Finish后，WAS自动生成脚本。6.3 导入网站内容文件
这种方法通过导入网站上具体的文件来生成测试脚本。一般情况下，不推荐使用这种方法。下面简单说明这种方法的使用。打开菜单，选择Scripts|Create|Contents ，WAS自动新建一个测试脚本，并且切换到Contents Tree节点。
[attach]76419[/attach]
然后回到New Script的主页面，会看到选择的内容文件自动添加到表格中
[attach]76421[/attach]
使用方法就是这样。
7 初步的想法1 在大规模的测试时，需要很多WAS客户端。为了充分利用资源，可以在项目组每个人的机器上都安装WAS软件（只要正确安装，启动WebTool服务即可）。这样测试时，WAS会自动协调，自动分配线程。
2 我们的系统中有很多的角色。虽然WAS可以将不同角色执行请求的顺序进行混合，但是这样我们不知道WAS怎样混合的，不能随时控制角色的状态。建议将不同的角色分组，每个角色放到一个WAS测试机（充当控制器）上，这样可以分角色而又集中的对WebServer进行压力测试，同时又能随意的控制各个WAS客户机的状态。这种思想是模仿LoadRunner软件，具体实施还需要不断的实验和学习。
3 在集成测试时，先注重性能方面的测试，逐步的加压，寻找WebServer的最大负载量。进而对照技术需求，不断改进。
4 WAS首先是性能测试工具，然后才是压力测试工具。具体测试时，可以先在正常的条件下（满足技术需求）进行性能测试，然后才是异常情况（增加压力到技术需求规定的1.5-2倍）的测试。
5 不断的研究学习，利用WAS更深入地了解你的应用的性能、稳定性、瓶颈和局限性。
目前存在的问题：
1 在测试结果Report中的Page Data部分，25%、50%、75%的值到底是什么意思？Average又是怎样计算出来的
2 在关于身份验证的页面中，如何模拟多用户使用不同的账号登陆？按照帮助说明和例子的说明，在ASP.NET开发的登陆程序中没有试验成功。（帮助中这么说明：取用户名是在POST数据项中把用户名用“%Username%”代替，密码用“%Password%”代替）
3 添加性能计数器时，添加本机的当然没有问题。但是如何添加服务器的性能计数器。这需要在服务器端进行设置，但怎样设置？还没有弄清楚。（这个问题已经清楚了，服务器端不需要任何设置，只要客户机和服务器在一个工作组即可）
以下文字摘自网络上的文章。仅供参考。
随着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个用户获得了好处。
静态页面方法并不能够适合所有类型的页面。例如，某些页面在进行任何处理之前必须要有用户输入。但是，这种方法可以成功地应用到那些不依赖用户输入却进行大量数据库调用的页面，而且这种情况下它将发挥出更大的效率。
在大多数情况下，动态页面的生成将在相当大的程度上提高网站的性能而且无需在功能上有所折衷。虽然有许多大的网站采用了这个策略来改善性能，也有许多网站完全由于进行大量没有必要的数据库调用而表现出很差的性能。
| 欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) | Powered by Discuz! X3.2 |