聊一聊性能测试

提到性能测试，很多从业相关人员可能会感觉比较混淆。

性能测试，它是属于测试领域一个专业细分领域，和软件测试一样，性能测试涉及到的范围和所需要的技能是非常广而精的，如果从大的类型来划分的话性能测试可以被分为：

服务端性能测试 | 客户端性能测试 | 全链路性能测试

这三种性能测试它的关注点及关注指标都是不一样的，本系列以服务端性能测试展开，客户端性能测试及全链路性能测试不在此系列说明

什么是服务端性能测试？

那么，什么是服务端性能测试呢？

从大家熟悉的功能测试举例吧！比如测试一个简单登录功能，在只考虑正常流程的情况下无非就是输入正确的账户和密码点击登录，然后跳转到系统首页。

注意，这里的登录是只考虑正常流程的情况下，而在这里功能测试也不是重点。

那么，如何对该登录功能进行性能测试呢？

就是在确保功能测试已经通过的情况下，模拟多个用户同时进行登录，在这过程中监控系统的各项性能指标及服务器硬件资源的使用情况。

看到这里，相信许多人都觉得比较简单。虽然简单，但是这例子已经包含的性能测试的三个基本特点。

功能测试已通过
一定的并发用户
监控各项性能指标与硬件资源使用情况

最后，在明确下什么是性能测试：性能测试是在有性能测试指标的前提下模拟多个用户对系统进行操作（请求），监控系统的各项性能测试指标与服务器资源是否达到我们的一个预期值。

功能测试的测重点是测试功能是否与需求说明书一致，性能测试的测重点是测试系统是否符合我们预期的一个性能指标。各位千万别搞错了哦！

性能测试类型？

根据不同的测试目的，性能测试可以大致分为五种类型，类型如下：

基准测试
负载测试
压力测试
疲劳强度测试
稳定性测试
容量测试

性能测试类型概念？

基准测试：

基准测试是指模拟单个用户执行业务场景，监控系统的性能指标与服务器资源。严格来说，基准测试不属于性能测试的范畴，它与功能测试其实没有太大的区别。具体的差异在于，基准测试的目的更多的是关注业务功能及验证脚本的一个准确性，然后，将基准测试时采集到的结果（各项性能指标及服务器硬件资源）作为后续并发测试性能分析的一个参考依据。

负载测试：

**负载测试是模拟系统在正常负载压力场景下，考察系统的各项性能指标**。这里说的正常负载，主要是指用户对系统能承受的最大负载量的期望值。即预计系统最大可用支持的业务并发用户数。**通过负载测试，可以验证系统是否能满足我们预期的一个业务压力场景**。

通常负载测试类型是最典型的性能测试类型。通过负载测试，得到系统的性能拐点（最佳性能点），当达到这个点时，系统的极限与表现能力又是多少！负载测试也经常用于线上流量评估。

压力测试：

压力测试是测试系统在多大并发压力下系统的性能会变得不可接受，或者出现性能拐点（崩溃）。在加压策略上，压力测试会对被测系统逐步加压，在加压的过程中考察系统性能指标的走势情况，最终找出系统在出现性能拐点时的并发用户数，也就是系统支持的最大并发用户数。

压力测试主要用于测试系统或系统某些部分的极限能力。通过一直增加负载，直到应用的部分功能不能正常工作，压力测试的****目的是找到被测系统的容量天花板。

看到这里，是不是觉得负载测试和压力测试好像没啥差别。其实还是有很大区别的！

目的不一样。负载测试是验证系统是否满足预期的业务压力场景；而压力测试是找到测试系统的容量天花板。
负载测试是模拟多个用户不同时间段内持续向系统发送请求的，而压力测试是模拟同一时间段内持续不断的向系统发送请求的。

如果各位还有不同见解的话可以评论区下留言哦！

疲劳强度测试：

疲劳强度测试与负载测试testing觉得挺接近的，都是对系统模拟出系统能承受的最大业务负载量。差异在于，疲劳强度测试的侧重点是系统在长时间运行情况下系统各项性能指标的变化情况。例如：系统在运行24 * 3后，是否会出现事务处理失败、响应时间增长、业务吞吐量降低、CPU/内存资源增长等性能问题。

