|
|
知识路径： > 测试技术的分类 > 应用负载压力测试 > 负载压力测试实施 > 测试环境、工具、数据准备 >
|
|
考试要求：掌握
相关知识点：15个
|
|
|
|
|
这里主要讨论选择测试工具的原则，介绍一些主流负载压力测试工具，同时也涉及到测试工具的缺陷等内容。
|
|
|
|
|
|
古人云“工欲善其事，必先利其器”，进行负载压力性能测试首先应该选择一个合适的测试工具，一个测试工具能否满足测试需求、能否达到令人满意的测试结果，是选择测试工具要考虑的最基本的问题。更进一步可以考虑一些细节问题，比如该工具对于处理扩展的交互（例如一个请求取决于上一个请求的结果）如何；对于处理cookies（cookies对于许多面向会话的J2EE系统是必不可少的）如何；如果J2EE应用程序客户机需要处理一些JavaScript，以进入下一次通信会如何处理；在收集了响应时间数据后，如何对它进行分析；对CPU时间、网络使用、堆大小、分页活动或者数据库活动如何监控等都是选择一个测试工具需要考虑的具体问题。一些高端工具与基本工具往往在一些细节、适用范围以及易用性方面存在差别。比如，顶级的负载测试工具可以模拟多个浏览器，与大多数应用服务器集成，收集多个服务器主机的性能数据（包括操作系统、JVM和数据库统计数字），生成可以在以后用高级的分析工具分析的数据集。
|
|
|
|
当然，测试工具的选择首先应该看是否能够满足基本测试需求，该工具必须可以模拟应用程序客户机，如果应用程序使用一些不常见的浏览器功能组合或者其他非标准客户机技术，那么就排除了相当一部分候选者。具备了基本功能后，可以考虑工具的生产率。一般来说，包含的分析工具越多，可以记录的性能数据类型越多，可以达到的生产率就越高，价格也就越高。不过有些低端负载测试程序是免费的，在预算有限的情况下，“免费”的意义是不言自明的。
|
|
|
|
|
|
|
|
首要要求一定是负载测试程序能够处理应用程序所使用的功能和协议。
|
|
|
|
|
|
这是负载测试程序最基本、且最重要的功能，它有助于确定哪些是负载测试程序以及哪些不是。
|
|
|
|
|
|
如果不能编辑客户机与服务器之间交互的脚本，那么就不能处理除最简单的客户机之外的任何东西。编辑脚本的能力是最基本的，且小的改变不应该要求重新生成脚本。
|
|
|
|
|
|
如果不支持会话或者cookies，就不算是真正的负载压力测试工具，并且不能对大多数J2EE应用程序进行负载测试。
|
|
|
|
|
|
测试程序应该可以让您指定每个脚本由多少个模拟用户运行，包括让您随时间改变模拟用户的数量，因为许多负载测试可以做到从小的用户数量开始，并慢慢增加到更多的用户数量。
|
|
|
|
|
|
每一个脚本都必须定义一个方法来识别成功的交互以及失败和错误模式（错误一般不会有页面返回，而失败可能在页面上得到错误的数据）。
|
|
|
|
|
|
如果测试工具可以检查一些发送给模拟用户的页面，这会很有用，这样可以做到心中有数，以确保测试工作是正确进行的。
|
|
|
|
|
|
可以用不同的工具来分析测试结果，这些工具包括电子表格和可以处理数据的自定义脚本。虽然许多负载测试工具包括大量的分析功能，但是导出数据的能力使您在以任意的方式分析和编辑数据方面具有更大的灵活性。
|
|
|
|
|
|
真实世界的用户不会在收到一页后立即请求另一页，一般在查看一页和下一页之间会有延迟。考虑时间这个标准术语表示在脚本中加入延迟以更真实地模拟用户行为。大多数负载测试程序支持根据统计分布随机生成考虑时间。
|
|
|
|
|
|
用户一般不会使用同样的一组数据，每位用户通常与服务器进行不同的交互。模拟用户应该也这样做，如果在交互的关键点，脚本可以从一组数据中选择数据，则可以更容易地让您的模拟用户表现出使用不同数据的行为。
|
|
|
|
|
|
相对于编写脚本，用浏览器手工运行会话并记录这个会话，然后再编辑会容易得多。
|
|
|
|
|
|
一些应用程序大量使用JavaScript并且需要模拟客户机支持它。不过，使用客户端JavaScript可能会增加对测试系统上系统资源的需求。
|
|
|
|
|
|
得到测试数据只是成功的一半，另一半是分析性能数据。因此测试工具提供的分析工具越多，就越有利于从不同的方面进行数据分析。
|
|
|
|
|
|
基本负载压力测试工具测量客户机/服务器交互中基于客户机的响应时间。如果同时收集其他统计数据（如CPU使用情况和页面错误率）就更好了，有了这些数据，就可以进一步做一些有用的工作，如查看服务器负载上下文中的客户机响应时间和吞吐量统计。
|
|
|
|
|
|
任何负载压力测试工具都不是完美无缺的，在我们的实际使用中经常碰到一些问题，概括起来主要有以下几点：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
在实际压力测试过程中，我们通常使用多种工具达到测试目的，如何配合使用多种工具，是否能达到最好的“性能价格比”？测试工程师要发挥最大的主观能动性。
|
|
|
|
|
|
. 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，资源消耗较小，支持一些底层访问。
|
|
|
|
|
|
|
