有许多声称能够对产品进行压力测试的可用工具目前正在开发中。被广泛应用的是针对 Web 服
务的那些工具。然而，这些工具中有许多只是简单的 HTML/SOAP 生成器，它们模拟许多客户机连接，
并因此对 Web 服务器生成高负载(这对于查找 Web 服务器的问题很有用，但对于查找 Web 服务的问
题就没那么有用了)。这些工具对基本的压力测试比较有用，但它们经常是仅仅扩展功能验证阶段来重
复地执行相同的功能任务。如果足够的时间和资源可用，就可以通过创建定制构建的压力测试系统来
实现更有效的测试。由于压力系统的设计者通常对要测试的产品和 Web 服务有更多的了解，所以他们
将能够确保压力系统可以用于哪些具体的代码区域。
设计压力应用
设计试图对 Web 服务进行压力测试的压力测试系统时，要让它们以某种特定的方式运行代码。
这些风格超越了功能验证，目的是要弄清楚被测试的 Web 服务是不是不仅能做我们认为它能做的事，
而且在被施加了某些高强度压力的情况下仍然继续正常运行。压力测试必须对 Web 服务应用四个基
本条件。许多已建立的压力系统应用了这些条件。有效的压力测试系统将应用以下这些关键条件:
重复(Repetition): 或许最明显的且最容易理解的压力条件就是测试的重复。换句话说，测试的重
复就是一遍又一遍地执行某个操作作或功能，比如重复调用一个 Web 服务。功能验证测试可以用来
被弄清楚一个操作作能否正常执行。而压力测试将确定一个操作作能否正常执行，并且能否继续在每
次执行时都正常。这对于推断一个产品是否适用于某种生产情况至关重要。客户通常会重复使用产品，
因此压力测试应该在客户之前发现代码错误。许多最简单的压力系统只实现这一个条件，但简单地扩
展功能验证测试来多次重复并不能构成一个有效的压力测试。当与下面的一些原则结合起来使用时，
重复就可以发现许多隐蔽的代码错误。
并发(Concurrency): 并发是同时执行多个操作作的行为。换句话说，就是在同一时间执行多个测
试，例如在同一个服务器上同时调用许多 Web 服务。这个原则不一定适用于所有的产品(比如无状态
服务)，但是多数软件都具有某个并发行为或多线程行为元素，这一点只能通过执行多个代码示例才能
测出来。功能测试或单元测试几乎不会与任何并发设计结合。压力系统必须超越功能测试，要同时遍
历多条代码路径。至于怎么做到这一点取决于具体的产品。例如，一个 Web 服务压力测试需要一次模
拟多个客户机。Web 服务(或者任何多线程代码)通常会访问多个线程实例间的一些共享数据。因额外
方面的编程而增加的复杂性通常意味着代码会具有许多因并发引起的错误。由于引入并发性意味着一
个线程中的代码有可能被其他线程中的代码中断，所以错误只在一个指令集以特定的顺序(例如以特定
的定时条件)执行时才会被发现。把这个原则与重复原则结合在一起，您可以应用许多代码路径和定时
条件。
量级(Magnitude): 压力系统应该应用于产品的另一个条件考虑到了每个操作作中的负载量。压力
测试可以重复执行一个操作作，但是操作作自身也要尽量给产品增加负担。例如，一个 Web 服务允
许客户机输入一条消息，您可以通过模拟输入超长消息的客户机来使这个单独的操作作进行高强度的
使用。换句话说就是，您增加了这个操作作的量级。这个量级总是特定于应用的，但是可以通过查找
产品的可被用户计量和修改的值来确定它。例如，数据的大小、延迟的长度、资金数量的转移、输入
速度以及输入的变化等等。单独的高强度操作作自身可能发现不了代码错误(或者仅能发现功能上的缺
陷)，但与其他压力原则结合在一起时，您将可以增加发现问题的机会。
随机变化: 最后一点，任何压力系统都多多少少具有一些随机性。如果您随机使用前面的压力原则
中介绍的无数变化形式，您就能够在每次测试运行时应用许多不同的代码路径。下面是几个关于怎样在
测试生命周期内改变测试的示例。使用重复时，在重新启动或重新连接服务之前，您可以改变重复操作
作间的时间间隔、重复的次数，或者也可以改变被重复的 Web 服务的顺序。使用并发，您可以改变一
起执行的 Web 服务、同一时间运行的 Web 服务数目，或者也可以改变关于是运行许多不同的服务还
是运行许多同样的实例的决定。量级或许是最容易更改的 — 每次重复测试时都可以更改应用程序中出
现的变量(例如，发送各种大小的消息或数字输入值)。如果测试完全随机的话，因为很难一致地重现压
力下的错误，所以一些系统使用基于一个固定随机种子的随机变化。这样，用同一个种子，重现错误的
机会就会更大。