假如我是一名性能测试高手！

流量为王的时代，性能测试要怎么开展？

是什么让阿里双11近几年购物体验越来越好，支持高达54万订单/秒呢？是什么让钉钉、企业微信，快速恢复，支持1000万家企业在线办公呢？618快到了，你如何开展性能测试呢？

所有互联网产品的系统架构都不断优化迭代。技术人员要快速定位当前系统存在的问题，分析造成这些问题的原因是什么？并且提出有效的调优方案，以保证系统能支持预估的访问量。最终可以让系统支持更高的并发，处理更多的业务，保持长时间的稳定运行，流量为王的时代，性能测试是所有产品上线前必须通过的重要环节。

性能测试抢手已成趋势，打开招聘网站，你就会发现很多高薪职位都在招聘JD中，纷纷表示“会性能测试”。而且性能测试的薪水远高于同等经验水平的功能测试，性能正逐渐成为未来10年测试工程师的必备技能！本文给大家介绍性能测试～

性能测试简介

1

性能测试常见指标

吞吐量（TPS, QPS）：简单来说就是每秒钟完成的事务数或者查询数。通常吞吐量大表明系统单位时间能处理的请求数越多，所以通常希望TPS越高越好

响应时间：即从请求发出去到收到系统返回的时间。响应时间一般不取平均值，而是要去掉不稳定的值之后再取均值，比如常用的90%响应时间，指的就是去掉了10%不稳定的响应时间之后，剩下90%的稳定的响应时间的均值。从聚类的观点看，其实就是去掉离群点。

错误率：即错误请求数与总请求数之比。随着压力增加，有可能出现处理请求处理不过来的情况，这时错误数会不断增加。

三者有极大的关联，任何孤立的数据都不能说明问题。典型的关系是，吞吐量增加时，响应延迟有可能增加，错误率也有可能增加。因此，单拿出一个10w的TPS并不能说明问题。

2

性能优化目标

经常听到人说，做性能优化，吞吐量越高越好；或者做个性能测试，目标TPS是50000。可实际拿到这个信息，能够做性能测试吗？这个目标足够清晰吗？

事实上，未定义清晰的目标去做性能测试都是耍流氓。性能优化的目标一般是吞吐量达到多少，90%响应时间小于多少，错误率小于多少。同时还需要关注其他的性能指标，cpu使用情况，内存使用情况，磁盘使用情况，带宽使用情况等。对于摸底测试已经发现问题的，可以针对该问题专门优化，比如负载较高，cpu消耗过大，则目标可能是TPS，响应时间以及错误率不变的情况下降低CPU负载。或者内存增长过快，gc较为频繁，则目标可能是找出可能的内存泄露，或者进行相关的jvm内存调优。总之，目标可以比较灵活调整，但一定要明确。

性能测试步骤

性能测试的工作是基于系统功能已经完备或者已经趋于完备之上的，在功能还不够完备的情况下没有多大的意义（后期功能完善上会对系统的性能有影响，过早进入性能测试会出现测试结果不准确、浪费测试资源）；因此，性能测试首先是基于功能测试的，你必须了解其功能实现才能开展性能测试。

我们还是来逐步分解说明，一个被测系统来了，我们需要分三块来分析：

• 入口：需要怎么发送请求，施压方应该施加多大的压力，用什么方法施压；
• 被测系统：系统怎么应对单个请求，系统业务流程是怎么样的，系统网元节点、数据流向等，整体性能需求有没有，需要考察哪些指标，怎么监控
• 出口：接收数据有哪些，怎么获取和比对；

一般系统的性能测试步骤大体如下：

1）确认测试目标

2） 分析被测系统业务需求

3） 分析被测系统的系统结构

4） 分析被测系统的性能测试点

5） 设计测试方案、检测方案和测试案例

6） 选择测试工具

7） 测试脚本开发

8） 测试执行

9） 测试结果分析

10） 测试调优、测试验证、测试分析

11） 测试报告

1

确认测试目标

首先都要确认任务的目标是什么。如果不知道目标，你所做的任何努力得到的结果有可能都不是最终所需要的结果。

性能测试也一样，它首先是有一个目标的。无论是你是随机测试想看看系统的当前性能情况，还是奔着对系统进行优化而去的，还是检验一下系统的性能是否满足需求，等等，这些都是你在做事情之前的一个目标。

你后面所做的一切事情，从分析到方案和案例设计，到测试执行监控，再到最后的测试分析和报告，都是要围绕这个目标展开的。

所以，首要的任务就是确认测试的目标要求，需要达到怎样的一个测试目的和目标。

有一些测试任务没有明确的目标或者要求，并不说明它没有目的和目标，这就需要我们进行沟通和分析了。

沟通就是要和项目组达成一致的目的要求；分析，分析需求，分析系统，最后也是要明确项目或者系统测试任务的目的要求。

2

分析被测系统的业务

曾经在一次面试中，有一位面试官给了这样一个题目：“有一个网站，只知道它的总访问量一天是300万，怎么测试它的性能？”，大家想一想要怎么设计方案？猜想面试官是想面试者回答，正态分布、二八原理等基本的测试原则应用。

