1

初入职场

第一篇

小白多年一直勤勤恳恳地奋斗在测试行业，但始终

每天重复着黑盒功能测试，虽然自学过一些其他测试技

能，但总感觉不系统，自己也深感职业发展到了瓶颈期，

希望能有所突破，于是他开始查阅资料，无意间发现了

BestTest这样一个网站，里面有不少好资料，经过一段时

间的考虑，决定向性能测试的方向发起突击，希望早日突

破自己的瓶颈！

说来也巧，这时候收到经理的一封邮件，内容如下。

亲爱的小白：

随着公司与产品的发展，我们的测试技术与手段也要

与时俱进，所以准备在后续项目中增加性能测试，而这方

面我们没有技术储备，希望你能承担起这个任务，抓紧时

间学习性能测试，争取早日应用到我们的项目里。不知你

是否愿意接受这个挑战？

这么好的机会小白怎能放过，于是小白毅然决然地接

受任务并信心满满地开始了性能测试学习之旅。

Part 1

2　 　第一篇　初入职场

第 1 章

与性能测试的亲密触碰

性能测试的挑战性和趣味性小白早有耳闻，也会经常听到各个公司因为系统性能而引发

的一系列严重问题，所以性能测试会越来越受到重视，只是时间的问题。下面就让我们和小

白先来了解下性能测试的趣事，再一同学习性能测试的基本知识。

1.1　性能测试的作用以及重要性

随着社会的发展，用户对产品的要求也越来越高，以前可能看重功能方面，现在正在

逐步转变为性能方面，同时各大公司也加强了产品的性能测试，因为从这几年发生的事件来

看，性能带来的严重问题以及损失不容忽视，而性能测试的重要性也不言而喻。

1.1.1　由性能引发的严重问题

小白印象中由性能引发的严重问题历历在目，大部分都是由于没有做性能测试、性能测

试做得不充足或者对并发以及流量的预估不正确导致。

【案例 1】2008 年的奥运会票务系统，由于庞大的订票人数超出预期，奥运票务系统“开

工”后不久便陷入“瘫痪”状态，当时对外公布的是奥运票务系统每小时能处理 15 万张门

票的销售，以及承担每小时 100 万次以上的网上浏览量，但 10 月 30 日系统死机前每小时的

网上浏览量达到 800 万，1 小时售出的票也达到了 20 万张。由于预估工作的缺陷，导致很多

人无法通过网络订到自己想要的票，影响了很多人的热情，也损害了国家形象。

【案例 2】作为电商的代表，2009 年 11 月 22 日，eBay 网站出现死机，导致卖家至少损

失了当日销售额的 80%，原因是那年圣诞临近时，eBay 网站上有超过 2 亿件待售商品，这

Chapter 1

第1章　与性能测试的亲密触碰　 　3

个数字比上一年同期多出 33%，正是这激增的 33% 的待售商品导致 eBay 网站不堪重负而死

机，80% 的销售额对于 eBay 来说不可谓不严重。

【案例 3】魔兽世界在中国的代理商由九城变更为网易，与九城服务器经常死机不无关

系，但是换作网易后，服务器也经常死机。2010 年 10 月 11 日，魔兽世界服务器故障时，官

网论坛上的游戏玩家纷纷发“贺词”表示不满，从这可以看出网易公司对魔兽世界的性能预

估存在不足。也正是因为对性能严重忽视间接导致了九城在失去魔兽世界之后，从一家土豪

公司成了一家几乎被人遗忘的公司。

【案例 4】视频网站优酷网也在 2010 年发生死机事件，超过 3 小时无法访问。优酷对外

宣称的原因是：此次死机事件起源于“地球一小时”活动，优酷网为响应这次活动，全站采

用关灯模式，意在借此提醒网民注重环保与节约。但此举令网友一时无法适应，大量网友频

繁刷新页面导致优酷网服务器崩溃。

【案例 5】2010 年，中国最大的微博平台新浪微博死机 4 小时，新浪官方解释说：之所

以掉线几小时，是因为用户增长超出预期，服务器备感压力。自上午 10 点起，用户无法登

