本文主要针对WEB系统的性能测试。不涉及具体的执行操作，只是本人对性能测试的一点理解和认识。
性能测试的目的，简单说其实就是为了获取待测系统的响应时间、吞吐量、稳定性、容量等信息。而发现一些具体的性能相关的缺陷（如内存溢出、并发处理等问题），我认为只是一种附加结果。从更高的层次来说，性能测试最想发现的，是瓶颈。如何能得到所需要的信息，就需要从多方面进行测试。
性能测试的内容
性能测试种类的划分与定义这里就不说了，各有各的说法，比如性能测试、负载测试、压力测试这三个词，在网上能找到N个版本的定义，大体理解就行了，没必要在文字层面上较这个真。以下的内容也只是我个人的理解，一些名词的定义可能和其他资料有所不同，但在我的工作中，这样是比较形象和容易理解的。
在实际工作，一般的应用系统会从这么几个方面进行性能测试。
1.基准测试
Benchmark或者Baseline测试。一般为单用户测试，或者是零数据量环境下的测试。目的在于建立一个可度量的参考标准，为其他测试场景或者调优过程提供对比参考。也可认为是最基础的性能测试，如果基准测试的结果都不能达到预期要求，那么后续场景也就没必要测试了。
2.日常压力测试
在基准测试通过后，应该先进行较小压力下的测试，首先对系统在日常压力下的表现进行测试。此压力需要根据系统使用相关数据得出，如系统平均每天访问量、平均在线人数、每日完成事务数等。通过此测试，发现一些较表面的性能问题并进行处理。
3.峰值压力测试
在日常压力测试通过后，需要进行更大压力的测试。此处压力同样需要相关数据的支持，一般为未来几年后的预期压力。可根据历史日均压力、日最高压力等信息，估算出未来几年的日均以及日最高压力。再通过一些通用估算方法、如二八原则（80%的工作在20%时间内完成，相当于2小时完成一天8小时的工作量），将日压力转换成峰值压力。
峰值压力为可预期到的最大负载压力，通过了此测试，则认为系统有能力满足未来增长的压力。
4.容量测试
验证了系统是否可满足预期的压力后，还需要知道系统能够承受的最大压力，也就是容量。一般通过“拐点法”进行测试，逐步增大系统的压力，直到性能指标不可接受或者出现了明显的拐点。如下图，拐点在哪？
5.稳定性测试
验证系统是否可长期稳定的运行，是否存在一些短时间内可能无法发现的缺陷（如内存溢出、数据库连接不释放等）。为了缩短测试工期，一般可将预期一天的压力集中在2小时内完成（二八原则），这样持续加压10小时，便相当于系统运行5天。注意监控各种性能指标是否平稳，有无下降。
以上几种类型的测试，是性能测试过程中最多用到的。当然也也其他一些比较常用的类型，如绝对并发测试，测试多用户对某一功能的瞬时请求，主要用于验证系统是否存在并发逻辑上的处理问题。此测试也可划分到不同的压力测试场景中去，根据不同的用户压力，测试相应的绝对并发，一般取在线用户数的10%进行测试；突发压力测试，对一些不在预期内的突然压力进行测试（其实既然想到了，就应该是在预期内了）。以银行门户网站为例，可能会由于发布了一条重要消息（政策调整）而导致访问量激增，这种压力是否会导致系统宕机或者暂时无法提供服务，就是突发压力测试需要考虑的了。也有人将此压力定义为峰值压力，这就无所谓了，只要考虑到会有这么一个问题就够了。
性能测试的阶段
上面主要说的是测试内容的划分，也就是说做性能测试时要考虑到的几个方面。从实际执行层面来看，测试的过程一般分为这么几个阶段：
1.测试确认
理解被测系统、寻找测试点、确认测试范围、测试环境等。一些重要信息需要同PM、需求人员、设计人员讨论确认，如用户最常用哪些功能、最关注哪的性能，程序上哪可能是压力点，哪些数据需要模拟到真实的量级，大体上需要使用哪种测试方法。
2.确定通过标准
性能是好是坏、测试是否通过，必须有明确的标准。这个标准，主要从客户的期望和业务上的需求两方面来考虑，客户的期望一般指页面上的响应时间，业务需求则是系统的处理能力，一般为吞吐量或TPS（每秒完成事务数）。标准制定的不合理，测试结果可能无法反映系统真实的性能表现，或者会让客户无法接受我们认为通过的软件。
至于具体如何去设定，是需要同业务负责人（一般为PM）和技术负责人（一般为设计人员）共同确认的，业务负责人了解用户的实际需求和期望，技术负责人了解具体的实现，可以判断哪些是不可达到的要求。
一旦达成了共识，那么测试就要严格的按照标准去执行。
3.测试设计
主要从上面提到的几个方面进行分析，针对系统的特点设计出合理的测试场景。为了让测试结果更加准确，这里需要很细致的工作。如建立用户模型，只有知道真实的用户是如何对系统产生压力，才可以设计出有代表性的压力测试场景。这就涉及到很多信息，如用户群的分布、各类型用户用到的功能、用户的使用习惯、工作时间段、系统各模块压力分布等等。只有从多方面不断的积累这种数据，才会让压力场景更有意义。最后将设计场景转换成具体的用例。
测试数据的设计也是一个重点且容易出问题的地方。生成测试数据量达到未来预期数量只是最基础的一步，更需要考虑的是数据的分布是否合理，需要仔细的确认程序中使用到的各种查询条件，这些重点列的数值要尽可能的模拟真实的数据分布（数据统计信息、执行计划相关的内容，此处就不细说了），否则测试的结果可能是无效的。
此外，性能测试执行过程中，需要监控收集的各种指标数据，也需要明确下来。
4.测试环境准备
部署测试环境，生成测试数据，环境预调优等等。预调优指根据系统的特点和自己的经验，提前对系统的各个方面做一些优化调整，避免测试执行过程中的无谓返工。比如一个高并发的系统，10000人在线，连接池和线程池的配置还用默认的，显然是会测出问题的。
5.测试执行、监控
准备测试脚本，执行之前设计好的各个用例，监控并收集需要的数据。出现问题时，切记要全面的保留事故现场、或者是能进行分析的数据。比如TOMCAT不再响应，不能只把这个现象记录下来，这对问题的排查定位是没有意义的，要保留所有相关的日志，导出线程转储和堆转储。
6.问题分析定位、调优
发现问题或者性能指标达不到预期，及时的分析定位，处理后重复测试过程。
性能问题通常是相互关联相互影响的，表面上看到的现象很可能不是根本问题，而是另一处出现问题后引起的反应。这就要求监控收集数据时要全面，从多方面多个角度去判断定位。
调优的过程其实也是一种平衡的过程，在系统的多个方面达到一个平衡即可。
7.性能报告
将测试过程中记录的各种数据汇总成报告，将各方面需要的结果清楚的展现出来。
上面所有内容中，如果排除技术上的问题，性能测试中最难做好的，就是用户模型（或者叫系统使用模型）的分析。它直接决定了压力测试场景是否能够有效的模拟真实世界压力，而正是这种对真实压力的模拟，才使性能测试有了更大的意义。可以说，性能测试做到一定程度，差距就体现在了模型建立上。
至于性能问题的分析、定位或者调优，很大程度是一种技术问题，需要多方面的专业知识。数据库、操作系统、网络、开发都是一个合格的性能测试人员需要拥有的技能，只有这样，才能从多角度全方位的去考虑分析问题。
当然，对于测试人员来说，技术能力只能排在第二号，测试思想才是最根本的。敏锐的嗅觉、严谨的逻辑、合理的推测、大胆的实践是一个合格测试工程师的必备要素。
模拟演练
写了一大堆，新手还是不知道如何去做。其实写本文的目的也不是讲具体操作，而是思想，思想。新手学性能测试，建议找一本从LOADRUNNER开讲的书比较好。如51TESTING上有连载的《性能测试从零开始》。
不过还是尽量说点具体些的内容吧。
普通BS架构的系统，一般都采用测试工具（如LR）直接录制手工操作的方式进行测试。这种方式简单有效，对测试人员要求不高。但在一些情况下，这种基于录制的方法可能无法完成，比如页面上有特殊控件、系统是CS架构、或者通讯的协议无法捕获等。这时就需要更复杂的测试方法，如手动编写模拟客户端的JAVA代码，而把测试工具当作一个调度控制台，去调度大量的虚拟用户线程执行编写好的代码。
现在假设有一个简易版的12306网站，JAVA实现，中间件为TOMCAT，数据库为SYBASE，没有集群处理（一切从简，只有查询和订票功能）。如何对它进行性能测试呢？
按照上面的几个步骤来想一想吧，这里只简单写几点。
第一步，测试确认。海量并发，数据也应该是海量的，但基本都是简单查询，没有复杂的统计，所以主要困难还是在海量并发事务的处理上。中间件、数据库上都会承受巨大压力。此类高并发系统还需要对一些功能特别注意，比如一个车次有10张票，5个人同时购票，如何处理？如果是12个人同时点购票，又是如何处理？
第二步，通过标准。无非是系统能够满足多少人同时在线，一分钟内能处理多少订单，用户最大等待时间是几分钟。注意这个标准一定要是经过各方面确认过实际可行的啊，定一个订单响应时间不超过5秒有意义么？确认了以后，就要按着这个目标来设计测试和执行。
另一个需要注意的问题，按照预期的压力测试通过了以后，是不是就高枕无忧了？答案是否定的，因为很可能这个预期或者标准是不合理的，这个是非常可能的，只有长期的数据积累，才会一点点走向精确。想想奥运订票系统，开通后短短五分钟，网站就瘫痪了，你们以为这种系统没有经过专业的性能测试么？据我所知，奥运订票系统性能测试时制定的标准是每分钟处理四百万访问（具体数据记不住了，就假设是这个数吧），出事后的检查发现，每分钟的访问量超过了八百万。这种事故责任在谁呢？测试机构敢拍胸脯保证，每分钟处理四百万就是没问题的。而奥组委自己设定的每分钟四百万目标，和实际出现偏差也是正常的，毕竟这种系统是第一次上线。最后的处理方法就是，压力达到了预期最大值以后，再后来的访问就被排队了。好好体会这个案例吧，会有收获的。
第三步，测试设计。设计用户模型，设计测试场景，设计测试用例。一个典型的用户是如何使用系统的？登录、查询车次余票、订票、付款，这是理想化的情况。实际更可能是这样的，登录（一次登不进去，重复多次）、查询A车次（未到放票时间、不断重试，时间到无票）、查询B车次（无票）、查询C车次（有票）、订票、付款、查询订单。两种交互方式对系统产生的压力，差别是很大的。
将多个用户行动整合到一起，也就是用户模型，或者叫系统使用模型，是压力场景设计的依据。假设系统一天的访问量是一万个用户，这一万访问量是在24小时内平均分布的，还是分布在8小时内，还是在某一时间点上集中访问？这些具体到用例中也就是虚拟用户的加载策略，直接决定了压力的大小。
除了这个压力场景，针对此系统还需要进行绝对并发测试，参考第一步的分析。
第四、五步就不细说了，准备环境、数据，针对大量用户的并发进行一些预调优。按照第三步设计好的各个测试用例准备脚本、执行测试。
第六步，发现问题了怎么办？比如1000人的压力下，系统响应就比较慢了，查询车次需要1分钟，下订单需要2分钟，接下来要做什么？能把这些作为一个性能缺陷提起么？显然是不可以的，这只是通过你的压力测试场景产生的一个现象，可能是测试脚本有问题、也可能是测试环境有问题。作为一个性能测试人员，需要尽量深入的定位到问题产生的原因。就像这个响应慢，只是一个表面现象，慢在哪？是中间件还是数据库？一些简单的测试方法就可以进行判断，如在页面上进行一些数据库无关的操作，如果依然比较慢，说明在中间件上压力就已经比较大了。还可以部署另一套中间件测试环境，连接之前相同的数据库，在压力测试出现问题的同时，手动访问新部署的应用（只有一个用户），如果同样很慢，那说明慢在了数据库端的处理上。还可以通过日志的方式更准确的进行判断，如应用日志和数据库SQL执行日志。总之方法是多种多样的，但目的只有一个，就是不断的排除无关部分、缩小问题范围。
定位到了中间件和数据库之一，然后又该怎么办？此时恐怕就需要一些相关方面的专业知识了，但其实最常见的还是那些。中间件相关的一般是线程池、JVM、数据库连接池等，数据库相关的有锁、缓存、IO（一般就是SQL语句的问题）等。要进行全面的监控和分析，再做一些合理的调优并重复测试。
问题定位到什么程度才行？我认为是要让人看了知道改哪就可以了。比如提一个“这个SQL语句进行了大量的物理IO，性能不好”，这就不是个好问题，物理IO是什么？怎么改？如果这么说就好多了“这个SQL语句没有使用索引，导致了全表扫描，进行了大量的物理IO，性能不好。如果要避免全表扫描，需要调整SQL语句或者添加XX索引”，这才是定位问题。
当然了，上面只是一个非常简陋的举例，真实的性能测试要比这复杂的多。
总的来说，我认为，性能测试的难度主要不在技术手段上，互联网时代技术都是共享的，要善于去搜索利用他人的成果。即使自己搞不定，团队内一定还有专业的开发工程师、数据库管理员、系统管理员可以帮你搞定。真正的难点在于，你要想出来如何去测是有效的、有保障的，这才是测试工程师最重要的能力。
还是那个观点，思想才是根本。