Web 服务处于分布式计算的核心位置，它们之间的交互通常很难测试。分布式开发、大型的开发者团队以及对代码日益组件化的期望都有可能使 Web 服务的开发变得越来越容易隐藏错误。这些类型的错误极难检测出来。压力测试是检测这类代码错误的一种有效方法，但是只有在压力系统设计得比较有效的情况下 才能发挥作用。本文将让您深入了解一下这种压力系统的基本要求。
传统的测试方法包括某种形式的简单 单元测试 ，通常由开发人员执行。设计这些测试需要了解软件的内部知识，并且这些测试几乎总是针对产品的非常小的、特定的部分。这些类型的测试非常适合与其他代码组件极少交互，甚至没有交互的简单 Web 服务。
功能验证（Functional Verification） 也 是一种测试过程，在这个过程中，对产品源代码了解有限的设计者进行测试以确认产品或服务的核心功能。设计这种测试是为了证明这个核心功能符合某个规范。举 个例子，我的在线拍卖显示的是输入的正确出价吗？ 我的保险经纪人系统找到最便宜的报价了吗？如果这些测试失败，通常就意味着检测到了产品的一个基本问题（这个问题通常是可以直接修复）。这种测试也是适合 简单的 Web 服务，使您可以检查服务是否能够正确执行它的各个功能。
系统测试（System Test） 通常是在功能验 证阶段完成，验证了核心功能后进行。它倾向于把整个系统作为一个整体来查找问题 — 弄清 Web 服务作为系统的一部分怎样运作，以及 Web 服务相互之间如何交互。由于系统测试是在开发生命周期快结束时才进行，所以通常不能给它分配足够的时间来完成。又因为紧张的发行日程安排以及开发的各个重 要阶段的后移，系统测试阶段经常被忽略，并且一些通常都可以发现的、少见的错误都不能被检测到。即使发现了这种错误，这时也来不及确定错误的原因并设法修 复它们了。因此，在查找代码错误时，必需把系统测试应用设计得尽可能高效。系统测试通常由三部分组成，它们是：
性能（Performance）： 这涉及到确定相关的产品统计数据的过程。例如：每秒有多少条消息？一个服务可同时接受多少个用户？
案例（Scenario）： 这是重新创建客户所需的确切配置的过程。因此在案例中发现的任何问题都可以在客户使用该产品之前被检测出来。
压力（或称工作负载平衡）： 它 与另两个部分不同，因为它被设计为通过应用很大的工作负载来使软件超负荷运转。如果压力测试通过对产品保持高强度的使用（但不超过性能统计数字确定的限 制）能有效地执行，那么它就经常能够发现许多隐蔽的错误，而这些错误用上面提到的任何其他技术都是发现不了的（这些错误也经常是最难修复的）。
从检测代码错误这方面来说，可以证明这三个系统测试组件中效率最高的是 压力测试 部分。但由于这个过程经常跟系统的其他要素或功能测试混淆在一起，所以这个过程涉及到的方法还没有被正确着手处理或实现。
压力下的错误
使用压力测试，您有希望找到很多种用其他测试方法更难发现的错误。有两种错误类型是：
内存泄漏（Memory leak）： 一种极难检测的现象。内存泄漏经常发生在已发行的产品中，原因很简单，很难设计测试 用例来检测它们。使用简单的功能测试，几乎发现不了内存泄漏问题，因为在产品完成之前测试没对产品进行足够多的使用。内存泄漏通常要求操作要重复非常多的 次数以使内存消耗达到能引起注意的程度。尽管与其它编程语言（如 C/C++）相比，Java 程序更难引入内存泄漏错误，但只要程序仍保持着对对象的引用，该对象仍有可能被实例化并且它占用的内存永远不会被释放。
并发与同步（Concurrency and Synchronization）： 压 力测试在查找并发性问题上非常出众，这是因为在任何一个测试生命周期中，它都应用了许多不同的代码路径和定时条件。一般的规则是，压力测试运行的时间越 长，涉及并应用的代码路径组合和定时条件就越多。当然，这也的确使得这些问题很难再现（错误可以在 5 分钟或 5 天后发生）。死锁、线程泄漏以及任何一般的同步问题通常只能在压力测试阶段被检测出来。这些类型的问题很难通过执行单元测试来发现。开发人员不会一直考虑 他或她的代码将与其他地方的代码（在执行单元测试时这些代码可能还没写出来）进行交互。
现有的压力测试工具
文章来源于领测软件测试网 https://www.ltesting.net/