在面试测试人员的时候，这是一个很好的问题：你如何定义性能/负载/压力测试?在很多时候，人们都是将它们作为可互相替换的相同术语来使用，然而实际上他们之间的差异是比较大的。这个贴子是根据我自己的一些经验，针对这三个概念写的一个比较简单的评论，当然也同时参考了一些测试文献资料里的定义，比如说：

　　"Testing computer software" by Kaner et al

　　"Software testing techniques" by Loveland et al

　　"Testing applications on the Web" by Nguyen et al

　　Update July 7th， 2005

　　从网站的访问日志中我可以看到这篇贴子经常会被人们在GOOGLE中搜索到，所以我在这里加上一个我写的一个后续贴子的地址连接‘More on performance vs. load testing‘.

　　性能测试

　　性能测试的目的不是去找bugs，而是排除系统的瓶颈，以及为以后的回归测试建立一个基准。而性能测试的操作，实际上是一个非常小心受控的测量分析过程。在理想的情况下，被测软件在这个时候已经是足够稳定了，所以这个过程得以顺利的进行。

　　一组清晰已定义好的预期值是让一次有意义的性能测试的基本要素。如果连你自己都不知道系统性能有些什么是要测的，那么它对于你要测试的方法手段是没有指导意义的*。例如，给一个web应用做性能测试，你要知道至少两样东西：

　　在不同并发用户数或者HTTP连接数情况下的负载预期值*

　　可接受的响应时间

　　当你知道你的目标后，你可以开始使用对系统持续增加负载的方法来观察系统的瓶颈所在。重新拿web应用系统来做例子，这些瓶颈可存在于多个层次，你可以使用多种工具来查明它们的所在：

　　在应用层，开发人员可以通过profilers来发现低效率的代码，比如说较差的查找算法

　　在数据库层，开发人员和数据库管理员(DBA)可以通过特定的数据库profilers及事件探查器(query optimizers)

　　在操作系统层，系统工程师可以使用一些工具如在Unix类的操作系统中的top，vmstat，iostat，在Windows系统中的PerfMon来监控CPU，内在，swap，磁盘I/O等硬件资源;专门的内核监控软件也可以在这一层面上被使用。

　　在网络层上，网络工程师可以使用报文探测器(如tcpdump)，网络协议分析器(如ethereal)，还有其它的工具(如netstat，MRTG，ntop，mii-tool)

　　从测试的观点来看，上面所有描述的活动都是一种白盒的方法，它对系统从内到外及多角度进行审查及监控。测度数据*被取得及分析后，对系统的调整则成为理所当然的下一个步骤。

　　然而，(除了上面的方法外)测试人员在给被测系统运行负载试验*(这里为了不与我们所理解的负载测试-load testing的概念搞混，特译做负载试验)的时候，也采取了黑盒的方法。像对于WEB应用来讲，测试人员可以使用工具来模拟并发用户或者HTTP连接及测量响应时间。在我以前使用过的轻量级的负载测试开源工具有ab，siege，httperf。一个更重量级的工具是OpenSTA，但我没用过。我也还没有用过The Grinder这个工具，但它在我将要做的事情中排名靠前。

　　当负载试验*的结果显示出系统的性能来没有达到它的预期目标时，这是要对应用和数据库的调整的时候了。同时你要确保让你的代码运行得尽可能高效，以及数据库在给定的操作系统和硬件配置的情况下优化。测试驱动开发(TDD)的实践者会发现这种上下文结构框架是非常有用的*，如可以通过负载试验*及时间试验的函数性*来增强现存单元测试代码的Mike Clark的jUnitPerf*。当一个特定的函数或者方法被剖析过*和调试过后，开发人员可以在jUnitPerf中，放入它的单元试验*来确保它可以达到负载及时间上的性能需求。Mike Clark称这为“持续性能测试”。我顺便也提一下我已经做了一个基于Python的jUnitPerf的初步研究，我称之为pyUnitPerf.