录，新浪的报错页面几次更改，最初的“微博正在升级，将于 11:30 恢复”，然后改为“12:00恢复”，过了一段时间，干脆改为“稍后恢复”，然而，估计是看不到恢复希望，提示信息又

改为“微博系统压力过大正在抢修，我们深表歉意”。悲剧的是“歉意”竟然写成了“谦意”，

这件事遭到网友的大量恶搞，小白也是参与者之一。

1.1.2　性能测试的重要性以及必要性

根据 2008 年 Aberdeen Group 的研究报告表明，Web 网站 1s 的页面加载延迟相当于少了

11% 的 PV，相当于降低了 16% 的顾客满意度。如果从金钱的角度计算，就意味着：如果一

个网站每天挣 10 万元，那么一年下来，由于页面加载速度比竞争对手慢 1s，可能导致总共

损失 25 万元的销售额。

Compuware 公司分析了超过 150 个网站和 150 万个浏览页面，发现页面响应时间从 2s增长到 10s，会导致 38% 的页面浏览放弃率。

Radware 也曾发布一份题为“行业现状：2013 年春季电商页面速度与 Web 性能”的调

查报告。报告指出，仅一年时间内，美国前 2000 家领先的在线零售商网站的加载时间较去

年同期减慢了 22%，网站性能急剧下降，用户体验质量大幅下降。对网站回访率、跳出率、

客户满意度及在线收入等多个关键业务指标的影响越来越大，对在线零售商而言，网站加载

速度已经成为制约其发展的重要因素，提升 Web 性能已经刻不容缓。

2014 年中国电子商务研究中心发布对电商网站的调查报告，报告中指出用户对网站响应

时间的要求很严苛，期望立刻做出响应的占 90%，期望 5min 内做出响应的占 10%。

从上面的研究分析再结合小白印象中列举的例子可以看出，性能测试非常重要也非常必

要，因为性能问题不仅仅会损害公司的形象，也会造成公司资金方面的损失。

4　 　第一篇　初入职场

1.1.3　什么系统需要做性能测试

小白刚接触到“什么系统需要做性能测试”这个问题的时候，心里在想应该是大型的系

统、软件才需要做性能测试，如果只是几个人用就没有必要了。可仔细想想，小白觉得应该

是所有系统、软件都应该做性能测试，关键是要思考应该做到什么程度，而不是做不做的问

题。因为就算是一个人在使用某个系统，但该系统的查询性能极差，一次查询需要 50 多秒

钟，这绝对是任何人都难以接受的。

接着小白对现有的系统进行了分类，大致分为单机系统、C/S、B/S。这 3 类系统都应该

进行性能测试，只是每个分类有各自特点，在实际测试中应该有不同策略进行应对。

一般 C/S 架构的应用程序更关注于系统资源使用情况、数据库性能以及运行的配置要求

等。例如，内存、用户连接数、数据库死锁、数据库 cache 命中率、运行的最低配置等。

而对于 B/S 架构的应用程序，会关注 Web 服务器的相关指标，如每秒点击数、吞吐量、

尝试连接数、事务成功率等。

如下几个案例分别针对典型的系统进行了说明。

【案例 1】假设使用 Word 来编辑一个 1 000 多页的文档，该文档包含了丰富的图表、图

片，需要等待系统花多少秒的时间进行处理。这时需要关注性能响应。

【案例 2】某业务系统属于二次开发，之前没有做过性能测试，当并发 100 个用户时就会

造成数据库服务器崩溃。这是很明显的性能问题。

【案例 3】某企业内部信息系统，使用人比较少，但并发时会出现重复的相同记录。这种

场景很难在功能测试时出现，所以有时候性能测试并不是只能发现性能问题。

【案例 4】面向广大互联网人群的网站，每天都需要接受大量的访问请求，服务器压力

大，对这样的系统进行性能测试是十分必要的。

其中 B/S 架构的系统会比较复杂，小白接到的正好是 B/S 的项目，看来这下需要学习

一番了。

1.1.4　性能测试的目的

很多第一次接触性能测试的人都会把功能测试的思想带入，造成思维的局限。其实性能

