|
|
知识路径： > 测试技术的分类 > 应用负载压力测试 > 负载压力测试实施 > 测试环境、工具、数据准备 > 测试工具准备 >
|
|
相关知识点：3个
|
|
|
|
|
. QALoad——美国Compuware（康博）公司。
|
|
|
|
|
|
①测试接口。DB2，DCOM, ODBC, ORACLE, NETLoad, Corba, QARun, SAP, SQLServer, Sybase, Telnet, TUXEDO, UNIFACE, WinSock, WWW。
|
|
|
|
②预测系统性能。当应用升级或者新应用部署时，负载测试能帮助确定系统是否能按计划处理用户负载。QALoad并不需调用最终用户及其设备，它能够仿真数以千计的用户进行商业交易。通过QALoad，用户可以预知业务量接近投产后的真实水平时端对端的响应时间，以便满足投产后的服务水平要求。
|
|
|
|
③通过重复测试寻找瓶颈问题。QALoad录制/回放能力提供了一种可重复的方法来验证负载下的应用性能，可以很容易地模拟数千个用户，并执行和运行测试。利用QALoad反复测试可以充分地测试与容量相关的问题，快速确认性能瓶颈并进行优化和调整。
|
|
|
|
④从控制中心管理全局负载测试。QALoad Conductor工具为定义、管理和执行负载测试提供了一个中心控制点。Conductor通过执行测试脚本管理无数的虚拟用户。Conductor可以自动识别网络中可进行负载测试的机器，并在这些机器之间自动分布工作量以避免网段超载。从Conductor自动启动和配置远程用户，跨国机构可以进行全球负载测试。在测试过程中，Conductor还可以在负载测试期间收集有关性能和时间的统计数据。
|
|
|
|
⑤验证应用的可扩展性。出于高可扩展性的设计考虑，QALoad包括了远程存储虚拟用户响应时间，并在测试结束后或其他特定时间下载这些资料的功能。这种方法可以增加测试能力，减少进行大型负载测试时的网络资源耗费。QALoad采用轮询法采集响应时间，在无需影响测试或增加测试投资的条件下，就可了解测试中究竟出现了什么情况。
|
|
|
|
在利用QALoad进行测试时，可以有选择地改变硬件或软件的配置，并改变测试步调和负载量。QALoad系统的NetLoad模块帮助建立所需的额外网络流量来模拟真实的产品负载。借助于“NetLoad”，可以在大环境下分配虚拟用户，更好地规划在投产环境中如何让这些应用更好地工作。
|
|
|
|
QALoad引入了“flash”为电子商务应用软件作容量测试。flash测试允许在测试期间增加大量的虚拟用户，来确定压力对底层部件和基础结构的影响。flash测试也可以证明应用投产后其响应时间将不会降低至服务级以下。
|
|
|
|
⑥快速创建仿真的负载测试。准确仿真复杂业务的进行，对于预测电子商务应用软件的功能至关重要。运用QALoad，可以迅速创造出一些实际的安装测试方案，而不需要手工编写脚本或有关应用中间软件的详细知识和协议。
|
|
|
|
对结合了多种传输协议的应用软件进行负载测试是一个巨大的挑战。为了准确仿真这些应用软件产生的流量，QALoad可以捕获多种协议并在同一测试过程中执行它们。基于浏览器的应用经常打开与服务器的多个连接以缩短网页下载时间，导致服务器的额外流量。QALoad能准确地仿真出浏览器与服务器之间的交互，包括多重连接，使负载更加准确。
|
|
|
|
另外，这些应用软件常常包含一些在测试方案中必须申明的动态信息。运用QALoad的ActiveData特征，可以定义脚本参数，以帮助确保应用测试脚本的成功执行。
|
|
|
|
例如，对一些安全或非安全的Web应用软件，ActiveData自动转化为动态信息，如cookies，包括动态Active Serve Page cookies、动态URL名称、服务器导向、动态框架或者其他时期的特定信息。ActiveData for Web有助于保证测试脚本与Web应用在测试过程中保持同步。
|
|
|
|
ActiveData每次自动查找和提出需要的变更建议，使测试脚本正确执行。在脚本执行过程中，脚本中的信息可以被产生的正确信息自动替代。
|
|
|
|
|
|
这些特点应该是负载压力测试工具普遍具备的特点，在后面的负载压力工具介绍中就不再赘述，而是介绍一些除了这些之外的特点。
|
|
|
|
|
|
|
|
|
|
测试结果分析如下图所示，1—2—3表示业务组A，4-5-6表示业务组B，7—8—9表示业务组C，10—11—12表示业务组D，在各个业务组中序号从小到大表示不同的并发用户。
|
|
|
|
|
|
|
|
. LoadRunner——美国Mercury Interactive公司。
|
|
|
|
|
|
①测试接口：支持的协议多且个别协议支持的版本较高；
|
|
|
|
|
|
|
|
④报告可以导出到Word、Excel以及HTML格式。
|
|
|
|
|
|
|
|
. Benchmark Factory——美国Quest软件公司。
|
|
|
|
|
|
|
|
|
|
③可以生成高级脚本，例如脚本中数据池的生成可以采用随机数。
|
|
|
|
|
|
这是一个Microsoft提供的免费的Web负载压力测试工具，应用比较广泛，下面做一个较详细的介绍。
|
|
|
|
WAS可以通过一台或者多台客户机模拟大量用户的活动。WAS支持身份验证、加密和Cookies，也能够模拟各种浏览器类型和Modem速度，它的功能和性能可以与数万美元的产品相媲美。
|
|
|
|
要对网站进行负载测试首先必须创建WAS脚本模拟用户活动。我们可以用下面四种方法之一创建脚本：①通过记录浏览器的活动；②通过导入IIS日志；③通过把WAS指向Web网站的内容；④手工制作。
|
|
|
|
制作WAS脚本是相当简单的，不过要制作出模拟真实用户活动的脚本就有些复杂。如果你已经有一个运行的Web网站，可以使用Web服务器的日志来确定Web网站上的用户点击分布。如果你的应用还没有开始运行，那么只好根据经验作一些猜测了。
|
|
|
|
|
|
①Number of hits：测试间隔内虚拟用户点击页面的总次数；
|
|
|
|
②Requests per second：每秒客户端的请求次数；
|
|
|
|
|
|
④TTFB Avg：从第一个请求发出到测试工具接收到服务器应答数据的第一个字节之间的平均时间；
|
|
|
|
⑤TTLB Avg：从第一个请求发出到测试工具接收到服务器应答数据的最后一个字节之间的平均时间。
|
|
|
|
准备好测试脚本之后，我们可以调整测试配置，以便观察不同条件下的应用性能。如下图所示是WAS的设置界面。
|
|
|
|
|
|
|
|
Stress Level和Stress Multiplier这两项决定了访问服务器的并发连接的数量。如果要模拟的并发连接数量超过100个，可以调整Stress multiplier或使用多个客户机。在负载测试期间WAS将通过DCOM与其他客户机协调。有关在测试中使用多个客户机的更多信息，参见http://webtool.rte.microsoft.com/kb/hkb13.htm。
|
|
|
|
如果网站提供个性化服务，要进行身份验证或使用Cookies，我们还要为WAS提供一个用户目录。WAS中的用户存储了发送给服务器的密码以及服务器发送给客户端的Cookies。增加用户数量并不增加Web服务器的负载。必须提供足够数量的用户以满足并发连接的要求（Stress Level乘以Stress Multiplier）。有关线程、用户和Cookies相互作用的更多信息请参见http://webtool.rte.microsoft.com/Threads/WASThreads.htm。
|
|
|
|
WAS允许设置warmup（热身）时间，一般可以设置为1分钟。在warmup期间WAS开始执行脚本，但不收集统计数据。warmup时间给MTS、数据库以及磁盘缓冲等一个机会来做准备工作。如果在warmup时间内收集统计数据，这些操作的开销将影响性能测试结果。
|
|
|
|
设置页面提供的另外一个有用的功能是限制带宽（throttle bandwidth）。带宽限制功能能够为测试模拟出Modem（14.4K, 28.8K, 56K）、ISDN（64K，128K）以及T1（1.54M）的速度。使用带宽限制功能可以精确地预测出客户通过拨号网络或其他外部连接访问Web服务器所感受的性能。
|
|
|
|
要理解这些不同的设置对应用的影响，有必要了解如何使用WAS收集性能数据。
|
|
|
|
使用WAS，从远程Windows NT和Windows 2000机器获取和分析性能计数器（Performance Counter）是很方便的。加入计数器要用到如下图所示的Perf Counters分支。
|
|
|
|
|
|
|
|
在测试中选择哪些计数器显然跟测试目的有关。虽然下面这个清单不可能精确地隔离出性能瓶颈所在，但对一般的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。
|
|
|
|
每次测试运行结束后WAS会生成详细的报表，即使测试被提前停止也一样。WAS报表可以从View菜单选择Reports查看。下面介绍一下报表中几个重要的部分。
|
|
|
|
如果这是一个新创建的测试脚本，你应该检查一下报表的Result Codes部分。这部分内容包含了请求结果代码、说明以及服务器返回的结果代码的数量。如果这里出现了404代码（页面没有找到），说明在脚本中有错误的页面请求。
|
|
|
|
页面摘要部分提供了页面的名字，接收到第一个字节的平均时间（TTFB），接收到最后一个字节的平均时间（TTLB），以及测试脚本中各个页面的命中次数。TTFB和TTLB这两个值对于计算客户端所看到的服务器性能具有重要意义。TTFB反映了从发出页面请求到接收到应答数据第一个字节的时间总和（以毫秒计），TTLB包含了TTFB，它是客户机接收到页面最后一个字节所需要的累计时间。
|
|
|
|
报表中还包含了所有性能计数器的信息。这些数据显示了运行时各个项目的测量值，同时还提供了最大值、最小值、平均值等。报表实际提供的信息远远超过了我们这里能够介绍的内容。为了给你一个有关报表所提供信息种类的印象，摘录了一个报表实例如下图所示。
|
|
|
|
|
|
|
|
. SILK PERFORMER V——美国Segue公司。
|
|
|
|
|
|
|
|
②脚本采用PASCAL，资源消耗较小，支持一些底层访问。
|
|
|
|
|
|
|
