性能测试基础教程 on 重定向学院

性能测试基础（一）性能测试分类

Fri, 11 Aug 2017 15:59:11 +0800

关于性能测试有几个名词：性能测试、负载测试、压力测试、并发测试，很多人都是混合使用，或者有时压力测试，有时叫并发测试。这些名词除了非测试人员分不清楚，甚至许多专业测试人员也对这些名词也很模糊。关于这个分类我翻阅了一些资料，解释都比较模糊，并没有给出本质上的区别。只是从不同角度和关注点来解释。我们先来看看这些解释。

#### 性能测试（狭义） ---- 性能测试方法是通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求。通俗地说，这种方法就是要在特定的运行条件下验证系统的处理能力。

特点：

这种测试方法的主要目的是验证系统是否有系统宣称具有的能力。
这种测试方法要事先了解被测试系统经典场景，并具有确定的性能目标。
这种测试方法要求在已经确定的环境下运行。

也就是说，这种方法是对系统性能已经有了解的前提，并对需求有明确的目标，并在已经确定的环境下进行的。

#### 负载测试 ----

通过在被测系统上不断加压，直到性能指标达到极限，例如“响应时间”超过预定指标或都某种资源已经达到饱和状态。

特点：

这种测试方法的主要目的是找到系统处理能力的极限。
这种测试方法需要在给定的测试环境下进行，通常也需要考虑被测试系统的业务压力量和典型场景、使得测试结果具有业务上的意义。
这种测试方法一般用来了解系统的性能容量，或是配合性能调优来使用。

也就是说，这种方法是对一个系统持续不段的加压，看你在什么时候已经超出“预期要求”或系统崩溃。

#### 压力测试（强度测试） ---

压力测试方法测试系统在一定饱和状态下，例如CPU、内存在饱和使用情况下，系统能够处理的会话能力，以及系统是否会出现错误。

特点：

这种测试方法的主要目的是检查系统处于压力性能下时，应用的表现。
这种测试方法一般通过模拟负载等方法，使得系统的资源使用达到较高的水平。
这种测试方法一般用于测试系统的稳定性。

也就是说，这种测试是让系统处在很大强度的压力之下，看系统是否稳定，哪里会出问题。

并发测试

并发测试通过模拟用户并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或其者他性能问题。

特点：

这种测试方法的主要目的是发现系统中可能隐藏并发访问时的问题。
这种测试方法主要关注系统可能存在的并发问题，例如系统中的内存泄漏、线程锁和资源争用方面的问题。
这种测试方法可以在开发的各个阶段使用需要相关的测试工具的配合和支持。

也就是说，这种测试关注点是多个用户同时（并发）对一个模块或操作进行加压。

#### 配置测试 --- 配置测试方法通过对被测系统的软\硬件环境的调整，了解各种不同对系统的性能影响的程度，从而找到系统各项资源的最优分配原则。 __特点：__

这种性能测试方法的主要目的是了解各种不同因素对系统性能影响的程度，从而判断出最值得进行的调优操作。
这种性能测试方法一般在对系统性能状况有初步了解后进行。
这种性能测试方法一般用于性能调优和规划能力。

也就是说，这种测试关注点是“微调”，通过对软硬件的不段调整，找出这他们的最佳状态，使系统达到一个最强的状态。

#### 可靠性测试 --- 在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。

特点：

这种性能测试方法的主要目的是验证是否支持长期稳定的运行。
这种性能测试方法需要在压力下持续一段时间的运行。
测试过程中需要关注系统的运行状况。

也就是说，这种测试的关注点是“稳定”，不需要给系统太大的压力，只要系统能够长期处于一个稳定的状态。

除了上面的分类，还有失效性测试，就是系统局部发生问题时，其它模块是否可以正常的运行。这个在极少数情况下进行，这里就不介绍了。

#### 性能测试分类之我见 ---

上面的类分完了，似乎得到不少专家的认同。但我们在做性能测试过程中真的能把它们区分的很清楚么?你能严格区分出你这次的测试到底并发测试还是压力测试。

我中学时练过几年体育，对于一个体育运动员来说，那么多的体育项目，其实，考核他的就两方面：爆发力和耐力。其实，我们在进行性能测试时主要关注的也是这两方面。

爆发力： 拿一个举重选手来说，他的重点在重量上，因为你只要能举起三秒就算你成功了。关键是看你能举起一个什么样的重量。

耐力： 拿一个马拉松运动员来说，你百米速度跑得再快没用。关键是这40公里路程中，最先跑到终点的人才是赢家。

整体协调性： 作为一个教练，在训练运动员时，除了看这个运动员的实际成绩之外，分析运动员的整体协调性，并发现运动员的短板是最关键的。比如一个运行员身体各位部位练得非常强壮，但右臂先天性萎缩。虽然他的最终的跑步成绩不错。但他在跑的过程中，身体有各个部位明显都在分担右臂的不足。右臂影响了整个体能的发挥。

回到性能测试上上，爆发力就是系统能承受的最大压力，没准系统承受的压力很大，但过半个小时之间就挂掉了。耐力就是这个系统长时间处于压力下的稳定性，这系统超级稳定，跑个几十年都不用重启服务器。那么整体协调性就是看系统有没系统瓶颈（短板），并对其进行系统调优。

原始封面

性能测试基础（二）并发用户

Fri, 11 Aug 2017 14:59:11 +0800