测试还是与功能测试有所不同的。性能测试更加关注系统的性能表现，也就是 How fast 和How much。而做性能测试就是排除系统瓶颈，使得它表现得更好、更霸气。可以从以下几个

方面来理解。

1）评估当前系统。系统未做过任何性能测试，对系统的当前性能情况不了解，就好像

没有体检过就不知道自己的身体状况一样。而此前说到的一系列性能引发的严重问题也正是

由于缺少了必要的性能评估而导致。

2）寻找瓶颈，优化性能。常见的现象为，某业务操作响应时间很长、某系统上线一段

时间后运行越来越慢，这些都需要逐步分析定位并调优。

3）预测未来性能。当用户数和业务量增加时能否及时应对？如何调整？是增加应用服

第1章　与性能测试的亲密触碰　 　5

务器，还是数据库服务器？还是要优化代码逻辑？这一系列问题都值得我们深思，这也是性

能测试的目的所在。回想 1.1.1 节中的 eBay 不就是最好的例子吗。

1.2　生活中的性能测试

小白对性能测试有所了解后，不自觉地联想到了实际生活中的现象，他突然发现原来

性能无处不在。每天上下班的高峰，不论是地铁，还是公交车都反映了交通的性能状况。

就拿地铁来说，上下班高峰期进站就是出现了严重的性能问题，表现为缓慢、堵塞、拥挤

甚至打架！对于性能测试来说不也是这样的吗？小白继续思考着，缓解地铁压力的方式无

非就是限流，增加通道、发车频率、列车长度和进站路径复杂度等，这似乎又能和性能测

试挂上钩了。

再想想让我们又爱又恨的 12306。这简直就是一个活生生的例子，网站页面响应很慢，

查火车票更慢，下单还经常失败，服务死机更是家常便饭，小白越想越气，起早贪黑地抢

票，每次都空手而归。小白想如果对产品设计、开发、测试、运维部署中的每个点都进行优

化，也许就会比现在的情况好很多。比如，页面设计简洁，去掉那些花哨的元素；对后端的

业务进行拆分；把火车票的数据分区，并放在各个省市等。理想很丰满，但现实很骨感。不

过小白也明白了一点：学习性能测试多与实际生活中的现象进行类比更容易理解。

1.3　性能术语与指标详解

小白理解了性能测试后就开始了性能测试基本概念的学习，首要任务就是深入理解重

要的术语和指标，因为对这些术语和指标的理解是否深入、透彻，将直接影响后续的学习

效果。

1. 并发数

在理解并发数之前，先提出 3 个常见的概念，分别是系统用户数、在线用户数和并发用

户数。小白发现很多人都会把这 3 个概念混淆，其实是不一样的。以 BestTest 的论坛作为例

子，对应的解释分别如下。

系统用户数：简单地说就是该系统的注册用户数。例如，BestTest 论坛里存在 6666个注册用户，他们可以是活跃的，也可以是僵尸的。

在线用户数：即登录系统的用户。例如，其中有 666 个用户的状态为在线，但在线用

户并不一定都会对服务器产生压力，因为有的用户登录后什么都不干。

并发用户数：是对服务器产生压力的用户。例如，可能在线的 666 个用户中，只有

20% 的用户对服务器产生了压力，这 20% 的用户数就是并发用户数。

那为什么要关注并发用户数而不是其他用户数呢？上面已经提到过，最直接的原因就

6　 　第一篇　初入职场

是只有并发用户数才对系统产生真正的压力。就好像一个人提 1 斤的东西不觉得重，但是提

150 斤的东西，那可就难以提动了。

在实际应用中，并发数可以通过分析服

务器日志得以确定，这种方式更加准确。一般

常用的日志分析工具有 AWStats、Webalizer、Analog、Deep Log Analyzer 等。也可以通过业

界的一些计算模型得到，后续章节中会学习。

这里再延伸一下并发的概念。一般有两

种理解方式：一种为所有用户在同一时刻做

同一种操作，主要是为了验证程序或数据库

对并发的处理能力；另一种为多个用户对被

测系统发起了多个请求，这些请求可以是同

一种操作，也可以是不同的操作，类似于混

合场景的概念。

2. 响应时间

小白通过查找资料发现，大部分资料都

