如何开展性能测试工作

文章开始，我先给大家说下QPS/TPS相关简介及区别。

QPS/TPS简介：
QPS：Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

TPS：是TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。

如何达到最大的tps:不断的增加并发数，加到tps达到一定值开始出现下降，那么那个值就是最大的tps。

吞吐量每秒请求的数大于并发数，则可以慢慢的往上面增加；若在压测的机器性能很好的情况下，出现吞吐量小于并发数，说明并发数不能再增加了，可以慢慢的往下减，找到最佳的并发数；
QPS ： 侧重于服务器处理请求的能力（偏向于开发)，即一秒内可以处理的请求数量称之为服务器的QPS；

假设在分布式服务中，其中单台订单服务器一次性（并发）可以处理100个下单请求，每个下单请求耗时 50毫秒：
QPS = ( 1秒 / 单个请求耗时) * 并发数 = (1000/50) * 100 = 2000
TPS： 侧重于服务器集群对单个业务的处理能力，是整个服务器集群对某个业务的处理能力,也是衡量一个系统能否满足当前市场需要的重要标准之一。

性能测试三连问

1 何时进行性能测试？

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

2 如何进行性能测试？

一个被测系统，我们需要分3部分来分析：

• 入口：需要怎么发送请求，施压方应该施加多大的压力，用什么方法施压；

• 被测系统：系统怎么应对单个请求，系统业务流程是怎么样的，系统网元节点、数据流向等，整体性能需求有没有，需要考察哪些指标，怎么监控；

• 出口：接收数据有哪些，怎么获取和比对；

  先分析单个用户的功能流程以及系统的数据流向（包括后台的数据流向）结构图，然后再考虑大量的用户操作。

3开展性能测试的步骤？

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

1.确认测试目标;

2.分析被测系统业务需求;

3.分析被测系统的系统结构;

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

5.设计测试方案、检测方案和测试案例;

6.选择测试工具;

7.测试开发;

8.测试执行;

9.测试结果分析;

10.测试调优、测试验证、测试分析;

11.输出测试报告;

二 性能测试开展前的准备

测试准备工作越充分，后期的测试执行越顺利，一般测试准备工作如下：

1.确认测试目标;

2.分析被测系统的业务;

3.分析被测系统的结构;

4.分析被测系统可能产生性能瓶颈的节点;

5.设计测试方案、检测方案和测试方案;

以下具体分析以上5个步骤：

1 确认测试目标

任何一个任务首先都要确认任务的目标是什么，如果不知道目标，任何努力得到的结果有可能都不是最终所需要的结果。性能测试也一样，首先需要确立明确的目标。无论是随机测试系统的当前性能情况，还是奔着对系统进行优化而去，或是检验一下系统的性能是否满足需求等等，这些都是开展性能测试之前的一个目标。之后的分析到方案和用例设计，到测试执行监控，再到最后的测试分析和报告，都是要围绕这个目标展开。所以，首要的任务就是确认测试的目标要求，需要达到怎样的一个测试目的和目标。

假如有一些测试任务没有明确的目标或者要求，并不说明它没有目的和目标，这需要我们进行沟通和分析。及时与项目组达成一致的目的要求，分析需求，分析系统，最后明确项目或者系统测试任务的目的要求。

2 分析被测系统的业务

朋友曾经在一次面试中，有一位面试官给了他这样一个题目：“有一个网站，只知道它的总访问量一天是300万，怎么测试它的性能？”

大家想一想要怎么设计方案？

猜想面试官是想面试者回答，正态分布、二八原理等基本的测试原则应用。朋友当时没有回答任何与正态分布、二八原理相关的东西。当时面试官对他的回答好像是“蔑视”的笑了笑，可能是觉着连基本的正态分布、二八原理都不知道，还搞性能测试？。其实，性能测试并不是想象的那样简单，并不是一个简单的原理的应用就行的，如果这么容易，那岂不是谁都能搞定。

性能测试的基础是基于系统的业务功能基本趋于稳定，首要的任务就是性能在系统满足业务功能需求上展开，因此我们必须要分析系统的业务。不管是普通的网站也好还是比较专业的系统也好，它都是有业务功能需求，所有的性能测试都要基于这些功能才能进行，脱离了业务功能的性能测试没有意义。性能测试首要的任务就是分析系统的业务功能，分析系统业务上的性能限制，也就是业务需求。

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

• 如果有用户需求规格说明，首要的任务就是阅读和理解分析用户需求规格说明；

• 如果没有用户需求规格说明，那么就需要分析系统功能，提炼出系统的业务需求。如果可能，项目组比较熟悉的人讲述一遍是最好的了。

• 最后无论哪一种，最好的方法就是按照自己的理解画出系统的业务流程或者系统的功能结构图，拿到项目组进行确认。一定要进行确认，和整个项目组达成一致的认同。

有人会问，我们项目组没有可确认的业务需求时候怎么办？

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

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

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

3 分析被测系统的结构

系统的结构和系统的业务一样重要，不知道系统的网元结构可能就没有办法进行监控，就没有办法知道瓶颈在哪个节点，就不能进行优化。

分析系统的结构，最好的方法就是项目组提供系统的部署和构成图；如果项目组不能提供或者没有项目组，那就需要用TCPDUMP等抓包工具，分析数据流向。

TCPDUMP的使用：

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

从第一个节点分析流向到哪，确定第二层的节点；然后从第二层每个节点分析第三层节点，逐层分析，完善系统的数据流向的所有结构层次和节点；再弄明白每个节点部署的应用程序或者进程队列；对每一个节点的应用程序或者进程队列进行测试监控；最后才能得出哪些应用或者进程队列需要进行优化。