稳定性测试：

稳定性测试是测试被测系统持续正确运行的周期长度。

看到这里，是不是觉得疲劳强度测试和稳定性测试很像，感觉是一个东西，其实不是的。

稳定性测试是指被测系统被用户正常的使用，能持续多长时间运行而不出现错误。而疲劳强度测试是指被测系统可以支持的最大并发数长时间模拟运行业务，通过资源和性能指标侧面分析系统的稳定性。

说到这，知道了稳定性测试需要花费的大量时间（如上月、上年）。所以大部分情况下，用疲劳强度测试来替代稳定性测试。

容量测试:

当系统业务越来越复杂的时候，比如双十一、春节等大促。我们应该怎么评估线上的性能？如何去做合理的扩容？这个时候就需要开展相应的容量测试了。

其实说到这里，通过对比可以发现，不同的性能测试类型，其本质的差异还是体现在了加压策略上，而采用哪种加压策略，就取决于我们性能测试的目的，即希望通过性能测试发现什么问题。本节可以总结出性能测试不同类型的重点在于加压的方式及策略。

性能测试指标:

一般来说，性能测试指标从维度上划分的话，主要可以分为两大类，分别是**业务性能指标和系统资源性能指标。**这里贴下百度的答案，具体的小编也有点忘了。

业务性能指标可以直观地反映被测系统的实际性能状况，常见的指标项有：

**并发用户数**
**事务吞吐率（TPS/RPS）**
**事务平均响应时间**
**事务成功率**

系统资源性能指标主要是反映整个系统环境的硬件资源的一个使用情况，常见的指标项有：

服务器：

CPU利用率、处理器队列长度、内存利用率、内存交换页面数、磁盘IO状态、网卡带宽使用情况等。

数据库：

数据库连接数、数据库读写响应时长、数据库读写吞吐量等；

网络：

网络吞吐量、网络带宽、网络缓冲池大小；

缓存（Redis）：

静态资源缓存命中率、动态数据缓存命中率、缓存吞吐量等；

测试设备（压力发生器）：

CPU利用率、处理器队列长度、内存利用率、内存交换页面数、磁盘IO状态、网卡带宽使用情况等。

看到最后一项（测试设备）有些人可能会问了，监控被测系统环境的相关硬件资源使用情况时，为什么还要关注测试设备本身呢？因为测试设备在模拟高并发请求的过程中，测试设备本身也会存在较高的资源消耗，例如CPU、内存、网卡带宽吃满，磁盘IO读写频繁，处理器排队严重等；当出现这类情况后，测试设备本身就出现了瓶颈，无法产生预期的并发压力，从而在测试中得到的数据也就不具有可参考性了。

说到这里，性能测试指标之间通常都是有密切关联的。如果单纯地看某个指标往往很难定位出性能瓶颈，所以需要我们对各项性能指标的含义了然于胸，然后才能在实际测试的过程中对系统性能状况综合进行分析，找出系统真正的瓶颈。

举个例子，在压力测试时发现服务器端CPU利用率非常高，那这个能说明什么问题呢？是服务端系统算法问题呢，还是服务器硬件资源配置跟不上呢？光看这个指标并不能定位出产生问题的根本原因，如果仅因为这一点，就决定直接去优化系统算法或者升级服务器配置，最后也很难真正地去解决问题。

是不是说到这里就明白了，**性能瓶颈定位的重点在于性能测试指标的监控和分析**。

性能测试开展:

前面说了那么多理论，那么实际工作又是怎么开展的呢？结合具体的一个实际情况，小编觉得下面这流程是比较标准的。

了解&获取性能测试需求，确定性能目标
设计及确定测试方案|测试计划
提取测试的业务场景，设计测试用例
构建性能测试环境
编写性能测试脚本和基准测试
执行性能测试和分析
测试结果分析和报告

性能测试工具推荐:

性能测试的主要手段是通过模拟真实业务的压力对被测系统进行加压，同时监控被测系统的各项性能指标，分析被测系统在不同压力情况下的表现，找出其潜在的性能瓶颈。