是说“响应时间 = 网络响应时间 + 应用程序

响应时间”诸如此类的解释。小白一时间有

点摸不着头脑。于是，静下心来开始认真分

析、研究。

我们可以换个角度去看待这个概念。首

先从大的方向上可以把一个系统分为前端与

后端，而响应时间也可以按照这个划分来理

解。让我们先看图 1-1 再来理解。

图 1-1　请求与响应

通过图 1-1 可以清楚地看出在没有缓存

的情况下，一个请求发出去后，需要经过网

络传输、DNS 解析等步骤才能到达服务器，

服务器处理完后，经由网络传输返回给客户

端，而客户端接收到以后，要进行解析渲染

展示给用户。这里需要注意，网络时间包括

请求传输的时间和响应传输的时间，而服务

器也可能是多层处理。

这下逻辑就非常清楚了，可以总结为：响

应时间 = 网络传输（请求）时间 + 服务器处理（一层或多层）时间 + 网络传输（响应）时间 +

第1章　与性能测试的亲密触碰　 　7

页面前端解析渲染时间。小白终于明白响应时间背后的来龙去脉了。

在实际应用过程中，需要明白响应时间的长短取决于用户的实际需求，而不是盲目设定

该指标。毕竟在 BestTest 论坛查找一个帖子和在数据统计系统中查找一个月的数据汇总与明

细统计是完全不同的，它们的业务有各自独有的特点，不能简单地一概而论。

注意

前端页面的解析展示时间一般在做非前端性能测试中不太会关注，因为每个浏览器解析页面的

方式不一样，时间也会不一样。

3. 每秒通过事务数

TPS 是指每秒通过事务数，是直接反映系统性能的指标，该值大时，系统性能会比较

好，当然每个系统都有它的上限，不可能无限大。将它与平均事务响应时间进行对比，可以

分析事务数量对响应时间的影响。

例如，当压力加大时，TPS 曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开

始出现瓶颈了。如果环境没有发生大的变化，对于同一系统会存在一个最大处理事务能力，

它并不随着并发用户的多少而改变。就好像传说中的北京五道口地铁检票机一样，只有两台

进站检票的机器，一次一台机器只能通过一个人，不论是来 10 个人，还是 100 个人。

4. 每秒点击数

每秒点击数代表用户每秒向 Web 服务器提交的 HTTP 请求数。但这里需要注意的是提交

一个登录请求，对于用户来说感觉是一个请求，但对于后端服务器来说也许是多个请求，所

以点击一次不代表就是一个请求。例如，点击一个链接，该操作返回的页面上有 6 张图片，

因为下载每张图片都需要一个 HTTP 请求，所以这个页面下载完成之后的点击数应该是 7。每秒点击数从侧面可以反映客户端的状况，每秒点击数不正常，一般可能是网络问题或

者脚本问题导致，需要进一步具体分析。

5. 吞吐量

经常在网上看到“吞吐量”与“吞吐率”的概念，也有不少人把两者混淆。吞吐量是指

单位时间内系统处理的请求数量，能直接反映服务器承受的压力，是需要重点关注的指标。

而吞吐率一般指用户在给定的一秒内从服务器获得的数据量，简而言之就是服务器返回的数

据量。

例如，一个食品厂的生产效率很高，一天能生产很多食品，但是工厂只有两辆三轮车在

运输，不难想象会出现什么样的可怕场景。这个时候工厂运输食品的能力就成为了瓶颈，也

就是它的吞吐量 / 吞吐率出现了瓶颈。

6. 思考时间

思考时间可以从两个宏观的角度来理解。

8　 　第一篇　初入职场

1）思考时间就是用户进行操作时，每个请求或者操作之间的间隔时间，是为了更加真

实地模拟用户的操作场景。因为在实际使用中不太可能会出现不断地发送请求，一般都是一

个请求后，等待一段时间，然后发送下一个请求，恶意攻击除外。

2）小白发现在 BestTest 论坛连续发帖时会提示“两次发帖时间间隔不能小于 15 秒钟”，

这时如果要满足业务的特定需求就需要加上思考时间 15s 了。这下小白对思考时间有了进一