其实，性能测试并不是想象的那样简单，并不是一个简单的原理的应用就行的，如果这么容易，那岂不是谁都能搞定。

性能测试的基础是基于系统的业务功能基本趋于稳定，首要的任务就是性能在系统满足业务功能需求上展开，因此我们必须要分析系统的业务。

不管是普通的网站也好还是比较专业的系统也好，它都是有业务功能需求的，所有的性能测试都要基于这些功能才能进行，脱离了业务功能的性能测试没有意义。

性能测试首要的任务就是分析系统的业务功能，分析系统业务上的性能限制，也就是业务需求。

那么怎么分析系统的业务需求呢？

• 如果有用户需求规格说明，首要的任务就是阅读和理解分析用户需求规格说明；
• 如果没有用户需求规格说明，那么就需要分析系统功能，提炼出系统的业务需求。如果可能，项目组比较熟悉的人讲述一遍是最好的了。
• 最后无论哪一种，最好的方法就是按照自己的理解画出系统的业务流程或者系统的功能结构图，拿到项目组进行确认。一定要进行确认，和整个项目组达成一致的认同。

有人会说，我们自由测试没有项目组可确认的时候怎么办？

还是一样，需要从分析入手。如果不分析，你就不会知道系统的功能数据流向，请求的数据构成，系统的网元结构，以及系统可能出现的瓶颈在哪一个节点，你又怎么进行优化呢？

当然面对一种全新的知识领域的时候，可能需要我们多积累经验，更多的进行分析；我们可能需要结合实践，多次实际运行系统或者执行测试，在测试中不断的进行优化和完善我们的分析过程、分析结果、测试方案、测试开发甚至是测试执行等等。

分析被测系统的业务，有时候不是一蹴而就，需要我们进行多次反复的分析、确认和再分析、再确认，直到把系统弄明白，甚至有可能在测试执行的最后阶段你还需要再次进行分析和确认，然后重新规划测试。

3

分析被测系统的结构

系统的结构和系统的业务一样重要，不知道系统的网元结构可能就没有办法进行监控，就没有办法知道瓶颈在哪个节点，就不能进行优化。分析系统的结构，最好的方法就是项目组提供系统的部署和构成图。如果项目组不能提供或者没有项目组，那就需要用TCPDUMP等抓包工具，分析数据流向。

TCPDUMP的使用：

tcpdump tcp -i eth1 -t -s 0 -c 100 and dst port ! 22 and src net 192.168.1.0/24 -w ./target.cap

• tcp: ip icmp arp rarp 和 tcp、udp、icmp这些选项等都要放到第一个参数的位置，用来过滤数据报的类型
• -i eth1 : 只抓经过接口eth1的包
• -t : 不显示时间戳
• -s 0 : 抓取数据包时默认抓取长度为68字节。加上-S 0 后可以抓到完整的数据包
• -c 100 : 只抓取100个数据包
• dst port ! 22 : 不抓取目标端口是22的数据包
• src net 192.168.1.0/24 : 数据包的源网络地址为192.168.1.0/24
• -w ./target.cap : 保存成cap文件，方便用ethereal(即wireshark)分析

从第一个节点分析流向到哪，确定第二层的节点；然后从第二层每个节点分析第三层节点，逐层分析，完善系统的数据流向的所有结构层次和节点；之后再弄明白每个节点部署的应用程序或者进程队列；对每一个节点的应用程序或者进程队列进行测试监控；最后才能得出哪些应用或者进程队列需要进行优化。弄明白系统的节点构成之外，还需要弄明白各个节点之间的通讯协议和数据格式，后面的测试工具选择和测试数据准备以及测试脚本开发就需要你明白这些。这一切的基础就是要分析和弄明白系统的所有节点，也就是要分析清楚系统的结构。

4

分析系统的性能瓶颈

分析系统的业务需求和系统的结构组成，同时预判系统可能存在的性能瓶颈，这是分析中的一个目标；得到预判的性能瓶颈后我们后面需要在监控的时候多注意一下这些节点。

当然有一些常见的可能会是系统瓶颈的节点我们需要注意:

• 登录，一般系统登录要进行多种校验，可能数据交互比较频繁；
• 下单，抢单、抢红包这个时候会有一定量的并发需求；
• 大数据的查询、统计和报表分析，会对系统产生压力；
• 视频、动画等会对网络产生压力；
• 消息比较集中的系统功能节点，会对系统产生压力；
• 一些特殊的业务需求会对系统产生压力；

常见的瓶颈：

• 数据库的瓶颈一般在磁盘IOPS过高造成进程阻塞
• 系统进程数过多一般会消耗系统的内存空间
• 消息队列和缓存服务，开启持久化后会需要考察磁盘IOPS，不开启持久化则需要考察内存占用
• 频繁的管道开辟和销毁会导致CPU占用较高
• 有部分程序结构上不能利用多个CPU

在分析业务和系统结构的过程中，我们就需要考虑这个业务点或者结构点会不会有大量的数据访问，会不会产生压力，我们的设计会不会产生性能瓶颈。

5

方案和案例设计