弄明白系统的节点构成之外，还需要弄明白各个节点之间的通讯协议和数据格式，之后测试工具选择和测试数据准备以及测试脚本开发就需要以此作为依据。这一切的基础就是要分析和弄明白系统的所有节点，也就是要分析清楚系统的结构。

4 分析系统可能的性能瓶颈

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

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

1. 登录，一般系统登录要进行多种校验，可能数据交互比较频繁；

2.下单，抢单、抢红包这个时候会有一定量的并发需求；

3.大数据的查询、统计和报表分析，会对系统产生压力；

4.视频、动画等会对网络产生压力；

5.消息比较集中的系统功能节点，会对系统产生压力；

6.一些特殊的业务需求会对系统产生压力；

常见的瓶颈：

1. 数据库的瓶颈一般在磁盘IOPS过高造成进程阻塞；

2.系统进程数过多一般会消耗系统的内存空间；

3.消息队列和缓存服务，开启持久化后会需要考察磁盘IOPS，不开启持久化则需要考察内存占用；

4.频繁的管道开辟和销毁会导致CPU占用较高；

5. 有部分程序结构上不能利用多个CPU；

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

5 测试计划和测试用例的设计

测试计划的设计以及最后测试总结文档的形成，实际就是所有分析工作的总结。

写测试计划的过程就是明确测试目的、分析业务需求、系统结构以及评估测试方法、测试安排、测试风险等等的过程总结。而这些全部来源于在测试执行之前的分析，有时候可能你在测试过程中还需要做出一些分析和调整。

测试计划包含了分析和整理的各个方面，一个好的测试计划包含的内容：测试目的、测试目标、测试内容（可能包含业务性能、可靠性、稳定性等等），业务需求目标，系统业务构成，系统节点构成，测试方法流程，需要监控的指标要求和节点等等。

测试用例一般包含在测试计划中，测试用例实际上就是普通的业务操作流程，用测试工具或者其他测试手段来模拟大的数据量业务操作，并对系统的各个节点进行监控，获取监控数据。预期的监控数据和实际监控数据的对比，满足要求就是预期要求，实际对比结果就是测试结果。

6 测试前的准备

环境搭建：测试环境搭建这一步工作量不大，如果有必要可以请开发协助配置完成。

场景建模：考虑哪些场景下可能存在性能瓶颈，相应的设置对应的测试脚本和测试逻辑，以尽可能模拟生产环境（ 一定要熟悉系统业务，因为需求的产生，就是用户+场景）。

测试数据准备：测试数据准备常用的有这两种方式：将生产数据复制一份过来、开发脚本预埋造数据（但无论哪种，一定要注意数据隔离，防止数据污染）。

测试脚本开发：首先，需要从开发那里获取开发接口文档和数据库表设计文档。然后，通过工具或者写测试脚本调试接口，先保证接口可以成功调用。

三 性能测试的正式开展

1执行测试脚本

在保证接口可以成功调用之后，先进行单接口基准测试，即：对一个接口进行压力测试，不断加压，直到响应时间达到或超过指标，观察当前其并发数和TPS。同样的并发数，多执行几次，得到一个平均值或稳定值（即TPS和TRT曲线相对稳定的值），并记录下来。

记录的目的是通过直观的数据变化，得到单个接口的最大TPS和不同并发情况下的响应时间变化。

“80%的性能瓶颈可以通过分析TPS和TRT的数值变化得到”。虽然有点片面，但也不失为一种方法。比如按照上图记录的数值变化来看，很明显领券接口性能极差，这时候就可以告知开发，通过查看log、检查代码、SQL语句等方法来查询原因。当然个人能力足够的话，这些可以自己来做。

2监控调试

所谓的监控调试，就是一个不断调整重复的过程，这个需要根据性能测试的目的去判断具体如何执行。

Jmeter本身就用监听器这个元件提供了一定的监听数值报告元件，但毕竟是开源工具，其本身的组件功能不够强大，可以通过下载支持jmeter的增强型功能插件来进行监控。

Jmeter插件下载地址：https://jmeter-plugins.org/

下载后可以解压缩，将plugins-manager.jar放入jmeter安装目录lib/ext，然后重启Jmeter即可，可以通过点击下图圈出来的按钮检验是否成功安装：

 无论是对服务器资源使用率还是测试数据报表生成，甚至TPS、TRT等的监听，该插件都提供了组件支持，具体使用方法自行探索。

3分析和调优

性能测试除了为获取性能指标外，更多是为了发现性能瓶颈和性能问题，然后对性能问题和瓶颈进行分析和调优，在当今互联网高速发展的时代，性能调优的模型可以归纳总结如下图所示。

性能调优就是不断采集系统中的性能指标以及系统模型中各层的资源消耗，从中发现性能瓶颈和性能问题，然后对瓶颈和问题进行分析诊断来确定性能调优方案，最后通过性能压测进行验证调优方案是否有效，如果无效继续重复这个过程进行性能分析，直到调优方案有效，瓶颈和问题得到解决。这个过程一般是非常漫长，因为很多时候性能调优方案往往不是一次就能有效或者一次就能解决所有的瓶颈和问题，或者解决了当前的瓶颈和问题，但是继续性能压测又可能会出现新的瓶颈和问题。

4输出测试报

根据以上几个步骤，得到测试结果，分析系统存在的瓶颈，然后采用各种方法提出解决方案或优化建议，最后对本次性能测试进行一个完整的总结，这样，一次性能测试就完成了。在整个过程中，费时较长一般是在测试数据准备和测试执行以及监控调优阶段。