步的认识，很是高兴。

另外，小白经常在网上看到关于 0 思考时间的讨论，自己也有点疑惑，于是请教了经

理。经理告诉他，如果想了解系统的最大承受能力或者极端情况下系统的性能表现，则可以

设置为 0 思考时间。但如果是预估系统的性能，就应该最大可能地模拟真实思考时间。一般

都会加上思考时间，只是在分析时要去掉思考时间。

7. 资源利用率

小白通过查找资料发现，关于资源利用率的资料太多也太杂，根本无法梳理，而且会越

看越乱，无奈之下向经理求助，经理告诉他虽然指标很多，但很多时候每个指标间都是有关

联的，而且重点的就是那么几个，只要把这几个理解透彻就行了。小白按照经理的指导开始

学习、理解重点的几个指标。

CPU ：它就像是人的大脑，主要是进行判断和处理，能反映出系统的繁忙程度，一

般分为系统 CPU 与用户 CPU，其中系统 CPU 是处理系统本身所占用的资源，用户

CPU 则是处理程序所占用的资源，对象不同。

Load Average ：指一段时间内 CPU 正在处理和等待 CPU 处理的任务，也就是 CPU 使

用队列的长度的统计信息。这里的 Load Average 值就好像地铁里等待进站上车的乘

客，越多则 Load Average 值也越大。

Memory ：它就像是人大脑的记忆区域，将各种信息收集起来存放。数据从内存中读

取要比从磁盘上读取速度快，而内存经常发生内存泄露或内存溢出的现象，是需要重

点留意的。不过这里需要注意，短时间的可用内存越来越少，不代表一定有内存泄露

或溢出。

队列：可以理解成地铁进站的排队现象，队列长，说明处理能力可能达到了极限或者

遇到了阻塞。

IO：与磁盘的交互，重点关注交换频率和磁盘队列长度。

网络：重点关注网络的流量，看是否存在网络带宽的瓶颈。

虽然小白把这些指标的含义都弄清楚了，但是具体用法以及如何判断是否会出现问题还

是不太懂，不过小白心里也清楚，这事得一步步来。先把基本概念和重点指标理解清楚了才

是最重要的，只有这样，以后分析起来才能有头绪、有突破口，否则会很被动。想到这里小

白会心一笑，心里暗想加油吧！

第1章　与性能测试的亲密触碰　 　9

1.4　性能测试分类详解

小白在学习过程中发现性能测试的种类繁多，但是实际执行起来又很难严格区分，所以

小白觉得理解各种分类的特点和概念即可，没必要咬文嚼字。

1. 基准测试

基准最简单的理解就是有基础的标准，这样能通过对比发现系统的不同点与变化。一般

情况下，基准测试有以下几种应用场景。

1）可以在制定的标准下通过基准测试建立一个性能基准，这样以后当系统的环境、参

数发生变化之后，再进行一次相同标准下的测试，即可看出变化对性能的影响。例如，数据

库的基准性能测试。

2）系统进行基准测试可以在较早的阶段发现性能问题。例如，如果对 BestTest 网站进

行 10 个用户并发测试时，系统出现了死机的现象，那么就没有必要进行后续的测试了。

3）某系统从来没有进行过任何性能测试，需要对该系统做一次性能评估作为后续开

发调优的参考。这是基准测试常见的一种场景，也是大部分没有做过性能测试的公司最需

要的。

虽然基准测试不难理解，但实践起来常常被误解。以对某个系统的数据搜索进行性能基

准测试为例，这个系统的数据量会随着时间的增长而增长，所以必须频繁地进行基准测试，

这样才能准确地把握数据量的增长对系统性能的影响。但因为进行的基准测试又恰恰是在应

用程序级别的，并不能客观地反映全局性的性能。所以，比较好的做法是每次只修改一个地

方，这样就能准确地判断出哪个地方会对性能产生影响。

2. 并发测试

并发测试可以理解为很多的用户按照预定的场景并发请求某个业务或功能时是否出现并

发问题。例如，内存泄露、线程锁、资源争用等，几乎所有的性能测试都会涉及并发测试。

并发测试的主要目的是找出并发引起的问题。

