软件测试之（web服务压力测试）有效的压力测

1）重复（Repetition）：最明显的且最容易理解的压力条件就是测试的重复。换句话说，软件测试的重复就是一遍又一遍地执行某个操作或功能，比如重复调用一个Web服务。功能验证测试可以用来被弄清楚一个操作能否正常执行。而压力测试将确定一个操作能否正常执行，并且能否继续在每次执行时都正常。这对于推断一个产品是否适用于某种生产情况至关重要。许多最简单的压力系统只实现这一个条件，但简单地扩展功能验证测试来多次重复并不能构成一个有效的压力测试。当与下面的一些原则结合起来使用时，重复就可以发现许多隐蔽的代码错误。

2）并发（Concurrency）：并发是同时执行多个操作的行为。换句话说，就是在同一时间执行多个测试，例如在同一个服务器上同时调用许多Web服务。这个原则不一定适用于所有的产品（比如无状态服务），但是多数软件都具有某个并发行为或多线程行为元素，这一点只能通过执行多个代码示例才能测出来。功能测试或单元测试几乎不会与任何并发设计结合。压力系统必须超越功能测试，要同时遍历多条代码路径。至于怎么做到这一点取决于具体的产品。例如，一个Web服务压力测试需要一次模拟多个客户机。Web服务（或者任何多线程代码）通常会访问多个线程实例间的一些共享数据。因额外方面的编程而增加的复杂性通常意味着代码会具有许多因并发引起的错误。由于引入并发性意味着一个线程中的代码有可能被其他线程中的代码中断，所以错误只在一个指令集以特定的顺序（例如以特定的定时条件）执行时才会被发现。把这个原则与重复原则结合在一起，可以应用许多代码路径和定时条件。

3）量级（Magnitude）：压力系统应该应用于产品的另一个条件考虑到了每个操作中的负载量。压力测试可以重复执行一个操作，但是操作自身也要尽量给产品增加负担。例如，一个Web服务允许客户机输入一条消息，您可以通过模拟输入超长消息的客户机来使这个单独的操作进行高强度的使用。换句话说就是，您增加了这个操作的量级。这个量级总是特定于应用的，但是可以通过查找产品的可被用户计量和修改的值来确定它—例如，数据的大小、延迟的长度、资金数量的转移、输入速度以及输入的变化等等。单独的高强度操作自身可能发现不了代码错误（或者仅能发现功能上的缺陷），但与其他压力原则结合在一起时，您将可以增加发现问题的机会。

4）随机变化：最后一点，任何压力系统都多多少少具有一些随机性。如果您随机使用前面的压力原则中介绍的无数变化形式，您就能够在每次测试运行时应用许多不同的代码路径。下面是几个关于怎样在测试生命周期内改变测试的示例。

《1》使用重复时，在重新启动或重新连接服务之前，您可以改变重复操作间的时间间隔、重复的次数，或者也可以改变被重复的Web服务的顺序。《2》使用并发，您可以改变一起执行的Web服务、同一时间运行的Web服务数目，或者也可以改变关于是运行许多不同的服务还是运行许多同样的实例的决定。

《3》量级或许是最容易更改的—每次重复测试时都可以更改应用程序中出现的变量（例如，发送各种大小的消息或数字输入值）。如果测试完全随机的话，因为很难一致地重现压力下的错误，所以一些系统使用基于一个固定随机种子的随机变化。这样，用同一个种子，重现错误的机会就会更大。

9_6O6qor%{{y0    一个压力测试通常会结合上述的所有原则，并且在允许的范围内尽可能长时间地运行。测试被允许的执行时间越长，就可以遍历越多的代码路径，并且发现的错误也越多。当然，一旦找到错误就必须诊断并修复它。由于一个代码错误可以在压力测试运行多日以后自己显示出来，所以系统必须保证当出现错误时所有可用的调试信息都被生成—否则可能就必须花费同样多的时间来重现这个错误。

原文转自：http://www.ltesting.net