![](http://img.testclass.net/vusers.png)
#### 并发的两种情况 ---- 一种是严格意义上的并发，即所有的用户在同一时间点做同一件事或操作，这种操作一般指做同一类型的业务。比如，所有用户同一时刻做并发登陆，同一时刻做表单提交。

另外一种并发是广义范围的并发，这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或都操作可以是相同的，也可以是不同的。比如，在同一时刻有用户在登录，有用户在提交表单。

从服务器的角度来看并发

前面的两种解释都是从用户业务的角度来解释并发的，因为我们平时所做的性能测试也是从用户端对业务层的操作来进行并发测试的。

如果考虑整个系统运行过程中服务器所承受的压力是这样的：在该系统的运行过程中，把整个运行过程划分为离散的时间点，在每个点上都有一个“同时向服务端发送请求的用户数”，这个就是所谓的服务器所承受的并发访问数。

#### 真正意义上的并发不存在 ----

从性能测试工具的角度来看，虽然，性能测试工具可以1秒模拟成千上万个请求，那么这些请求的产生同样分前后顺序。就算这些请求被真正的“同时”生产出来，通过网络传输到过服务器时，因为受网络带宽、延迟等影响，也无法真正的对服务器构成“同时”请求。

从服务器角度，当它接收到并发请求，在处理这些请求时同样需要分前后顺序，因为它处理每个请求的时间极短；每秒可以处理几千几万次请求；所以，我们说它的并发能力是每秒/次。

（注：这里假设模拟虚拟用户的服务器和系统服务器为单核CPU的情况下）

#### 系统用户数与同时在线人数 ----

在实际的性能测试中，经常还会遇到与并发相关的两个概念“系统用户数”与“同时在线人数”。

假设有一个网站，注册用户才能登录使用各种功能，如上传头像，阅读专家文章等。该系统有20万注册用户，这就是说有20万用户可以使用这个网站的所有功能，20万就是这个网站的“系统用户数”，网站有一个在线统计功能，从统计数据中可以看到，同时登录网站的人数的最高记录是2万，就是有2万人同时用浏览器打开着这个网站。2万就是“同时在线人数”。那么系统的并发用户数2万么？不是的！这2万只表示在系统最高峰时有这么多用户登录了网站，并不代表服务器的实际承受压力。因为服务器承受压力还与具体的用户访问模式相关，在这2万用户中考察某一个时间点对用户发出请求数，可以会大大缩水。那么，该系统的服务端承受的最大并发访问数是多少呢？这个取决于业务并发用户数和业务场景，一般可以通过服务器日志的分析得到。

原始封面

性能测试基础（三）经典例子--理发店原理

Fri, 11 Aug 2017 13:59:11 +0800

接下来通过一个简单理发店模拟来理解系统的并发处理。

__前提：__

1. 一个理发店有三位理发师傅。

2. 每位理发师傅服务一位顾客需要一小时。

3. 顾客都很忙，从进理发店起最多只能等待三小时（等待加 + 被服务的时间）。

思考：

这里我们来理解“最佳用户数”和“最大用户数”。

最佳用户数：

理发店的最佳状态，理发店收入最多（理发师傅没有休息时间，一直在理发），顾客满意度最高（顾客随时店随时接受服务，无需要等待）。从一个时间点来看，3个理发师傅服务3位顾客，那么这个最佳用户数是3。

最大用户数：

理发店的最大承受状态，理发店收入最多（理发师傅没有休息时间，一直在理发），顾客的最大忍耐度（来的顾客等上三个小时才轮到自己服务）。

假如理发店生意非常好，早上一开门一下子来了一群顾客（很多），A、B、C三位顾客先理，D、E、F顾客需要等待一小时才能得到理发师傅的服务，G、H、I三位顾客等待了两小时才得到服务，后面排队的J、K、L…..等顾客，已经等了三小时还没得到服务，因为这已经得达到了他们等待的极限，所以后他们气愤和无奈离开。

当然，理发店还会不断的来新的顾客，不断有等了三小时而没有得到服务的顾客离开，但对于理发店而言，他们在一个时间点上，能服务的最大用户数是九（三位正在接受服务、三位需要等待1小时，三位需要等待2小时）。

对于最大用户数，需要注意的两点：

1. 在理发店里很大，可以容纳很多位顾客（大于9），总有一部分在这里等待了三小时而没有得到服务离开，不要把等待了3小而没有得到服务的顾客纳入最大用户数里。

2. 假如理发店很小，最多只能容纳六位顾客，当第七个顾客来时，虽然，我们知道他只需要等待2小时就可得到服务（这个时间是他可以接受的范围），但由于理发店容量有量，这第七个顾客只有改天再来了。

关于理发店原理，参考

不知道通过上面对理发店的分析，你对性能有了一些眉目。假如理发店相当于我们的系统的话，顾客就我们向服务器所发送的请求，最佳用户数和最大用户数是我们衡量一个系统的处理能力的一种方法。

原始封面

性能测试基础（四）吞吐量

Fri, 11 Aug 2017 12:59:11 +0800

我们每天的生活中都在用水用电，如果我们把水龙头拧到最大，还是一滴水不出。那我们就会找物业/房东去询问情况，但一般不会想过去找自来水公司解决。我们每天都会上网，看电影很卡，需要等很久才缓冲一个几帧；打开网页很慢，IE状态条一直50%，那我们就会找电信服务器商，而不是某视频网站的客服。

以上的情况是正常的，这是生活常识。我想说明的是，你可能从来不关心一个自来水厂供应多少水，但供应多少水对一个自来厂来说却非常重要。你也可能从来不关心一个系统的吞吐量，但吞吐量对一个系统来说却非常重要。

吞吐量

指在一次性能测试过程中网络上传输的数据量的总和。

对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，在容量规划的测试中，吞吐量是一个重点关注的指标，因为它能够说明系统级别的负载能力，另外，在性能调优过程中，吞吐量指标也有重要的价值。如一个大型工厂，他们的生产效率与生产速度很快，一天生产10W吨的货物，结果工厂的运输能力不行，就两辆小型三轮车一天拉2吨的货物，比喻有些夸张，但我想说明的是这个运输能力是整个系统的瓶颈。

但是，用吞吐量来衡量一个系统的输出能力是极其不准确的，用个最简单的例子说明，一个水龙头开24小时，流出10吨水；10个水龙头开1秒钟，流出0.1吨水。当然是一个水龙头的吞吐量大。你能说1个水龙头的出水能力远超10个水龙头？所以，我们要加单位时间的限制，每秒/出水量，这就引出了一个新的概念–吞吐率。

吞吐率

单位时间内网络上传输的数据量，也可以指单位时间内处理客户请求数量。它是衡量网络性能的重要指标，通常情况下，吞吐率用“字节数/秒”来衡量，当然，你可以用“请求数/秒”和“页面数/秒”来衡量。其实，不管是一个请求还是一个页面，它的本质都是在网络上传输的数据，那么来表示数据的单位就是字节数。

但是从业务的角度看，吞吐率也可以用“业务数/小时”、“访问人数/小时”、“页面访问量/小时”来衡量。例如，在银行卡审批系统中，可以用“千件/小时”来衡量系统的业务处理能力。那么，从用户的角度，一个表单提交可以得到一次审批。这又引出来一个概念—事务。

事务

就是用户某一步或几步操作的集合。不过，我们要保证它有一个完整意义。比如用户对某一个页面的一次请求，对某系统的一次登录，对商品的一次确认支付过程。这些我们都可以看作一个事务。那么如何衡量服务器对事务的处理能力。又引出一个概念—-TPS

TPS (Transaction Per second)

每秒钟系统能够处理事务或交易的数量，它是衡量系统处理能力的重要指标。

点击率（Hit Per Second）

点击率可以看做是TPS的一种特定情况。点击率更能体现用户端对服务器的压力。TPS更能体现服务器对客户请求的处理能力。

每秒钟用户向Web服务器提交的HTTP请求数。这个指标是Web 应用特有的一个指标；Web应用是“请求—响应”模式，用户发一个申请，服务器就要处理一次，所以点击是Web应用能够处理的交易的最小单位。如果把每次点击定义为一个交易，点击率和TPS就是一个概念。容易看出，点击率越大。对服务器的压力也越大，点击率只是一个性能参考指标，重要的是分析点击时产生的影响。

需要注意的是，这里的点击不能简单的看作鼠标的一次“单击”操作，也许一次“单击”操作中，客户端可能向服务器发现多个HTTP请求。

__吞吐量指标的作用：__

再次将话题回归到吞吐量上，在我们的性能测试中查看吞吐量对我们的测试有什么意义呢。

1. 用于协助设计性能测试场景，以及衡量性能测试场景是否达到了预期的设计目标：在设计性能测试场景时，吞吐量可被用于协助设计性能测试场景，根据估算的吞吐量数据，可以对应到测试场景的事务发生频率，事务发生次数等；另外，在测试完成后，根据实际的吞吐量可以衡量测试是否达到了预期的目标。

2. 用于协助分析性能瓶颈：吞吐量的限制是性能瓶颈的一种重要表现形式，因此，有针对性地对吞吐量设计测试，可以协助尽快定位到性能瓶颈的所在位置。

__扩展：__

RBI（rapid bottleneck identify）

是Empirix公司提出的快速识别系统性能瓶颈的方法。该方法基于以下事实。

1. 发现的80%系统的性能瓶颈都由吞吐量制约；

2. 并发用户数和吞吐量瓶颈之间存在一定的关联；

3. 采用吞吐量测试可以更快速定位问题。

通过不断增加并发用户数和吞吐量观察系统的性能瓶颈。然后，从网络、数据库、应用服务器和代码本身4个环节确定系统的的性能瓶颈。

原始封面

性能测试基础（五）响应时间

Fri, 11 Aug 2017 11:59:11 +0800

站在用户角度来说，你可以将软件性能看作是软件对用户操作的响应时间。说得更明直白点，对用户来说，当单击一个按钮或链接，从用户单击开始到应用系统把本次操作的结果以用户识别的方式展示出来，这个过程所消耗的时间就是用户对软件性能的直观印象。

#### 响应时间过程分析:

我们需要对这个过程进行分解，才能得到你真正想要的响应时间。我把整个过程分三个部分：呈现时间，数据传输时间和系统处理时间。

呈现时间

其实主要说的浏览器对接收到数据的一个处理展示的过程。几年前大家都在用IE，如果页面显示比较慢，我们肯定不会怪罪IE，只会怪罪电信运营商的网速或被访问的系统（其实，大多情况我们不会考虑是被访问系统的问题）。现在Chrome来了，我们会发现同一台电脑同一个网站，通过Chrome去访问，页面的呈现速度会比IE略快。这是各种评测及大众用户的整体感受。

当然，我说这个呈现时间不能全怪在浏览器的身上，当然还和承载它的操作系统有关，以及电脑硬件（比如CPU、内存）。假如你有超快的浏览器，如果是一台配置很低的电脑上运行，当你多打开几个网页就有可能使电脑卡死。

数据传输时间

千万不要忽视数据传输时间。如果你要寄信给你一个远方的朋友，你想是什么影响你朋友收到信的时间的？不是你写信的过程（如果你写的信不像书一样厚的话），也不是你朋友读信的过程，而是送信的过程。

拿我们系统的数据传输过程来说，我们发送一个请求需要时间，系统处理完后返回给我们也需要时间。初学性能测试工具的同学喜欢拿工具去测试互联网上的一些系统，甚至不懂性能的同学认为可以用性能测试工具将互联网上的一些网站宕机。

那么，我觉得这些同学应该补补网络知识了，你的带宽是多少？互联网是个网，就是算是相同的起点与终点，它有可能走的不同的路线。有没有考虑网络延迟？就算你的发出请求都能成功的发出，但到目的地的时候，已经不能叫并发了。

这也是为什么我们在一般做性能测试时，一般要强调要在局域网中进行。当然，有些性能测试需要在互联网中时行。但它们重点不是验证服务器端的最大处理能力。

系统处理时间

当系统得到请求后会对请求进行处理并将结果返回。那我进行性能测试主要就是验证系统的处理时间，因为前面的呈现时间和数据传输时间都是我们不可控制的，用户使用的电脑及浏览器千差万别，用户的网络状况千差万别。我们唯一能控制的就是将系统的处理请求的时间缩到最短。一般性能测试场景

听了上面的分析，貌似每个过程都挺“浪费”时间，那么我们如何只测试系统的处理时间呢？

一般测试工具都屏蔽响应的呈现过程，只是模拟多用户并发请求，计算用户得到响应的时间，不会将服务器的每个响应做客户端渲染呈现。

对于数据传输的问题，这也是我要强调的性能测试要在局域网中进行，在局域网中一般不会受到数据带宽的限制。所以，可以对数据的传输时间忽略不计。

原始封面

性能测试流程（一）——问清性能需求

Fri, 11 Aug 2017 08:59:11 +0800

假如你一名新进公司的测试小菜鸟，在一次的早会中，领导突然分配给你了一个性能测试任务。我想此时的你是一脸的大写？？，怎么办？怎么办？这里会提供一个通用的测试思路，照着这个思路做，你就会顺利的完成性能测试。

问清性能测试需求

首先，要问本次性能测试的需求是什么，或者性能测试的目的是什么？我把性能测试按目的分以下几种。

1）新系统能力验证

比如，你们刚好开发了一个新系统，在上线前需要验证系统性能。这种情况比较简单；你可以有更多的自由选择测试环境、压力点和测试工具；测试策略上也比较灵活。并且如果性能测试结果没有明显的短板，也不需要进行调优。

2）客户有明确要求

这是一个好的结果，这说明客户对性能测试有一定的了解，知道他们需要的系统要达到一个什么样的标准。如：系统要求同时满足100用户登陆，平均每个用户登陆时间不能超过5秒。这个需求很明确，当然也不排除一些不懂装懂的用户，提一些不现实的要求。

不管怎么说，用户提要求了，这个比较容易，你可以对现系统做一次性能测试，至于，是通过优化系统还是增加硬件设备才能达到要求。就不是测试考虑的问题了。

3）找出系统性能瓶颈

这个需求的目的就很明确了，目的就是找出系统的性能瓶颈，进行调优或硬件扩容，所以性能测试的重点在系统的架构分析和业务分析上面。

4）稳定性验证（强度测试）

稳定性是系统的一个重要指标，因为系统一旦上线，就有可能会长期处在用户的访问状态，可能以前没发现的一些问题就会暴漏出来。比较典型的就是内存溢出，这种需求在测试策略上就要考虑性能测试的运行时长。

注意： 当拿到需求时一定要问测试的目的，一方面会显得你很专业；另一方面，我们通过测试目的可以知道后续性能测试工作的重点在哪儿？最主要的是，还可以揣摩出领导对这次测试的重视程度。^_^!

原始封面

性能测试流程（二）——了解系统架构

Fri, 11 Aug 2017 07:59:11 +0800

系统架构对于测试新手来是最难的；先来了解系统所使用的技术和框架，在环境搭建阶段，你需要了解项目的部署；在性能分析与调优阶段，更要深入这些技术的细节去分析。

下面看一个基本的系统架构：

表示层

表示层（浏览器）通过前端技术（HTML5/JavaScript/CSS3）将系统功能和数据展示给用户，并与用户实现交互。通过TCP/HTTP协议与业务层系统通信，向应用层系统发送请求报文，并接收应用层系统返回的响应报文。

业务逻辑层

业务逻辑层作为中间层实现核心业务逻辑服务。

应用服务器主要运行中间件系统，中间件系统系统作为一个容器来运行各种应用软件系统。前台发来的请求报文通过中间件传递给应用程序，应用程序在处理的过程中调用数据层的数据服务器，数据服务器将查询的数据返回给应用程序，应用软件处理完成后通过中间件系统返回给客户端。

在大型的系统中，可以对应用系统进行拆分，比如拆分成交易服务，查询服务；或者通过负载均衡技术，来分散客户端发来的请求，使其能承受更大的用户访问量。

数据层

数据层运行在数据库主机上，负责整个系统中数据信息的存储。运行数据库服务程序，查询通过JDBC与应用程序进行通信，主要用于存储数据与提供数据查询等服务。

数据库集群技术就是对大型系统应用非常广泛的一种解决方案。

前面介绍了一般系统的架构，那么一个大型的系统在设计中使用了哪些手段或技术来提高系统的性能呢？下面通过一张图来了解一下。

常用的系统架构:

· Linux + Apache + PHP + MySQL

· Linux + Nginx + Redis + PHP + MySQL

· Linux + Apache + Tomcat + Java+ Oracle

· Windows Server 2003/2008 + IIS + C#/ASP.NET + 数据库

· Window Server 2003/2008 + tomcat + MySql/Oracle/ + Java

性能测试流程（三）——分析测试点

Fri, 11 Aug 2017 06:59:11 +0800

当你了解你的系统架构之后，接下来可以好好的分析一下性能测试点。因为这关系到你测试工具的选型。

性能测试点的选取

*　发生频率非常高的（例如：某邮箱核心业务系统中的登录、收发邮件等业务，它们在每天的业务总量中占到90%以上）

*　关键程度非常高的（产品经理认为绝对不能出现问题的，如登录等）

*　资源占用非常严重的（导致磁盘I/O非常大的，例如某个业务进行结果提交时需要向数十个表存取数据，或者一个查询提交请求时会检索出大量的数据记录）

对性能需求点的描述

准确

如**系统必须在不超过 10 秒的响应时间内，处理 20 起登录任务。再如发邮件时间最大不超过5秒以及平均时间在2秒以内。

一致

用户和性能测试工程师对有关术语的理解要一致，如:并发用户数、在线用户数、注册用户数:

特定

性能测试的需求一定是有条件的。

检查系统后台关键业务数据10G、操作数据量为20K，1500 个用户、500 个并发用户运行的负载下，连续运行12小时过程中，业务操作是否满足性能需求。

一般性能需求描述

1、Web首页打开速度5s以下，Web登陆速度 15s以下。

2、邮件服务支持50万个在线用户

3、计费话单成功率达到99.999%以上。

4、在100个并发用户的高峰期，邮箱的基本功能，处理能力至少达到10QPS(TPS). QPS(TPS)–每秒钟请求/事物数量

5、系统能在高于实际系统运行压力1倍的情况下，稳定的运行12小时。

6、这个系统能否支撑200万的VU（每天登录系统的人次） VU–Virtual user(虚拟用户)

原始封面

性能测试流程（四）——测试工具选型

Fri, 11 Aug 2017 05:59:11 +0800

根据对系统性能测试点的分析，我们选择合适的工作。不是所有的性能需求都要用LoadRunner或Jmeter来进行的。只要能满足需求就可以了，我个人倾向于轻量级的性能工具，或自己动手写代码。

测试工具的比较：

软件性能测试工具分为三类，商业收费工具、开源免费工具、自主开发工具。

表：

–	商业工具	开源工具	自研工具
优点	功能强大且简单易用；提供丰富的功能，支持更多协议和并发用户数，丰富的计数器和测试结果；自动生成脚本，学习成本较低；很强的稳定性和可靠性。	轻量灵活容易扩展；可免费下载使用，可查看工具源代码，根须需求容易扩展。	贴近需求，开发出更适合需求的工具，较开源工具学习成本低。可形成特有的工具体系。
缺点	依赖工具本身提供的功能，较难扩展。工具体积大，购买成本高。	学习成本高，不能完全满足性能测试需求，需要功能扩展。功能相对比较简陋。	工具开发成本高，需要专业的工具开发人员或团队，工具成本也会存在不确定。

通过上面的比较分析，很难判别对某类工具的取舍，各自有其明显的优势，当然也有明显的缺点，如何更好选择工具，这里就要结合实际性能的需求了。

需要考虑以下几个方面:

性能需求：

首先要考虑的是否满足性能需求，例如系统的协议不支持，无法创建脚本，系统的模拟用户数达不到，或都某此特殊功能无法测试，如流媒体性能测试等。一些有性能工具是无法满足这些需求的，那当然要首先排除。

购买成本

对于商业工具的购买成本也是我们需要考虑的问题，其实，这个问题也是老板需要考虑的问题，对性能测试成本的整体预算等。当然了，在满足性能需求的前提下，当然一切从简。正版LoadRunner的服务费用非常的高。那么开源软件呢？开源的性能测试工具其实非常的多，因为它们都分别适合在不同的需求场景下，所以，它们的体积相比商业软件会小很大，当然功能也相对简陋。但是他们在某些情况下可以完全满足某些性能需求，或者可以通过几款开源工具配合满足，或者通过对开源工具进行扩展进行满足。对开源工具进行扩展，对测试人员的要求较高。需要测试人员对工具的原理及源代码有相当有研究。这里对测试人员自动能力的提升非常有帮助。或者你的性能测试项目特殊，找遍市面上的所有性能工具无一款满意，商业定制成本过高。或者你想构建自己有工具体系。处于公司需求的特殊性与长期性考虑，可以自主开发一个性能测试工具来用。一次开发，永久收益（当然也需要维护与升级、扩展等），而且更贴近自已的需求。目前很多知名的大公司都有自己的性能测试工具，用于内部使用。

人员学习成本：

最后要提到的就是人员对工具的学习成本，其实，测试人员在选择性能测试工具时最先考虑的就是从自己会使用的工具入手，这样可以最低的控制学习成生，如果整一个工具，测试人员单学测试脚本就学了半年，老板早让你走人了。这也是对性能测试人员要求较高的地方。所以，对于性能测试人员，你最好熟悉一款流程的商业性能工具，一款开源免费性能具，还需要熟悉常见的性能脚本开发语言等，这是基本要求。

原始封面

性能测试流程（五）——测试计划

Fri, 11 Aug 2017 04:59:11 +0800

一．简介

简介部分就不用过多描述了，无非项目的背景，进行此次性能测试的原因，以及性能测试覆盖的范围等等，几乎所有项目文档都在开端对项目进行简单的阐述。

二．性能测试需求

寻找的被测试对象和压力点

要测试的对象不是凭空想象出来，而是经过分析与系统数据收集得到。以下取几个典型的压力点。

查询：查询一般比较消耗系统和数据库资源。搜索引擎的查询功能就是典型，如果你在输入框内输入内容，很久就得不到结果。我想被称为“互联网入口”的搜索引擎就不会存在。

交易：对于一些电子商务系统来说，交易过程的性能要求是很高的，如果交易过程消耗用户很长时间的话，用户可能会转投其它平台。当然，除了交易速度外，对交易的成功率要求也是非常高的。不然，造成的损失也是不可估量的。

被测的系统应该是最重要的最基本的功能，也是用户使用最频繁的功能。

三．测试环境

这里的测试环境主要指的软件硬件环境和网络环境。

笔者认为性能测试最好在一个独立的环境内进行，这样不会受到外界的干扰，能够保证测试的数据是独立有效的。如果现你对某个已经上线的网站进行压力测试，那么你得到的数据不是独立的，因为你在做压力测试的时候，其它散户也在访问系统。

软件环境：

这里的软件环境主要指项目运行的环境，比如采用什么样的操作系统、中间件、和数据库。

硬件环境：

这里的硬件环境除了主要包括主机内部部件，cpu、内存、磁盘以及主板、网卡等，传输介质和路由器也应该考虑在内，

网络环境：

网络环境除了考虑测试机与被系统服务器在一个局域网中进行，还应该保证这个网络的独立性。如果在在性能测试的过程中，其它机子也在消耗着路由器资源。那么路由器也会影响到数据库的传输速度。

四．数据准备

在很多时候，我们是要准备测试数据的，例如系统不允许相同用户的重复登录，那么必须要生成合法的用户数据。有时要对系统进行查询测试，只有在系统有一定数据量进才能验证出系统的真实性能。一个数据库中有两条数据和有两千万条数据，同相一条查询操作，对系统造成的压力是完全不一样的。

系统所需数据的分析可以参考以下方式：

历史数据分析有助于数据量级的确定。从历史数据入手，找出高峰期数据量。

从其他相似或者相同系统入手，进行数据分析，找出高峰期数据量。

无历史或者相关系统可以参考的时候，就要对系统的性能数据进行估算，包含系统容量，并发数等数据，估算以后给相关人员进行评审或者修订以后，按照大家同意的性能指标进行测试。

…………

测试数据最好和真实数据相同，如果能够获得真实系统运行3个月的数据，我们就可以在此基础上进行性能测试。

关于数据的生成，我们可以通过工具完成，如数据库数据生成工具，大小文件生成工具等。

五．测试工具

前面已经介绍如何分析需求，需求确定下来之后，我们可以考虑引入什么样的工具适合性能需求。

当然，在引入工具的时候除了考虑可以是否满足需求，还应该考虑工具的成本，这不单指工具的购买成本，还有测试人员对工具的学习成本。

关于测试工具的选择，后面会单独有一章节介绍，这里就不细说了。

如果你选择的性能测试工具不是足够的强大的话，你可能还需要其它的辅助的工具。如果Jmeter利用BadBoy来录制脚本，更能提高脚本开发效率。在压力测试的过程中也可能需要性能计数器来记录软硬件的性能。如监控服务器CPU、内存的计数器，记录中间件日志的监控中工具，监控数据库性能的监控工具等。

六．测试策略

对于一个特定的业务系统，用户一般会分散在一天的各个时间段进行访问。在不同的时间段中，用户使用业务系统的频率不同，而系统的繁忙程度不同。在一些特定的条件下，可能出现短时间内用户集中访问某个业务系统的情况。例如对于公文处理子系统而言，可能就存在短时间内大量用户查看并办理某条公文的情况。在进行性能测试时，应当使用“考虑最坏情况的原则”。也就是应当在用户使用业务系统最频繁、对系统造成最大压力的情况下对系统的功能进行测试，判断各功能和页面是否能够满足性能的要求，系统的响应时间是否过长。

另一方面，系统性能的验证必须做到“覆盖全面”。虽然系统中各个功能的使用频率并不相同，一些功能的使用频率相对于其他功能来说比较低，但是在进行性能测试和优化时，不能忽略这些功能，编制测试用例时也不能仅仅选择最常用功能。例如可能所有的用户都会访问我的通知列表，但是一般只有5%的用户会使用通过系统设置模块查找某个用户的信息；但是在测试时，我们并不能因为查看用户信息功能的使用频率相对较少，而忽略掉这项功能的测试。所以，这里进行系统性能测试时，对于不同业务，用户的访问比例应该做一个合理分配。

在测试策略上，我们还应该考虑，同一个系统在不同硬件环境下的性能表现。从而让系统满足需求的情况下，硬件配置也能达到一个最佳的状态。过份的增加硬件来满足需求也是一种浪费。再说增加硬件设备不是能解决所有性能问题的。

七．人力与时间安排

最后一条，就是要根据项目的进度要求以及规模，来进行人力与时间的安排。对于大型的性能测试，项目前期的需求调研，环境的部署，工具的选购或开发，人员对测试工具的学习与使用，性能测试的后进行，后期数据的分析与调优。都需要人员安排的。有可以需要专业的，系统工程师、数据库工程师、软件开发工程师、网络工程师以及性能测试工程师的共同参与配合完成。不是一个性能测试人员就可以全部搞定的。

原始封面

性能测试流程（六）——测试环境搭建

Fri, 11 Aug 2017 03:59:11 +0800

#### 性能测试环境与功能测试环境的区别那么性能测试环境与功能测试环境有所不同，对于一些企业为了节约资源，进行功能测试的测试环境，一台服务器可以运行多个系统，通过技术手段可以使系统之间是不会相互影响的（以前公司就是一台服务器上跑多个tomcat）。性能测试是要对整个系统运行的软件硬件环境进行测试的，如果某环境下运行多个系统，就很难判断其中的某个环境对资源的占用情况。
#### 保证测试环境与生产环境的一致性

1、硬件环境，包括服务器环境、与网络环境

如服务器的型号以及是否和其它应用程序共享此服务器，是否在集群环境下，是否通过BIGIP进行负载均衡，客户使用的硬件配置情况，使用的交换机型号，网络传输速率。

2、软件环境

版本一致性

包括包括操作系统、数据库、中间件的版本，被测系统的版本。

配置一致性

系统（操作系统/数据库/中间件/被测试系统）参数的配置一致，这些系统参数的配置有可能对系统造成巨大的影响。所以，除了保证测试环境与真实环境所使用的软件版本一致，也要关注其参数的配置是否一致。

3、使用场景的一致性

基础数据的一致性

包括预测的业务数据量，以及数据类型的分配。很简单的一个列子，一个系统的数据库只有10条数据和一条数据库里几千万条数据，我们在对其进行性能测试时，得到的性能指标可能会有非常大的差别。

为了保证每次测试环境的更加一致性，磁盘的使用情况以及磁盘的碎片情况也会或多或少的影响的性能。

使用模式的一致性

尽量模拟真实场景下用户的使用情况，其实，我们在做性能测试前期的需求分析，其主要目的也就是为了更真实的模拟用户的使用情况。

#### 实施策略

上面讲测试环境与生产环境保持一致所需要注意的内容。在实际的测试中，处于成本考虑，在很多情况下，我们很难申请到足够的且一致的资源，所以，很难搭建出与生产环境完全一致的一个测试环境。

我们一般通过两种策略来搭建性能测试环境（预估方式均有误差）

1、通过建模的方式实现低端硬件对高端硬件的模拟

通过配置测试来计算不同配置下的硬件性能和系统处理能力的关系，从而推导出满足系统性能的真实配置情况，这种模拟需要精确的建模，模型的采样点越多，那么得到的结果越精确，从而将在低端配置下的性能指标通过该模型转化为高端配置下的最终预计性能指标。

例如：搭建一个低端环境，首先需要对这个环境的CPU和内存进行单独的性能基准测试，同过在不同的配置的性能测试，得到一个基准信息列表，当然，在进行这个性能测试的过程中，我们要确定硬件是系统的瓶颈。如果只用一个CUP，在性能测试过程中，其使用率很低，但得到的性能数据都非常底，这起码说明CUP不是系统的瓶颈，这种情况下就无法得到想要的基准值。

如上图，在一颗CPU情况下，运行100个用户且CUP使用率接近饱和（100%）。在增加至两颗CUP的情况下，可以运行190个用户且UPU使用率接近饱和（100%），以此做记录，那么我们就可以推算出运行800个用户需要多少颗CUP。如果你在实际应用中使用的CUP型号及其频率并非完全一样，这个时候可以使用EVEREST工具计算每种CUP的得分，对其性能进行评估。内存也可以使用此方法进行测试推导，这里需要我们多进行试验，对硬件的性能以及对整个项目的结构都要做深入的了解，以便尽量减少误差。

2、通过集群的方式计算

对于较大的系统来说，单台服务器的处理能力是有限的，通常都会采用集群的方式来进行负载均衡，完成对海量请求的处理。虽然无法获得整体集群的测试环境，但是可以对集群上的一个节点进行性能测试，得出该节点的处理能力，再计算每增加一个节点的性能损失，同样也可以能过建模的方式得到大型负载均衡情况下的预计性能指标。

例如:首先在单台服务器上获得具体的性能指标，每台服务器能够承受500用户并发，平均TPS为60，响应时间为2秒，接着，添加负载均衡策略，再次测试负载策略下的数据损耗。得出数据后添加1台负载均衡服务器，测试在两台服务器下每台服务器的性能指标，以此类推，可以得到下表：

表：

负载服务器个数	并发用户数	平均TPS	响应时间
1	500	60	2
1	490	58	2
2	490	58	2
3	480	57	2

随着负载均衡服务器的添加，平均每台服务器的处理能力会逐渐稳定，从而了解在什么情况下需要多少台负载均衡服务器。

原始封面

性能测试流程（七）——测试执行

Fri, 11 Aug 2017 02:59:11 +0800

参考测试计划，大概执行过程如下：

1、准备测试数据

2、使用测试工具模拟测试点，回放OK

3、根据测试策略，使用不同的虚拟用户和测试组合运行测试。

4、监控系统CPU、内存、中间件，数据库的性能，收集数据。

5、重复3、4。

原始封面

性能测试流程（八）——性能调优

Fri, 11 Aug 2017 01:59:11 +0800

![](http://img.testclass.net/tuning.jpg)

一般系统的瓶颈

性能测试调优需要先发现瓶颈，那么系统一般会存在哪些瓶颈：

硬件上的性能瓶颈：

一般指的是CPU、内存、磁盘I/O 方面的问题，分为服务器硬件瓶颈、网络瓶颈（对局域网可以不考虑）、服务器操作系统瓶颈（参数配置）、中间件瓶颈（参数配置、数据库、web服务器等）、应用瓶颈（SQL 语句、数据库设计、业务逻辑、算法等）。

应用软件上的性能瓶颈：

一般指的是应用服务器、web 服务器等应用软件，还包括数据库系统。

例如：中间件weblogic 平台上配置的JDBC连接池的参数设置不合理，造成的瓶颈。

应用程序上的性能瓶颈：

一般指的是开发人员新开发出来的应用程序。

例如，程序架构规划不合理，程序本身设计有问题（串行处理、请求的处理线程不够），造成系统在大量用户访问时性能低下而造成的瓶颈。

操作系统上的性能瓶颈：

一般指的是windows、UNIX、Linux等操作系统。

例如，在进行性能测试，出现物理内存不足时，虚拟内存设置也不合理，虚拟内存的交换效率就会大大降低，从而导致行为的响应时间大大增加，这时认为操作系统上出现性能瓶颈。

网络设备上的性能瓶颈：

一般指的是防火墙、动态负载均衡器、交换机等设备。

例如，在动态负载均衡器上设置了动态分发负载的机制，当发现某个应用服务器上的硬件资源已经到达极限时，动态负载均衡器将后续的交易请求发送到其他负载较轻的应用服务器上。在测试时发现，动态负载均衡器没有起到相应的作用，这时可以认为网络瓶颈。性能测试出现的原因及其定位十分复杂，这里只是简单介绍常见的几种瓶颈类型和特征，而性能测试所需要做的就是根据各种情况因素综合考虑，然后协助开发人员\DBA\运维人员一起定位性能瓶颈。

#### 一般性能调优步骤 ---

步骤一：确定问题

应用程序代码：在通常情况下，很多程序的性能问题都是写出来的，因此对于发现瓶颈的模块，应该首先检查一下代码。

数据库配置：经常引起整个系统运行缓慢，一些诸如oracle 的大型数据库都是需要DBA进行正确的参数调整才能投产的。

操作系统配置：不合理就可能引起系统瓶颈。

硬件设置：硬盘速度、内存大小等都是容易引起瓶颈的原因，因此这些都是分析的重点。

网络：网络负载过重导致网络冲突和网络延迟。

步骤二：分析问题

当确定了问题之后，我们要明确这个问题影响的是响应时间吞吐量，还是其他问题？是多数用户还是少数用户遇到了问题？如果是少数用户，这几个用户与其它用户的操作有什么不用？系统资源监控的结果是否正常？CPU的使用是否到达极限？I/O 情况如何？问题是否集中在某一类模块中？是客户端还是服务器出现问题？系统硬件配置是否够用？实际负载是否超过了系统的负载能力？是否未对系统进行优化？

通过这些分析及一些与系统相关的问题，可以对系统瓶颈有更深入的了解，进而分析出真正的原因。

步骤三：确定调整目标和解决方案

得高系统吞吐量，缩短响应时间，更好地支持并发。

步骤四：测试解决方案

对通过解决方案调优后的系统进行基准测试。（基准测试是指通过设计科学的测试方法、测试工具和测试系统，实现对一类测试对象的某项性能指标进行定量的和可对比的测试）

步骤五：分析调优结果

系统调优是否达到或者超出了预定目标？系统是整体性能得到了改善，还是以系统某部分性能来解决其他问题。调优是否可以结束了。

最后，如果达到了预期目标，调优工作就基本可以结束了。

原始封面

性能测试基础教程 on 重定向学院

性能测试基础（一）性能测试分类

并发测试

性能测试基础（二）并发用户

从服务器的角度来看并发

性能测试基础（三）经典例子--理发店原理

性能测试基础（四）吞吐量

性能测试基础（五）响应时间

性能测试流程（一）——问清性能需求

问清性能测试需求

性能测试流程（二）——了解系统架构

性能测试流程（三）——分析测试点

性能测试流程（四）——测试工具选型

测试工具的比较：

需要考虑以下几个方面:

性能测试流程（五）——测试计划

一．简介

二．性能测试需求

三．测试环境

四．数据准备

五．测试工具

六．测试策略

七．人力与时间安排

性能测试流程（六）——测试环境搭建

性能测试流程（七）——测试执行

1、准备测试数据

2、使用测试工具模拟测试点，回放OK

3、根据测试策略，使用不同的虚拟用户和测试组合 运行测试。

4、监控系统CPU、内存、中间件，数据库的性能，收集数据。

5、重复3、4。

性能测试流程（八）——性能调优

一般系统的瓶颈

3、根据测试策略，使用不同的虚拟用户和测试组合运行测试。