性能测试浅谈

一月蔷薇_456

本文主要针对WEB系统的性能测试。不涉及具体的执行操作，只是本人对性能测试的一点理解和认识。

　　性能测试的目的，简单说其实就是为了获取待测系统的响应时间、吞吐量、稳定性、容量等信息。

而发现一些具体的性能相关的缺陷（如内存溢出、并发处理等问题），我认为只是一种附加结果。

从更高的层次来说，性能测试最想发现的，是瓶颈。如何能得到所需要的信息，就需要从多方面进

行测试。

　　性能测试的内容

　　性能测试种类的划分与定义这里就不说了，各有各的说法，比如性能测试、负载测试、压力测

试这三个词，在网上能找到N个版本的定义，大体理解就行了，没必要在文字层面上较这个真。以

下的内容也只是我个人的理解，一些名词的定义可能和其他资料有所不同，但在我的工作中，这样

是比较形象和容易理解的。

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

　　1.基准测试
　　Benchmark或者Baseline测试。一般为单用户测试，或者是零数据量环境下的测试。目的在

于建立一个可度量的参考标准，为其他测试场景或者调优过程提供对比参考。也可认为是最基础的

性能测试，如果基准测试的结果都不能达到预期要求，那么后续场景也就没必要测试了。

　　2.日常压力测试
　　在基准测试通过后，应该先进行较小压力下的测试，首先对系统在日常压力下的表现进行测试。

此压力需要根据系统使用相关数据得出，如系统平均每天访问量、平均在线人数、每日完成事务数

等。通过此测试，发现一些较表面的性能问题并进行处理。

　　3.峰值压力测试
　　在日常压力测试通过后，需要进行更大压力的测试。此处压力同样需要相关数据的支持，一般

为未来几年后的预期压力。可根据历史日均压力、日最高压力等信息，估算出未来几年的日均以

及日最高压力。再通过一些通用估算方法、如二八原则（80%的工作在20%时间内完成，相当于

2小时完成一天8小时的工作量），将日压力转换成峰值压力。
　　峰值压力为可预期到的最大负载压力，通过了此测试，则认为系统有能力满足未来增长的压力。

　　4.容量测试
　　验证了系统是否可满足预期的压力后，还需要知道系统能够承受的最大压力，也就是容量。一

般通过“拐点法”进行测试，逐步增大系统的压力，直到性能指标不可接受或者出现了明显的拐点。

如下图，拐点在哪？

一月蔷薇_456

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秒有意义么？确认了以后，就要按着这个目标来设计测试和执行。

　　另一个需要注意的问题，按照预期的压力测试通过了以后，是不是就高枕无忧了？答案是

否定的，因为很可能这个预期或者标准是不合理的，这个是非常可能的，只有长期的数据积累，

才会一点点走向精确。想想奥运订票系统，开通后短短五分钟，网站就瘫痪了，你们以为这种

系统没有经过专业的性能测试么？据我所知，奥运订票系统性能测试时制定的标准是每分钟处

理四百万访问（具体数据记不住了，就假设是这个数吧），出事后的检查发现，每分钟的访问

量超过了八百万。这种事故责任在谁呢？测试机构敢拍胸脯保证，每分钟处理四百万就是没问题

的。而奥组委自己设定的每分钟四百万目标，和实际出现偏差也是正常的，毕竟这种系统是第一

次上线。最后的处理方法就是，压力达到了预期最大值以后，再后来的访问就被排队了。好好体

会这个案例吧，会有收获的。

一月蔷薇_456

　第三步，测试设计。设计用户模型，设计测试场景，设计测试用例。一个典型的用户是如何

使用系统的？登录、查询车次余票、订票、付款，这是理想化的情况。实际更可能是这样的，登

录（一次登不进去，重复多次）、查询A车次（未到放票时间、不断重试，时间到无票）、查询

B车次（无票）、查询C车次（有票）、订票、付款、查询订单。两种交互方式对系统产生的压

力，差别是很大的。

　　将多个用户行动整合到一起，也就是用户模型，或者叫系统使用模型，是压力场景设计的

依据。假设系统一天的访问量是一万个用户，这一万访问量是在24小时内平均分布的，还是分

布在8小时内，还是在某一时间点上集中访问？这些具体到用例中也就是虚拟用户的加载策略，

直接决定了压力的大小。

　　除了这个压力场景，针对此系统还需要进行绝对并发测试，参考第一步的分析。

　　第四、五步就不细说了，准备环境、数据，针对大量用户的并发进行一些预调优。按照第

三步设计好的各个测试用例准备脚本、执行测试。

　　第六步，发现问题了怎么办？比如1000人的压力下，系统响应就比较慢了，查询车次需要

1分钟，下订单需要2分钟，接下来要做什么？能把这些作为一个性能缺陷提起么？显然是不可以

的，这只是通过你的压力测试场景产生的一个现象，可能是测试脚本有问题、也可能是测试环境

有问题。作为一个性能测试人员，需要尽量深入的定位到问题产生的原因。就像这个响应慢，只

是一个表面现象，慢在哪？是中间件还是数据库？一些简单的测试方法就可以进行判断，如在页

面上进行一些数据库无关的操作，如果依然比较慢，说明在中间件上压力就已经比较大了。还可

以部署另一套中间件测试环境，连接之前相同的数据库，在压力测试出现问题的同时，手动访问

新部署的应用（只有一个用户），如果同样很慢，那说明慢在了数据库端的处理上。还可以通过

日志的方式更准确的进行判断，如应用日志和数据库SQL执行日志。总之方法是多种多样的，但

目的只有一个，就是不断的排除无关部分、缩小问题范围。

　　定位到了中间件和数据库之一，然后又该怎么办？此时恐怕就需要一些相关方面的专业知识

了，但其实最常见的还是那些。中间件相关的一般是线程池、JVM、数据库连接池等，数据库相

关的有锁、缓存、IO（一般就是SQL语句的问题）等。要进行全面的监控和分析，再做一些合理

的调优并重复测试。

　　问题定位到什么程度才行？我认为是要让人看了知道改哪就可以了。比如提一个“这个SQL语

句进行了大量的物理IO，性能不好”，这就不是个好问题，物理IO是什么？怎么改？如果这么说

就好多了“这个SQL语句没有使用索引，导致了全表扫描，进行了大量的物理IO，性能不好。如果

要避免全表扫描，需要调整SQL语句或者添加XX索引”，这才是定位问题。

　　当然了，上面只是一个非常简陋的举例，真实的性能测试要比这复杂的多。

　　总的来说，我认为，性能测试的难度主要不在技术手段上，互联网时代技术都是共享的，要

善于去搜索利用他人的成果。即使自己搞不定，团队内一定还有专业的开发工程师、数据库管理

员、系统管理员可以帮你搞定。真正的难点在于，你要想出来如何去测是有效的、有保障的，这

才是测试工程师最重要的能力。

　　还是那个观点，思想才是根本。

libingyu135

点赞点赞