那并发数又如何确定呢？小白通过查找资料得知，一般可以通过以下几种方法推算需要

的并发数。

1）并发数 =PV / PV Time× 页面连接次数 ×HTTP 响应时间 × 因数 / Web 服务器数量。

其中，PV Time 是 PV 的统计时间，换算成秒，一天是 86 400s。页面连接次数包括外部

的 JS、CSS、图片等，一般为 10。HTTP 响应时间一般可为 1s 或更少。因数一般为 5。假设，BestTest 官网每天有 6 万 PV，其余参数保持默认，那么推算出来的并发数大致

为 35。

提示

PV（page view）即页面浏览量。一个用户有可能创造十几个甚至更多的 PV。它是目前判断网

站访问流量最常用的计算方式，也是反映一个网站受欢迎程度的重要指标之一。

10　 　第一篇　初入职场

2）著名的经典理论 80-20 原则。

3）参考段念老师在《软件性能测试过程详解与案例剖析》一书中提到的估算方法。

当然，上面的方法仅供参考，需要根据实际的系统特点、业务特点来衡量。

3. 负载测试

负载测试可以理解为确定所要测试的业务或系统的负载范围，然后对其进行测试。它的

主要目的是验证业务或系统在给定的负载条件下的处理性能。此外，还要关注响应时间、每

秒通过事务数和其他相关指标。

从另一个角度理解，负载测试可以看作是性能测试的一部分，但它们两者的目的是不同

的，负载测试是为了发现性能问题，而性能测试是为了获取性能指标。因为在性能测试过程

中，也可以不调整负载，而是在同样负载情况下通过改变系统的结构、算法、硬件配置等来

得到性能指标。

4. 压力测试

压力测试可以理解为没有预期的性能指标，不断地加压，看系统什么时候崩溃，以此

来确定系统的瓶颈或者不能接受的性能拐点，以获得系统的最佳并发数、最大并发数。仍然

以生活中的例子来说明，压力测试就好比跑马拉松，看你到底能跑多久，什么时候就坚持不

住了。

压力测试也可以看作是负载测试的一种，即高负载下的负载测试。通过压力测试，可以

更快地发现内存泄漏问题，还可以更快地发现影响系统稳定性的问题。例如，在正常负载情

况下，某些功能可以正常使用或者出错的概率比较低，但在压力测试下可能很快就会出现，

帮助我们提早发现性能问题。

小白想起，公司之前有个网站，在用户少的时候没有什么问题，但在用户多时就暴露出

了一些问题，经常会有异常报错产生。看来公司的网站真的需要进行性能测试来评估了，小

白心里暗想。

注意

负载测试与压力测试的概念并非完全独立，读者大可不必纠结于文字概念。在实际应用中一般

二者都是相互结合、相互补充的。

5. 稳定性测试

稳定性测试顾名思义重点在于“稳定”二字，要想知道系统稳定的情况，就需要长时间

运行，在这段时间内观察系统的出错几率、性能变化趋势等。进而大大减少系统上线后的崩

溃等现象。一般都会进行所谓的 7×24 小时的稳定性测试。

但稳定性测试也有和其他分类不一样的地方，这里需要强调以下两点。

1）一般稳定性测试需要在系统成型后进行，并且没有严重的 Bug 存在。

2）场景的设计以模拟真实用户的实际操作为佳。

第1章　与性能测试的亲密触碰　 　11

6. 失效恢复测试

失效恢复测试重在关注系统出现问题后能否根据预先制定的策略恢复，且恢复后能否正

常运行。怎么理解呢？很简单，以跑马拉松为例，为了预防出现跑不动的情况，预先准备了

一瓶红牛（应该给我广告费），当选手累得躺下后，拿出这瓶红牛一口气喝了，然后你有力量

了，恢复了原来的状态，站起来继续跑。这下理解了吧。

不过失效恢复测试一般是对具有负载均衡的系统进行的，主要是为了测试当系统局部发

生故障时，是否会对全局产生大的影响，产生的影响是否在可以接受的范围内，以及用户能

否继续使用系统。

在实际应用过程中，可以模拟一台或几台负载均衡机器出现故障来进行失效恢复测