那么，如何对系统进行加压，又如何对系统的指标进行监控呢？这里，就需要引入性能测试工具了。

当然，我们也可以看下在不借助性能测试工具的情况下，如何手工地对系统进行性能测试。

假设现在我们要对前面提到的登录功能进行负载测试，验证在10个并发用户下登录功能的事务平均响应时间是否在3秒以内。

很自然地，我们想到测试的前提条件有如下几点：

10个测试人员，产生业务压力
1个指挥人员，对10个人员的协调控制，实现并发操作
1个结果记录人员，对每一个人员的操作耗时进行监控和记录
若干资源监控人员，实时查看被测系统的各项性能指标，对指标进行汇总、分析
1个结果统计人员，对10个用户各操作消耗的时长进行汇总，计算其平均值

可以看出，要通过人工来进行性能测试，操作极为繁琐，需要投入的资源非常多。想像一下，如果要测试1000、10000、1000000并发呢？

显然，这种情况下是完全不可能通过投入人力就能解决的。这也就是性能测试工具存在的必要性和诞生的背景。

性能测试工具推荐:

在性能测试工具方面，市面上已经有很多的测试工具可以拿来使用，这里重点给大家推荐 Locust、LoadRunner、Jmeter三款工具，排名不分先后。

从功能特性角度来说，LoadRunner作为一个老牌的性能测试工具，其功能是最全面的，用户群体也是最多的，相应的学习资料也是最丰富的。个人建议如果是刚刚接触性能测试，可以先熟悉LoadRunner，借此来熟悉一些理论上的东西。但是，缺点也是有的，LoadRunner不能跨平台，目前貌似只支持在windows下使用。

因为这工具也没怎么用过，只是了解过，所以在这里不作过多评价。

Jmeter是由Java开发的可在跨平台运行的性能测试工具，除了做性能测试，它也常用于做接口测试。目前市面上大多数的人都在用它来开展性能测试。该款工具的并发机制是基于线程来实现的。有GUI界面操作，也支持命令行调用。功能插件也比较完善，我一般把它用来做接口测试或者接口自动化测试

Jmeter给我的唯一缺点就是灵活度，有点高不成低不就的味道。也可能我没有对Jmeter进行一个系统的学习吧。

**Locust**是由Python开发的一款性能测试库，性能测试过程皆是采用Python脚本描述，并且HTTP请求完全基于Requests库。除了HTTP(S)协议，Locust也可以测试其它任意协议的系统，比如：websocket、Thrift、RPC协议等等，只需要采用Python调用对应的库进行请求描述即可。需要强调的是Locust的并发机制摒弃了进程和线程，采用协程（gevent）机制。

这款工具testing还是比较推荐的，因为去年在实际的性能测试项目实践testing使用的就是这个框架，在灵活度上比LoadRunner及Jmeter高很多。但是缺点也还是有的，比如报表功能太简单，有些数据没有进行收集，使用的人群少，出现问题也只能自己鼓捣等。

资源监控工具推荐:

既然有性能测试工具，也肯定有资源监控工具啦！下面推荐二款用过的。一款是nmon，一款是grafana软件。

nmon是一款帮助收集服务器的各项硬件资源信息的工具。觉得，这款工具在操作上还是有些繁琐的。安装后需要命令行运行，然后在收集信息的同时不能实时监控服务器资源；收集信息完后还需要导出收集结果在去nmon官方的一个可视化工具里处理形成可视化报表。

是不是觉得很麻烦，所以后面一直在找一个可替代的工具。后面就发现了Grafana。

Grafana是一款强大的监控工具，使用Grafana可以自定义自己的监控指标，但是Grafana官方提供了非常多的实用模板，使用官方的模板是一个快速开启监控的好办法哦。比如我监控Linux服务器资源，我可以使用Grafana+Prometheus+Node Exporter进行监控，而且是实时的，也支持报表导出等。如果我想监控Mysql，我可以使用Grafana+mysqld_exporter+Prometheus进行监控。这样监控都在Grafana。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：