在通常的软件生产周期中，先由用户提出用户需求或经系统分析核定以后提出系统需
求，开发人员再经过需求分析提出软件需求规格说明，进行概要设计，提出概要设计说明，
进行详细设计，提出详细设计说明，最后就是对每个模块进行编码。到测试阶段，测试按照
开发过程逐阶段进行验证并分步实施，体现了从局部到整体、从低层到高层逐层验证系统的
思想。对应软件开发过程，软件测试步骤分为代码审查、单元测试、集成测试、系统测试。
而性能测试就属于软件系统级测试，其最终目的是验证用户的性能需求是否达到，在这
个目标下，性能测试还常常用来做：
（1）识别系统瓶颈和产生瓶颈的原因；
（2）最优化和调整平台的配置（包括硬件和软件）来达到最高的性能；
（3）判断一个新的模块是否对整个系统的性能有影响。
典型的分布式系统架构：如图
如果把软件系统看作是交通系统，那么网络就是一条条大道，客户端、防火墙、负载均
衡器、Web 服务器、应用服务器（中间件）、数据库等各个系统节点就是交通要塞，客户的
请求和数据就像在道路上行驶的车辆，如果在某处发生堵车，那么整个交通系统都会不畅。
在 这个时候，我们就要分析是哪里出了问题，是道路不够宽，还是某处立交桥设计不合理
而引起堵塞等。找到问题的关键点，那么此关键点就是本系统的瓶颈。软件系统也是如此，
我们做性能测试的大部分工作都是为了寻找这个瓶颈到底在何处。
1．性能测试不是功能测试
性能测试不要求也无法做到覆盖软件所有的功能，通常我们只是对系统中某些功能或模
块做性能测试。一般的，我们在选择性能测试案例时需要遵循以下的原则：
（1）基本且常用的
比如，一个 E-mail 系统，基本且常用的功能有注册、登录、收邮件、查询邮件，用户
使用这些功能的频率较高，要做性能测试。而高级查询、过滤器、邮件列表等功能被使用的
次数较少，就可以不做性能测试，或者进行性能测试的优先级低一些。
（2）对响应时间要求苛刻的
这样的要求经常出现在金融和电信等对实时性要求比较高的系统中。比如，从手机呼叫
开始，经过基站、核心网，再到被叫手机响铃，整个系统的处理时间应该在用户能接受的范
围内。另外，一个负责和手机通信的基站在发生故障或掉电后，要能很 快地恢复工作状态。
这些功能都对时间有着严格的要求，一定要做性能测试，当然实际运作时，电信系统上线时
所做的性能测试不仅仅限于这些功能。
将这些功能细分就是性能测试中的事务（Transaction）。
常见的性能测试方法有以下几种：
1．负载测试
在这里，负载测试指的是最常见的验证一般性能需求而进行的性能测试，在上面我们提
到了用户最常见的性能需求就是“既要马儿跑，又要马儿少吃草”。因此负载测试主要是考察
软件系统在既定负载下的性能表现。我们对负载测试可以有如下理解：
（1）负载测试是站在用户的角度去观察在一定条件下软件系统的性能表现。
（2）负载测试的预期结果是用户的性能需求得到满足。此指标一般体现为响应时间、
交易容量、并发容量、资源使用率等。
2．压力测试
压力测试是为了考察系统在极端条件下的表现，极端条件可以是超负荷的交易量和并发
用户数。注意，这个极端条件并不一定是用户的性能需求，可能要远远高于用户的性能需求。
可以这样理解，压力测试和负载测试不同的是，压力测试的预期结果就是系统出现问题，而
我们要考察的是系统处理问题的方式。比如说，我们期待一个系统在面临压力的情况下能够
保持稳定，处理速度可以变慢，但不能系统崩溃。因此，压力测试是能让我们识别系统的弱
点和在极限负载下程序将如何运行。
例子：负载测试关心的是用户规则和需求，压力测试关心的是软件系统本身。对于它们
的区别，我们可以用华山论剑的例子来更加形象地描述一下。如果把郭靖看作被测试对象，
那么压力测试就像是郭靖和已经走火入魔的欧阳峰过招，欧阳锋蛮打乱来，毫无套路，尽可
能地去打倒对方。郭靖要能应对住，并且不能丢进小命。而常规性能测试就好比郭靖和黄药
师、洪七公三人约定，只要郭靖能分别接两位高手一百招，郭靖就算胜。至于三百招后哪怕
郭靖会输掉那也不用管了。他只要能做到接下一百招，就算通过。
思考
我们在做软件压力测试时，往往要增加比负载测试更多的并发用户和交易，这是为什
么？
3．并发测试
验证系统的并发处理能力。一般是和服务器端建立大量的并发连接，通过客户端的响应
时间和服务器端的性能监测情况来判断系统是否达到了既定的并发能力指标。负载测试往往
就会使用并发来创造负载，之所以把并发测试单独提出来，是因为并发测试往往涉及服务器
的并发容量，以及多进程/多线程协调同步可能带来的问题。这是要特别注意，必须测试的。
4．基准测试
当软件系统中增加一个新的模块的时候，需要做基准测试，以判断新模块对整个软件系
统的性能影响。按照基准测试的方法，需要打开/关闭新模块至少各做一次测试。关闭模块
之前的系统各个性能指标记下来作为基准（Benchmark），然后与打开模块状态下的系统性
能指标作比较，以判断模块对系统性能 的影响。
5．稳定性测试
“路遥知马力”，在这里我们要说的是和性能测试有关的稳定性测试，即测试系统在一定
负载下运行长时间后是否会发生问题。软件系统的有些问题是不能一下子就暴露出来的，或
者说是需要时间积累才能达到能够度量的程度。为什么会需要这样的测试呢？因为有些软件
的问题只有在运行一天或一个星期甚至更长的时间才会暴露。这种问题一般是程序占用资源
却不能及时释放而引起的。比如，内存泄漏问题就是经过一段时间积累才会慢慢变得显著，
在运行初期却很难检测出来；还有客户端和服务器在负载运行一段时间后，建立了大量的连
接通路，却不能有效地复用或及时释放。
6．可恢复测试
测试系统能否快速地从错误状态中恢复到正常状态。比如，在一个配有负载均衡的系统
中，主机承受了压力无法正常工作后，备份机是否能够快速地接管负载。可恢复测试通常结
合压力测试一起来做。
提示：每种测试有其存在的空间和目的。当我们接手一个软件项目后，在有限的资源条
件下，选择去做哪一种测试，这应该根据当前软件过程阶段和项目的本身特点来做选择。比
如，在集成测试的时候要做基准测试，在软件产品每个发布点要做性能测试。