试，但需要注意的是，不仅要关心失效后，用户是否可以正常访问或者恢复后系统是否可

以正常工作，也要关注失效后，系统还能支持多少并发用户，以及采用哪些备选方案来快

速响应。

小白学到这里也明白了原来性能测试中需要关注许多点，既要有对某个点的思考，也要

有扩展点的思考，否则容易遗漏或得出片面的结论，而不能从根本上来预防解决问题。

7. 现网性能测试

所谓现网性能测试，就是在实际网络、实际环境中进行测试，完全和真实用户一样。当

然这样的测试有一定的风险，需要注意以下几点。

1）时间段的选择。现网性能测试可能会影响正常用户，所以这样的时间段要尽量避开

高峰期，选择半夜或者凌晨来进行。

2）垃圾数据处理。如果现网性能测试涉及了写数据的操作，那么肯定会带来不少的垃

圾数据，这些数据后期一定要清理，为了清理方便，前期数据的设计要有规律可循。

3）网络限制。和在内网测试不同，现网的测试如果突然间产生大的数据量，可能会被

网络带宽限制，甚至路由会认为是非法数据请求而产生拦截等。所以如果在现网进行性能测

试，那么压力机需要和被测服务器部署在同一个网段机房内，这样可以避免网络限制，最后

远程收集数据即可。

如果没有特殊情况，尽量不要进行现网的性能测试，风险比较大，如果非要进行，一定

要事先充分评估风险以及应对的解决方案，这样出了问题可以快速响应，把影响控制到最小。

1.5　性能测试模型分析

经过上面的学习，小白对基本的性能测试概念等有了深刻理解，为了能把这些概念应用

到实际项目中，小白开始对典型的性能测试模型进行学习，逐步把概念、指标运用起来，并

培养自己的观察分析能力。

12　 　第一篇　初入职场

1.5.1　曲线拐点模型分析

对于初学者来说，培养观察与分析思想是很重要的，首先来看一张典型的曲线拐点模型

图，如图 1-2 所示。

图 1-2　曲线拐点模型

分析图 1-2 最好是先看一个个指标，然后再综合分析，这样的步骤更容易理解，思路也

更加清晰明了。接下来就和小白一起来分析吧，分析思路如下。

1）X 轴代表并发用户数，Y 轴代表资源利用率、吞吐量、响应时间。X 轴与 Y 轴区域

从左往右分别是轻压力区、重压力区、拐点区。

2）然后一个个分析，根据前面学习的性能术语与指标进行理解，随着并发用户数的增

加，在轻压力区的响应时间变化不大，比较平缓，进入重压力区后呈现增长的趋势，最后进

入拐点区后倾斜率增大，响应时间急剧增加。

3）接着看吞吐量，随着并发用户数的增加，吞吐量增加，进入重压力区后逐步平稳，

到达拐点区后急剧下降，说明系统已经达到了处理极限，有点要扛不住的感觉。

4）同理，随着并发用户数的增加，资源利用率逐步上升，最后达到饱和状态。

5）最后，把所有指标融合到一起来分析，随着并发用户数的增加，吞吐量与资源利用

率增加，说明系统在积极处理，所以响应时间增加得并不明显，处于比较好的状态。但随着

并发用户数的持续增加，压力也在持续加大，吞吐量与资源利用率都达到了饱和，随后吞吐

量急剧下降，造成响应时间急剧增长。轻压力区与重压力区的交界点是系统的最佳并发用户

数，因为各种资源都利用充分，响应也很快；而重压力区与拐点区的交界点就是系统的最大

并发用户数，因为超过这个点，系统性能将会急剧下降甚至崩溃。

第1章　与性能测试的亲密触碰　 　13

分析到这里，小白终于找到点成就感了，同时也庆幸自己没有忽略基础，看来基础对于

日后的学习有着重要意义！

1.5.2　地铁模型分析

和绝大部分人一样，小白每天都要乘坐地铁上下班，那么就拿地铁来分析，再次深刻理

解下性能。早上乘坐地铁上班，最典型的就是北京地铁 1、5、10、13 号线等，人多得简直

