讲到测试，人们脑海中首先浮现的是针对软件正确性的测试，即常说的功能测试。但是软件仅仅只是功能正确是不够的。在实际开发中，还有许多其它的非功能因素在起着决定性作用。比如软件响应速度，影响软件响应速度的因素很多，有些是因为算法不够高效，有些可能受用户并发数的影响。

在我所负责的测试项目中，程序功能能够满足客户需求，但当把程序交付客户使用时，由于客户网络应用环境复杂，而我们在压力测试时没有周密考虑各种可能发生的情况，软件程序在巨大负载下频繁崩溃，使测试团队饱受客户和老板的抱怨。由此，我认识到随着网络环境的复杂性和多样性，压力测试是软件质量保证的重要元素之一，绝对不能马虎了事。

什么是压力测试？

在软件功能测试中，白盒和黑盒技术用于对正常程序功能和性能进行详尽的检查和测试。而压力测试（Stree Testing）则是用来对付非正常的情况。

（1）什么是压力测试

压力测试是指模拟巨大的工作负荷来测试应用程序在峰值情况下如何执行操作。例如模拟实际软硬件环境，在超出用户常规负荷下，长时间运行测试工具来测试被测系统的可靠性，和测试被测系统的响应时间，目的是在极限负载下识别程序的弱点。

在众多类型的软件测试中，压力测试主要是以软件响应速度为测试目标，尤其是针对在较短时间内大量并发用户访问时软件的抗压能力。因此，压力测试是在一种需要反常数量、频率或资源下运行系统。由于我们之前对“反常”这个关键词没有理解好，只进行了常规的测试，在这一点上客户的批评让我们感到非常汗颜，说我们是“头发长，见识短”。

（2）压力测试和负载测试的区别

在这次项目测试前，我一直对压力测试和负载测试存在着一定程度的混淆。经过这次系统崩溃后，我对压力测试和负载测试的区别有了新的认识。压力测试是在超常规负荷条件下，长时间连续运行系统，检验应用程序的各种性能表现和反应。负载测试是指测试应用程序在常规负荷下，确认响应时间和其它的性能和表现。

实际上，压力测试也是从比较小的负载开始，逐渐增加模拟用户的数量，直到应用程序响应时间超时。压力测试的特点是长时间连续运行，增加超负荷（并发，循环操作，多用户）来测试什么时候系统会产生异常，以及异常处理能力，找出瓶颈所在。现在的我终于明白到其实压力测试实际上就是超常规的负载测试。

（3）压力测试的核心原则

一个有效的压力测试需要遵循一些核心的基本原则，这些原则可以让我们在测试过程中时刻提醒我们压力测试是否还有更多的极端可能。

①重复:最明显且最容易理解的压力原则就是测试的重复。换句话说，重复测试就是一遍又一遍地执行某个操作或功能。功能测试是验证一个操作能否正常执行，而压力测试则是确定一个操作能否在长时间内每次执行时都正常。

②并发:并发是同时执行多个操作的行为。换句话说，就是在同一时间执行多个测试用例。功能测试或单元测试几乎不会与任何并发设计结合。因此，压力系统必须超越功能测试，要同时遍历多条代码路径。

③量级:压力测试另一个重要原则就是要给每个操作增加超常规的负载量。就是说压力测试可以重复执行一个操作，但是在操作自身过程中也要尽量给程序增加负担，增加操作的量级。一般来说，单独的高强度操作重复自身可能发现不了代码错误，但与其他压力测试方法（如并发和量级）结合在一起时，将可以增加发现错误的机会。

④随机:意思是任何压力测试都应该多多少少具有一些随机性。例如随机组合前面三种压力测试原则，然后变化出无数种测试形式，就能够在每次测试运行时应用许多不同的代码路径来进行压力测试。当一个压力测试结合的原则越多，测试执行的时间越长，就可以遍历越多的代码路径，发现的错误也会越多。

压力测试对系统的重要作用

我们对应用程序进行压力测试时经常会出现这种情况，就是测试到了最后却发现不明白测试结果有什么意义？实际上，当我们都不明白压力测试的意义时，我们就不能设计出各种极限测试用例。

压力测试不同于功能测试，软件的正确性并不是它的测试重点，它所看重的是软件的执行效率，尤其是短时间内访问用户数爆炸性增长时软件的响应速度。因此，明白压力测试的作用，对我们高效完成压力测试有至关重要的指导意义。

（1）测试应用程序的可靠性

