Web压力测试简介

Web压力测试简介
一.Web压力测试
传统的系统测试由三部分组成：性能测试、案例测试和压力测试。

压力(或称工作负载平衡): 它与另两个部分不同，因为它被设计为通过应用很大的工作负载来使软件超负荷运转。

如果压力测试通过对产品保持高强度的使用(但不超过性能统计数字确定的限制)能有效地执行，那么它就经常能够发现许多隐蔽的错误，而这些错误用任何其它技术都是发现不了的(这些错误也经常是最难修复的)。

1.1压力下的错误
使用压力测试，您有希望找到很多种用其它测试方法更难发现的错误。

有两种错误类型是:
内存泄漏(Memory leak): 一种极难检测的现象。

内存泄漏经常发生在已发行的产品中，原因很简单，很难设计测试用例来检测它们。

使用简单的功能测试，几乎发现不了内存泄漏问题，因为在产品完成之前测试没对产品进行足够多的使用。

内存泄漏通常要求操作要重复非常多的次数以使内存消耗达到能引起注意的程度。

尽管与其它编程语言(如C/C++)相比，Java 程序更难引入内存泄漏错误，但只要程序仍保持着对对象的引用，该对象仍有可能被实例化并且它占用的内存永远不会被释放。

并发与同步(Concurrency and Synchronization): 压力测试在查找并发性问题上非常出众，这是因为在任何一个测试生命周期中，它都应用了许多不同的代码路径和定时条件。

一般的规则是，压力测试运行的时间越长，涉及并应用的代码路径组合和定时条件就越多。

当然，这也的确使得这些问题很难再现(错误可以在5 分钟或5 天后发生)。

死锁、线程泄漏以及任何一般的同步问题通常只能在压力测试阶段被检测出来。

这些类型的问题很难通过执行单元测试来发现。

开发人员不会一直考虑他或她的代码将与其它地方的代码(在执行单元测试时这些代码可能还没写出来)进行交互。

1.2设计压力应用
设计试图对Web 服务进行压力测试的压力测试系统时，要让它们以某种特定的方式运行代码。

这些风格超越了功能验证，目的是要弄清楚被测试的Web 服务是不是不仅能做我们认为它能做的事，而且在被施加了某些高强度压力的情况下仍然继续正常运行。

压力测试必须对Web 服务应用四个基本条件。

许多已建立的压力系统应用了这些条件。

有效的压力测试系统将应用以下这些关键条件:
重复(Repetition): 或许最明显的且最容易理解的压力条件就是测试的重复。

换句话说，测试的重复就是一遍又一遍地执行某个操作或功能，比如重复调用一个Web 服务。

功能验证测试可以用来被弄清楚一个操作能否正常执行。

而压力测试将确定一个操作能否正常执行，并且能否继续在每次执行时都正常。

这对于推断一个产品是否适用于某种生产情况至关重要。

客户通常会重复使用产品，因此压力测试应该在客户之前发现代码错误。

许多最简单的压力系统只实现这一个条件，但简单地扩展功能验证测试来多次重复并不能构成一个有效的压力测试。

当与下面的一些原则结合起来使用时，重复就可以发现许多隐蔽的代码错误。

并发(Concurrency): 并发是同时执行多个操作的行为。

换句话说，就是在同一时间执
行多个测试，例如在同一个服务器上同时调用许多Web 服务。

这个原则不一定适用于所有的产品(比如无状态服务)，但是多数软件都具有某个并发行为或多线程行为元素，这一点只能通过执行多个代码示例才能测出来。

功能测试或单元测试几乎不会与任何并发设计结合。

压力系统必须超越功能测试，要同时遍历多条代码路径。

至于怎么做到这一点取决于具体的产品。

例如，一个Web 服务压力测试需要一次模拟多个客户机。

Web 服务(或者任何多线程代码)通常会访问多个线程实例间的一些共享数据。

因额外方面的编程而增加的复杂性通常意味着代码会具有许多因并发引起的错误。

由于引入并发性意味着一个线程中的代码有可能被其它线程中的代码中断，所以错误只在一个指令集以特定的顺序(例如以特定的定时条件)执行时才会被发现。

把这个原则与重复原则结合在一起，您可以应用许多代码路径和定时条件。

量级(Magnitude): 压力系统应该应用于产品的另一个条件考虑到了每个操作中的负载量。

压力测试可以重复执行一个操作，但是操作自身也要尽量给产品增加负担。

例如，一个Web 服务允许客户机输入一条消息，您可以通过模拟输入超长消息的客户机来使这个单独的操作进行高强度的使用。

换句话说就是，您增加了这个操作的量级。

这个量级总是特定于应用的，但是可以通过查找产品的可被用户计量和修改的值来确定它。

例如，数据的大小、延迟的长度、资金数量的转移、输入速度以及输入的变化等等。

单独的高强度操作自身可能发现不了代码错误(或者仅能发现功能上的缺陷)，但与其它压力原则结合在一起时，您将可以增加发现问题的机会。

随机变化: 最后一点，任何压力系统都多多少少具有一些随机性。

如果您随机使用前面的压力原则中介绍的无数变化形式，您就能够在每次测试运行时应用许多不同的代码路径。

下面是几个关于怎样在测试生命周期内改变测试的示例。

使用重复时，在重新启动或重新连接服务之前，您可以改变重复操作间的时间间隔、重复的次数，或者也可以改变被重复的Web 服务的顺序。

使用并发，您可以改变一起执行的Web 服务、同一时间运行的Web 服务数目，或者也可以改变关于是运行许多不同的服务还是运行许多同样的实例的决定。

量级或许是最容易更改的—每次重复测试时都可以更改应用程序中出现的变量(例如，发送各种大小的消息或数字输入值)。

