性能测试种类的划分与定义这里不说了，各有各的说法，比如性能测试、负载测试、压力测试这三个词，在网上能找到N个版本的定义，大体理解行了，没必要在文字层面上较这个真。以下的内容也只是我个人的理解，一些名词的定义可能和其他资料有所不同，但在我的工作中，这样是比较形象和容易理解的。

　　性能测试的目的，简单说其实是为了获取待测系统的响应时间、吞吐量、稳定性、容量等信息。而发现一些具体的性能相关的缺陷（如内存溢出、并发处理等问题），我认为只是一种附加结果。从更高的层次来说，性能测试想发现的，是瓶颈。

　　在实际工作，一般的应用系统会从这么几个方面进行性能测试。

　　1、基准测试

　　Benchmark或者Baseline测试。一般为单用户测试，或者是零数据量环境下的测试。目的在于建立一个可度量的参考标准，为其他测试场景或者调优过程提供对比参考。也可认为是基础的性能测试，如果基准测试的结果都不能达到预期要求，那么后续场景也没必要测试了。

　　2、日常压力测试

　　在基准测试通过后，应该先进行较小压力下的测试，首先对系统在日常压力下的表现进行测试。此压力需要根据系统使用相关数据得出，如系统平均每天访问量、平均在线人数、每日完成事务数等。通过此测试，发现一些较表面的性能问题并进行处理。

　　3、峰值压力测试

　　在日常压力测试通过后，需要进行更大压力的测试。此处压力同样需要相关数据的支持，一般为未来几年后的预期压力。可根据历史日均压力、日高压力等信息，估算出未来几年的日均以及日高压力。再通过一些通用估算方法、如二八原则（80%的工作在20%时间内完成，相当于2小时完成8小时的工作量），将日压力转换成峰值压力。

　　峰值压力为可预期到的大负载压力，通过了此测试，则认为系统有能力满足未来增长的压力。

　　4、容量测试

　　验证了系统是否可满足预期的压力后，还需要知道系统能够承受的大压力，也是容量。一般通过“拐点法”进行测试，逐步增大系统的压力，直到性能指标不可接受或者出现了明显的拐点。如图：

　　5、稳定性测试

　　验证系统是否可长期稳定的运行，是否存在一些短时间内可能无法发现的缺陷（如内存溢出、数据库连接不释放等）。为了缩短测试工期，一般可将预期的压力集中在2小时内完成（二八原则），这样持续加压10小时，便相当于系统运行5天。注意监控各种性能指标是否平稳，有无下降。

　　以上几种类型的测试，是性能测试过程中多用到的。当然也也其他一些比较常用的类型，如并发测试，测试多用户对某一功能的瞬时请求，主要用于验证系统是否存在并发逻辑上的处理问题。此测试也可划分到不同的压力测试场景中去，根据不同的用户压力，测试相应的并发，一般取在线用户数的10%进行测试；突发压力测试，对一些不在预期内的突然压力进行测试（其实既然想到了，应该是在预期内了）。以银行门户网站为例，可能会由于发布了一条重要消息（政策调整）而导致访问量激增，这种压力是否会导致系统宕机或者暂时无法提供服务，是突发压力测试需要考虑的了。也有人将此压力定义为峰值压力，这无所谓了，只要考虑到会有这么一个问题够了。

　　上面主要说的是测试内容的划分，也是说做性能测试时要考虑到的几个方面。从实际执行层面来看，测试的过程一般分为这么几个阶段：

　　1、测试确认

　　理解被测系统、寻找测试点、确认测试范围、测试环境等。一些重要信息需要同PM、需求人员、设计人员讨论确认，如用户常用哪些功能、关注哪的性能，程序上哪可能是压力点，哪些数据需要模拟到真实的量级，大体上需要使用哪种测试方法。

　　2、确定通过标准

　　性能是好是坏、测试是否通过，必须有明确的标准。这个标准，主要从客户的期望和业务上的需求两方面来考虑，客户的期望一般指页面上的响应时间，业务需求则是系统的处理能力，一般为吞吐量或TPS（每秒完成事务数）。标准制定的不合理，测试结果可能无法反映系统真实的性能表现，或者会让客户无法接受我们认为通过的软件。

　　至于具体如何去设定，是需要同业务负责人（一般为PM）和技术负责人（一般为设计人员）共同确认的，业务负责人了解用户的实际需求和期望，技术负责人了解具体的实现，可以判断哪些是不可达到的要求。

　　一旦达成了共识，那么测试要严格的按照标准去执行。