在系统崩溃后总结之前失败的压力测试时，我忽视的第一个要点就是没有测试出应用程序在压力下的可靠性。压力测试除了对每个单独的组件进行压力测试外，更应该对带有其所有组件和支持服务的整个应用程序进行集中压力测试，以检查在巨大的工作负荷时，应用程序在峰值情况下是否可靠的执行操作。例如，当实际情况是平均每秒出现1个或2个中断的情形下，应当对每秒出现10个中断的情形来进行特殊的测试；又或者把输入数据的量提高一个数量级来测试输入功能是否可靠的响应。从本质上来说，压力测试是想要看在最大极限时程序是否可靠的运行。

（2）测试应用程序的并发性能

进行压力测试需要对实际的并发访问量有一个正确的预期估算，否则在负载远远大于事前预测的压力下系统将脆弱得不堪一击。导致系统崩溃的因素有很多，处理能力、存储速度、响应时间、网络带宽等无论哪部分出现短板拥堵、后果都可能导致全盘崩溃。

现在我明白，哪怕硬件条件达到了，如果软件的并行处理能力不足将会导致等候队列过长，响应时间变慢，系统崩溃也只是时间问题。简单说就是：压力测试是考察当前软硬件环境下系统所能承受的最大并发负荷，并帮助找出软件程序的瓶颈所在。

（3）测试应用程序的最大负载能力

压力测试的目的之一是找出应用程序能够支持的最大客户端数。通过多次的运行和对测试结果中正在运行用户数与错误用户的对比，然后根据可接受错误率就可得到该功能的最大负载访问的用户数。最大负载压力测试用来评估在超越最大负载的情况下系统将如何运行，这时的目标是要发现在高负载的条件下应用程序的缺陷(Bug)，例如内存泄漏等。因此，最大负载能力不但是应用程序一个重要的技术指标，也是客户评估和验收软件的一个关键指标。

如何进行高效的压力测试？

软件测试有两句通俗的话：开发是尽可能地让程序通过；而测试则是尽可能地让程序通不过。对于压力测试而言，测试效果好不好，测试计划的好坏是关键。所以，针对不同的情况，分析后有针对的进行测试，比起拿枪乱打、无的放矢显然要高效得多。

进行一次切实可行的压力测试并不像乍看之下那么简单，遇到的问题也可能非常微妙。例如，我的测试团队就经常遇到诸如“客户端每小时将要处理100个客户订单请求”等此类的需求，于是测试团队就试图把该需求转化为某种测试需求，执行这种测试需求的常见方法就是以死循环的形式对服务器进行反复请求，然后静观其效。然而，通常事情进行得并不顺利，原因在于这只是把需求表面化了，没有分析出测试需求的本质。高效的压力测试应遵循以下这几个步骤：

（1）确定测试目标

在确定压力测试目标中，我们要定义测试的对象，并对每一个测试对象给出清晰说明，也要定义测试结束的目标。为控制测试的有效性以及完成程度，必须定义准则和策略。准则必须是客观的，可量化的，而不能是经验或感觉。例如压力测试目标可能是测定终端用户处理事务的响应时间，它可能随用户的增加而增加，但要定义一个可接受时间。在确定压力测试目标过程中，最好能邀请客户、设计人员等一同对测试目标进行评审。

（2）制定压力测试计划

测试计划内容包括：定义测试资源、制定测试进度表、选择测试工具等。制定测试计划的目的是使压力测试有章可循并得到人力、物力等各方面的保证；在制定测试进度表时应考虑和开发进度相互协调；对于测试工具的选择应以满足测试目标为前提。所以，这并不是说测试工具提供的功能越多就越好，在实际的选择过程中适用才是根本。

（3）编写测试案例和设置测试数据

测试人员一般是根据测试案例进行实际的测试工作，因此测试案例的编写应做到客观全面、重点突出，也就是要求编写的测试案例应该尽可能模拟真实的负荷，不遗漏重要的测试内容。为了让所有的测试顺利执行，可采取数据驱动方式进行，同时应该对测试数据进行参数化。另外，一般不提倡在开发环境中进行压力测试，最好是另外构建测试环境。

（4）结果分析及测试报告

压力测试运行结束后，应把所有的数据汇总并记录到文件中，以方便对测试结果进行分析和得出结论。若测试失败，应先分析失败原因，如果是软件系统造成的，应返回给设计人员修改。如果测试结果不满足预期需求，应先对软件程序进行优化调理，然后再次运行测试，直到可以满足预期需求或调整已无法改善结果。

最后需要注意的是测试报告。报告应包括测试提要、测试环境和测试结果。提要应简单说明测试方法、策略、范围、内容；测试环境应包括资源开销、环境配置等；测试结果必须包括测试是否通过或拒绝，并要对测试结论进行说明，并对软件程序的性能做出评价。