如果测试完全随机的话，因为很难一致地重现压力下的错误，所以一些系统使用基于一个固定随机种子的随机变化。

这样，用同一个种子，重现错误的机会就会更大。

二.压力测试步骤与指标
随着WEB应用程序使用越来越广泛，针对其性能测试的要求也越来越多。

然而由于WEB程序混合了大量的技术，如：HTML、Java、javascript、VBScript等，同时它还依赖很多其它的因素，如：Link、Database、Network等，使得WEB应用程序测试变得更加复杂。

WEB压力测试是评价一个WEB应用程序的重要手段，我觉得可以从以下几个方面入手：
1. 充分熟悉待测软件。

这是测试前的准备工作，任何一个项目，在开始测试之前，都应该对它有个全面的了解，如这个软件是干什么的，其功能和性能主要体现在哪几个方面，有什么特点，如何才能体现这些特点等。

2. 制定测试计划。

测试计划就是定义一个测试项目的过程，以便能够正确地度量和控制测试。

测试计划包括准备采用哪种测试工具，根据现有条件准备搭建的测试模拟环境，测试完成的标准（包括数据库的大小、并发用户的多少等），是否进行对比测试，测试方法与进度安排等等。

3. 实施测试。

按照测试计划，在各种条件下，运行事先设计的测试脚本，记录WEB服务器及相关客户端的性能参数。

在一定的范围内调整数据库的大小、并发访问的用户数、访问时间等测试条件以获得所需要的数据。

4. 分析测试结果。

测试会收集到大量的数据，根据这些数据就可以帮助分析Web应用程序的性能。

对其性能的描述可以采用线图、条形图和报表等多种直观的形式。

具体而言，评价WEB应用的有以下几个指标：
Number of hits：测试间隔内虚拟用户点击页面的总次数;
Requests per second：每秒客户端的请求次数;
Threads：线程数，即虚拟用户并发量;
Socket Errors Connect：Socket错误连接次数;
Socket Errors Send：Socket错误发送次数;
TTFB Avg：从第一个请求发出到测试工具接收到服务器应答数据的第一个字节之间的平均时间;
TTLB Avg：从第一个请求发出到测试工具接收到服务器应答数据的最后一个字节之间的平均时间。

根据以上数据，可以从以下几个方面分析应用程序性能，生成相应报表：
Number of hits vs. Users：随着虚拟用户的增加，服务器在规定时间内所能处理的总点击数；
Requests per second vs. Users：随着虚拟用户的增加，服务器在规定时间内所能处理的每秒请求数；
Errors vs. Time：随着模拟访问时间的延续，出现错误的数量；
Errors vs. Users：随着虚拟用户的增加，出现错误的数量；
Performance Distribution vs. Users：针对虚拟用户数的应用性能分布情况，包括服务器的内存、CPU使用情况等。

三.压力测试软件
我推荐各位Web 2.0开发测试人员使用Microsoft 的Web Application Stress Tool(WAST)这个工具软件，这个微软提供的小工具仅9.58M，很小巧且实用。

虽然功能上比不了专业的LoadRunner，但LoadRunner体积庞大，价格不菲，一般的企业也不会花那么多钱去购买LoadRunner，而微软的W AS则是完全免费，并且主要的功能都有，够用就行。

1.1 测试工具的设置
点击“Defaults→Settings”打开设置面板。

在Concurrent Connections下进行并行连接设置。

Stress Level（Threads）是最少线程，Stress Multiplier是最大线程。

这里的线程是指定程序在后台用多少线程进行请求，也就是相当于模拟多少个客户机的连接，一般填写500～
1000。

这个线程数是根据本机的承受力来设置的，如果你对自己的机器配置有足够信心的话，那么可以设置得更高一些。

2．设置持续时间
在“Test Run Time”中用来指定一次压力测试需要持续的时间，分为天、小时、分、秒几个单位级别，比如我们设置为1个小时。

3．其余设置
用Rpquest Delay设置延迟时间，我们设置为100～500。

用Suspend设置设定挂起时间，Warmup时间是初始化测试运行时间，Cooldown时间是指定结束阶段的测试时间。

Bandwith 指定带宽瓶颈，允许模拟从14．4 kbps的Modem连接到T1（1．5 Mbps）的Local Area Network （LAN）连接的网络带宽。

Redirects设置复位向时间，Throughput用来设置用户、密码页面状态保存等是否启用，Name Resolution用来设置是否进行名称解析。

所有以上的选项大家可以根据自己的需要进行设置。

1.2 压力测试的步骤
设置完成后就可以进行压力测试。

测试的步骤如下：
第一步，点击工具栏上的“New Script”按钮，在打开的面板中点击“Nanual”按钮创建一个新的测试项目。

在打开的窗口中对它进行设置，在主选项中的Server中填写要测试的服务器的IP地址。

这里我们填写192.168.1.20。

在下方选择测试的Web连接方式，这里的方式Verb选择get。

Path选择要测试的Web页面路径，这里填写/Index.asp即动网的首页文件，WAST可以设置更多的Path。

第二步，在“Settings”功能设置中将Stress Level （Threads）线程数设置为1000。

然后点工具中的灰色三角按钮即可进行测试。

测试过程中我们可以从服务器的任务管理器中看到CPU使用率已经达到100%，损耗率达到最大。

在CMD窗口中使用命令netstat -an，可以看到客户端的IP地址在服务器上的80端口进行了非常多的连接，而且Web网站已经打不开了，提示过多用户连接。

通过压力测试，管理员对Web服务器的抗压能力有了大概了解，可根据实际需要进行服务器硬件扩展，也为系统设置和软件选择等提供依据。

Web服务器在正式发布前进行压力测试是非常必要的。