测试方案的以及最后测试方案文档的形成，实际就是上面所有分析工作的总结。写测试方案的过程就是明确测试目的目标、分析业务需求、系统结构以及评估测试方法、测试安排、测试风险等等的过程总结。而这些全部来源于你在测试执行之前的分析，有时候可能你在测试过程中还需要做出一些分析和调整。

测试方案包含了这些你分析和整理的各个方面，一个好的测试方案包含的内容：

测试目的目标、内容（可能包含业务性能、可靠性、稳定性等等），业务需求目标，系统业务构成，系统节点构成，测试方法流程，需要监控的指标要求和节点等等。

测试案例，实际上一般需要包含在测试方案中；测试案例，实际上就是普通的业务操作流程，用测试工具或者其他测试手段来模拟大的数据量业务操作，并对系统的各个节点进行监控，获取监控数据。

预期的监控数据和实际监控数据的对比，满足要求就是预期要求，实际对比结果就是测试结果。

性能测试常见误区

误区1：应用程序必须通过功能测试后才可以测试性能

应该尽早的进行性能测试。性能测试可以发生在各个测试阶段中，即使是在单元层，一个单独模块的性能也可以使用白盒测试来进行评估，然而，只有当整个系统的所有成分都集成到一起后，才能检查一个系统的真正性能。

性能测试从早开始，完成一个小模块，对小模块的接口进行性能测试，一般耗费资源很少，但可以防止问题在项目最后出现，花费很大的精力去修改。

而有些资料中提到的：在系统代码开发和功能测试完成之后，进行性能测试的说法，是为了检查系统整体性能的做法。一般经常出现在验收性能测试中。

误区2：软件性能测试要像功能测试一样，覆盖到所有功能

性能测试的主要目的是为了系统调优。不可能对所有的系统功能都进行性能测试。在测试设计时需要结合当时的实际系统，先分析软件可能存在的瓶颈，此时可依据80/20原则分析：对系统资源的利用、数据大量传输、数据转换、用户使用频率、逻辑复杂度等进行分析，选择要执行的功能和场景，再依次制定性能测试的方案。

误区3：系统吞吐率随着并发量增加而增加

随着并发量的增加吞吐率并不是线性增长的。并发量从小逐渐增大，开始阶段吞吐率随着并发量的增加线性变化；当并发量达到某一值时，系统处理能力趋于饱和（也可能某一硬件条件达到临界值），此时再逐渐增大并发，会有一些请求处于等待状态，所以响应时间变慢，吞吐率趋于稳定；当并发量达到系统的最大处理能力后，再增加并发，系统处理能力会下降，吞吐率也会下降，最终可能发生宕机。

误区4：客户给出性能指标，我们一定要想法设法达到

根据用户提供的指标进行可行性分析，分析这些指标在理想状态下是否可以达到。比如有这么一个要求：有一台服务器，希望能承载10000个用户每秒200kb的传输。从CPU、Disk、网卡等方面分析都是很难达到的，也是很难测试的。需要和客户商讨增加硬件配置或者通过其他途径来解决。

误区5：压力测试、负载测试、容量测试等这些不同类型的测试一个一个分开来执行

现实场景是复杂的，测试也需要尽可能的模拟负载的场景。在一个整体的系统性能测试场景中，应该包括各个类型的测试。而需要检查某一个方面的指标或分析某个性能问题时，尽量保证场景简单、单一、容易模拟。

误区6：做性能测试主要就是性能测试工具的使用；

我做不好性能测试，是因为对测试工具不熟悉；测试工具可以自动生成我所需要的报表；依靠性能测试工具就能准确定位系统瓶颈；

测试工具在测试中只能起到辅助性作用。而测试方案、测试场景的分析、问题的定位这才是性能测试的关键。不要期望测试工具能够生成你想要的东西（报表、瓶颈分析），工具只是尽可能多的提供我们分析的依据。

误区7：在线用户数就是并发用户数。

并发用户数高意味着PV（页面浏览量）大。

并发用户数*用户访问页面数=PV

误区8：提高一下硬件配置就可以提高性能了，因此性能测试不重要。

随着软件规模的扩大，提高硬件配置只是解决性能问题的一个基本手段。因为如果软件自身存在性能问题，再多的资源可能也不够用，例如：内存泄露问题，随着时间的增加，内存终究会被耗尽，最后导致系统崩溃；数据库连接等配置信息、数据库死锁是和硬件很难挂钩的；算法逻辑问题导致程序缓慢。即使要提高配置，也要首先用性能测试的方式得出哪些硬件可能存在瓶颈。

误区9：性能测试独立于功能测试

一方面，整体性能测试的场景设计要求的系统功能非常熟悉；另一方面，功能测试可以发现性能问题，性能测试也能发现功能问题。很多性能问题时由于软件自身功能缺陷引起的。如果应用系统功能不完善或者代码运行效率低下，通常会带来一些性能问题。功能测试可能会发现这些问题。

误区10：随便找个环境下进行一下性能测试就可以了。

做性能问题分析可以在类生产环境上进行，配置可以有些差别，但是，整体性性能测试、验收性性能测试要尽量在用户生产环境下进行。