没法形容！为了方便理解分析，先做如下假设。

某地铁站进站只有 3 个刷卡机。

人少的情况下，每位乘客很快就可以刷卡进站，假设进站需要 1s。 乘客耐心有限，如果等待超过 30min，就会暴躁、唠叨，甚至选择放弃。

按照上述的假设，最初会出现如下的场景。

场景一：只有 1 名乘客进站时，这名乘客可以在 1s 的时间内完成进站，且只利用了一

台刷卡机，剩余 2 台等待着。

场景二：只有 2 名乘客进站时，2 名乘客仍都可以在 1s 的时间内完成进站，且利用了 2台刷卡机，剩余 1 台等待着。

场景三：只有 3 名乘客进站时，3 名乘客还能在 1s 的时间内完成进站，且利用了 3 台刷

卡机，资源得到充分利用。

想到这里，小白越来越觉得有意思了，原来技术与生活这么息息相关，真的可以快乐学

习哦。随着上班高峰的到来，乘客也越来越多，新的场景也慢慢出现了。

场景四：A、B、C 三名乘客进站，同时 D、E、F 乘客也要进站，因为 A、B、C 先到，

所以 D、E、F 乘客需要排队，等 A、B、C 三名乘客进站完成后才行。那么，A、B、C 乘客

进站时间为 1s，而 D、E、F 乘客必须等待 1s，所以他们 3 位在进站的时间是 2s。通过上面这个场景可以发现，每秒能使 3 名乘客进站，第 1s 是 A、B、C，第 2s 是 D、E、

F，但是对于乘客 D、E、F 来说，“响应时间”延长了。

场景五：假设这次进站一次来了 9 名乘客，根据上面的场景，不难推断出，这 9 名乘客

中有 3 名的“响应时间”为 1s，有 3 名的“响应时间”为 2s（等待 1s+ 进站 1s），还有 3 名

的“响应时间”为 3s（等待 2s+ 进站 1s）。场景六：假设这次进站一次来了 10 名乘客，根据上面的推算，必然存在 1 名乘客的“响

应时间”为 4s，如果随着大量的人流涌入进站，可想而知就会达到乘客的忍耐极限。

场景七：如果地铁正好在火车站，例如，著名的北京西站、北京站。每名乘客都拿着大

小不同的包，有的乘客拿的包太大导致卡在刷卡机那（堵塞），这样每名乘客的进站时间就会

又不一样。

小白突然想到，貌似很多地铁进站的刷卡机有加宽的和正常宽度的两种类型，那么拿大

包的乘客可以通过加宽的刷卡机快速进站（增加带宽），这样就能避免场景七中的现象。

场景八：进站的乘客越来越多，3 台刷卡机已经无法满足需求，于是为了减少人流的积

14　 　第一篇　初入职场

压，需要再多开几个刷卡机，增加进站的人流与速度（提升 TPS、增大连接数）。 场景九：终于到了上班高峰时间了，乘客数量上升太快，现有的进站措施已经无法满足，

越来越多的人开始抱怨、拥挤，情况越来越糟。单单增加刷卡机已经不行了，此时的乘客就

相当于“请求”，乘客不是在地铁进站排队，就是在站台排队等车，已经造成严重的“堵塞”，

那么增加发车频率（加快应用、数据库的处理速度）、增加车厢数量（增加内存、增大吞吐

量）、增加线路（增加服务的线程）、限流、分流等多种措施便应需而生。

分析到这里，小白可以熟练地把性能指标与场景结合运用起来了，初步学习成果还是不

错的。

1.6　本章小结

通过本阶段的学习，小白深入理解了性能测试的作用、重要性以及意义，同时掌握了重

要的术语、概念、指标，并把这些知识应用到实际生活场景中，经过深刻学习产出了两个经

典模型。

虽然第 1 章为基础知识，但对于学习整体的性能测试知识尤为重要，如果不能很好地理

解和掌握这些基础，后续的学习将会变得凌乱不堪，这也是很多读者最容易犯的错误，切忌

不要浮躁！

接下来小白将学习现在十分流行的商业性能测试工具 LoadRunner，他又会遇到什么问题

呢？让我们继续往下看吧。