从零开始学习性能测试

学习目标

理解性能测试定义、目的
理解常见性能测试策略
理解性能指标
理解性能测试方法
学习性能测试工具

什么是性能测试

测试中的非功能测试其实范围比较广，性能、稳定性、安全性等都可以放进这个范畴。非功能测试，一般比功能测试门槛高些，多数还是需要掌握一两种测试工具，配合代码能力和超强的问题能力，才能得到开发人员的尊重。功能测试其实也一样，但以性能为基础的非功能测试更能考验测试人员的综合能力。

性能测试主要分类

负载测试、压力测试、并发测试、基准测试、稳定性测试、可恢复性测试。
按LoadRunner中的定义:

负载测试(Load Testing)：不断加压被测系统，直到超过预定指标或者部分资源已经达到饱和不能再加压。其目的是找到系统最大的负载能力，在特定的环境下测试，不断加压，直到系统中部分资源达到极限。
压力测试(Stress Testing)：系统已经达到一定的饱和程度(如CPU磁盘等)，此时系统处理业务的能力，系统是否会出现错误。疲劳测试是压力测试的一种表现形式，一般用于系统稳定性测试。
配置测试(Confguration Testing)：调整系统的软硬件环境，了解各种不同环境对系统的影响从而找到系统的最佳配置。用于系统调优和规划，了解不同因素对系统性能的影响情况。
并发测试(Concurrency Testing)：模拟用户并发访问，测试多用户同时访问某一应用、模块或数据，观察系统是否存在死锁、系统处理速度是否明显下降等其他一些性能问题。
可靠性测试(Reliability Testing)：系统在一定的业务压力下，让系统持续运行一段时间，观察系统是否达到要求的稳定性，必须给出明确的要求，例如系统能够持续无故障运行的时间。持续关注运行状态。
基准测试：在一定软硬件以及网络环境下，模拟一定数量的虚拟用户运行一种或多种业务，将测试结果作为基线数据。在系统调优或系统评测的过程中，通过运行相同业务场景并比较测试结果确定调优是否达到效果或者为系统的选择提供决策数据。
大数据量测试：大数据量测试包括独立的数据量测试和综合数据量测试。独立的数据量测试是指针对某些系统存储、传输、统计、查询等业务进行的大数据量测试。综合数据量测试指系统在具备一个数据量时，在负载压力测试下，考察业务是否能够正常运行的测试。目标：测试数据量较大时系统的性能状况。
疲劳强度测试：疲劳强度测试采用系统稳定运行情况下长时间运行系统的测试。
失效恢复测试：失效恢复测试是针对有冗余备份或负载均衡的系统来说，如果系统局部发生故障，系统对故障如何处理来保证系统可以正常运行启动，并确认用户是否可以继续使用。

性能测试包含的主要内容

工具+计划+监控+调优：性能测试工具更多的是模拟客户端产生压力的工具，其在性能分析和调优方面较弱，需要一些监控和调优工具，才能做好性能测试，性能测试计划也很重要。
经典工具LoadRunner的使用过程：计划测试，测试设计，创建虚拟用户脚本，创建测试场景，运行测试场景，分析结果。

性能测试本身质量

测试工具的稳定性，测试环境的稳定性都可以用做考核工具本身。需求定义时的性能指标需要同步提出，比如CPU利用率低于68%，响应时间不超过1秒，每秒请求数目达到单机1万QPS，跑7*24小时系统稳定性成功率达到99.999%等。

常见性能测试指标

响应时间（服务器响应时间，网络响应时间，客户端响应时间），吞吐量（请求和结果，数据库吞吐量，网络吞吐量，单位时间处理的请求事务数），资源使用（CPU占有率，内存使用率，磁盘读写，网络读写），点击数（PV，UV），并发用户数。

注：PV是页面访问量，即PageView，用户每次对网站的访问均被记录，用户对同一页面的多次访问，访问量累计；UV是UniqueVisitor，独立访客数，指访问某个站点或点击某个网页的不同IP地址的人数，访问网站的一台电脑客户端为一个访客

性能测试开始和结束时间

一般在需求分析阶段就开始介入，到最后一个版本测试完成，得出性能报告，才算是一个需求的终结。研发阶段如何安排呢？一般情况下在编码过程中进行并发测试、压力测试和配置测试，因为此阶段可以快速发现性能的问题；编码结束后的测试阶段，对系统的稳定性调优，达到系统最优性能，进行负载测试、基准测试和配置测试。

关注性能的三类

用户：关注软件系统对用户请求的响应时间
运维和测试工程师：关注响应时间+资源消耗+硬件资源可扩展性
开发工程师：关注代码所有问题，包括内存泄露、死锁、中间件以及应用服务器框架等

性能测试消耗的资源包括时间、物力、财力、性能测试中发现的bug数目及各自的差别，系统交付用户，用户在生产环境运行后发现的性能bug数目和级别。

为什么要进行性能测试

1、保证产品性能质量

海量用户访问下，系统稳定运行
硬件服务器选型，该软件运行依赖的机器配置
软件技术架构的选型

2、进阶高级测试开发的技能要求

性能：本质上是指软件在服务器上运行时，该服务器的健康状态、稳定性、资源使用率、性能强弱等，这些都是指服务器的性能

轻松理解性能

如何开始性能测试

使用自动化工具(因为人工操作难以实现批量、大规模操作)，模拟不同的场景，对软件运行过程中产生的各项性能指标采集、评估。
性能测试的对象：

后端程序(网站后台代码)
中间件(应用服务器)
数据库
服务器资源

性能测试目的

1、评估系统能力

验证软件能力
获取软件运行的性能指标，与同类型软件对比(比如手机跑分)

2、发现性能问题，寻找瓶颈原因，进行优化。(12306软件)

3、评估软件是否能满足未来某一时刻的性能需要。(春运时的压力)

性能与功能比较

焦点：
1、功能：关注系统功能，是否满足用户需求

按正确使用说明，测试软件
以反面角度，测试功能结果

2、性能：关注软件运行性能

软件运行响应时间、耗时
运行损耗资源情况

关系：

功能通过之后，开展性能测试

基准测试

在一定软硬件以及网络环境下，模拟一定数量的虚拟用户运行一种或多种业务，将测试结果作为基线数据。在系统调优或系统评测的过程中，通过运行相同业务场景并比较测试结果，确定调优是否达到效果或者为系统的选择提供决策数据。简单说就是：单个用户进行业务场景的测试，统计性能各项指标，后续与多用户测试做对比。在某一时刻进行性能测试，得到一个性能水平统计，软件发生变化后，再观察对性能的影响。

负载测试

不断加压被测系统，直到超过预定指标或者部分资源已经达到饱和不能再加压，其目的是找到系统最大的负载能力，在特定的环境下测试，不断加压，直到系统中部分资源达到极限。
通过负载测试找到系统的最佳负载以及最大负数。

稳定性测试

系统在一定的业务压力下，持续运行一段时间，观察系统是否达到要求的稳定性，必须给出明确的要求，例如系统能够持续无故障运行的时间。
持续关注运行状态，如持续一周的稳定压力下，查看软件能否稳定运行，服务器资源使用率是否健康。

并发测试

模拟用户并发访问，测试多用户同时访问某一应用、模块或数据，观察系统是否存在死锁，系统处理速度是否明显下降等其他一些性能问题。
短时间内，同时处理大量请求，查看系统并发处理能力。

压力测试

系统已经达到一定的饱和程度(如CPU磁盘等)，此时系统处理业务的能力，系统是否会出现错误。

疲劳测试是压力测试的一种表现形式，一般用于系统稳定性测试。
系统在强负载情况下，测试系统在高压下是否还能良好运转，以及良好的容错能力和恢复能力。

稳定性压力测试：高负载情况下，接近c点；长时间如24小时的运行，查看系统处理能力

破坏性压力测试：验证系统极限状态，c-d点区间，查看系统容错能力，以及恢复能力。

性能测试指标

响应时间RT

请求的响应时间(Response Time)：从客户端发出请求到得到响应的整个时间，包括网络响应时间 + 应用程序响应时间。

用户接受准则：2~5~10(或3~5~8或2~5~8)原则，例如2~5~10原则，即按照正常用户体验，如果用户能够在2秒内得到响应，会感觉速度很快，如果 2~5 秒得到响应，用户感觉系统的响应速度还行，在 5~10秒之内得到响应时，用户会感觉系统的响应速度慢但是可以接受，超过10秒后还没有响应，用户很难能够接受。

不同行业不同业务可接受的响应时间是不同的，一般情况，对于在线实时交易：

互联网企业：500毫秒以下，例如淘宝业务10毫秒左右。
金融企业：1秒以下为佳，部分复杂业务3秒以下。
保险企业：3秒以下为佳。
制造业：5秒以下为佳。

PS：数据来自于阿里云规范

系统处理能力

系统处理能力是指系统在利用硬件平台和软件平台进行信息处理的能力。系统处理能力通过系统每秒钟能够处理的交易数量来评价，交易有两种理解:

一是业务人员角度的一笔业务过程
二是系统角度的一次交易申请和响应过程

前者称为业务交易过程，后者称为事务。两种交易指标都可以评价应用系统的处理能力。一般建议与系统交易日志保持一致，以便于统计业务量或者交易量。系统处理能力指标是技术测试活动中重要指标。

并发数

并发测试的用户数量

系统用户数：系统注册总用户数据

在线用户数：某时间内访问系统的总用户，但这些用户不一定同时向系统提交请求。如，夜里3点，访问淘宝的用户有2000万个，但下单用户有100万个

并发用户数：如12点秒杀活动，12:00整点有一万个用户同时向系统发来请求

吞吐量TPS

TPS(Transaction per second)吞吐量：系统每秒处理事务(原子性、一致性、隔离性、永久性)数，单位是笔/秒。特点是不可分割的，要么完全成功，要么完全失败。另外，每秒获取的数据量的大小，也称为吞吐率。

TPS是衡量服务器性能好坏的直接指标
只登录操作：发送登录请求，对应一个登录接口
支付操作：查询余额 + 支付安全校验 + 支付事务 = 3个接口

TPS是一项关键指标，用来描述每秒事务数，可以反应出一个系统的处理能力。但是，TPS 在不同的行业、不同的业务中定义的粒度都是不同的。所以不管你在哪里用TPS，一定要有一个前提，就是所有相关的人都要知道你的 T 是如何定义的。

如图所示，一个业务流程图：

如果要单独测试接口1、2、3，那么 T 就是接口级的。
如果我们要从用户的角度来下一个订单，那1、2、3应该在一个 T 中，这就是业务级的了。

结合上述示例，再次理解下：你要创建什么级别的事务，完全取决于测试的目的是什么。另外，在测试过程中，通常是先接口级、后业务级的顺序，容易定位问题。

执行数QPS

QPS(Query per second):系统每秒处理查询次数，单位是次/秒。
QPS一开始是用来描述MySQL中SQL每秒执行数，所有的SQL都被称为Query。后来，由于一些文章的转来转去，QPS被慢慢地移到了压力工具中，用来描述吞吐量。如果描述的是前端的每秒查询数，那就不包括插入、更新、删除操作了。显然这样的指标用来描述系统整体的性能是不够全面的，所以不建议用QPS来描述系统整体的性能。

点击数HPS

点击数指的是访问网页HTML时，html，jpg，css，js加载时，向服务器发送的请求数量用于衡量Web服务器的处理能力

错误率

错误率指的是在高负载情况下，业务出错的次数/业务总次数*100%

资源利用率

服务器硬件的资源使用率：资源使用量 /总资源量*100%

利用率是与组件可用的总时间相比，该组件实际被占用的时间的百分比。例如，如果CPU在1分钟内总共耗用40秒的时间处理事务，那么它在该时间间隔内的利用率为67%。

定期评估并记录以下系统资源的利用率：

CPU
内存
磁盘

当某资源被过度使用或者它的利用率与其他组件的利用率不成比例，那么就说该资源对于性能是临界的。例如：当一个磁盘的利用率达到 70%，而系统中其他所有磁盘的利用率只有 30% 的时候，可以认为该磁盘是临界的或被过度使用的。尽管 70%不表示磁盘使用严重过度，但是您可以通过重新安排数据以平衡整组磁盘上的I/O请求，从而提高性能。

如何评估资源利用率取决于操作系统为报告系统活动和资源利用率所提供的工具。发现资源似乎使用过度后，就可以使用数据库服务器提供的性能监视实用程序来收集数据，并对可能占用该组件上负载的数据库活动进行干涉。可以调整数据库服务器的配置或操作系统，以减少那些数据库活动或将它们分散到其他组件中。某些情况下，可能需要提供额外的硬件资源来解决性能瓶颈问题。

资源利用率

只要系统资源(例如CPU或特定磁盘)被事务或查询占用，资源就无法用来处理其他请求。暂挂的请求必须等待资源变得可用，然后才可完成。

CPU 利用率

对CPU利用率和响应时间的估计可以帮助您确定是否需要消除或重新调度某些活动。

内存利用率

内存不是作为单个组件(例如CPU或磁盘)管理的，而是作为称为页的小型组件的集合进行管理

磁盘利用率

由于磁盘之间的传输速率各不相同，大多数操作系统都不直接报告磁盘利用率。相反，它们报告每秒的数据传输量(以操作系统内存页大小为单位)。
参考：资源利用率和性能

Jmeter

Apache JMeter是Apache组织的开源项目，是一个纯]ava桌面应用，用于压力测试和性能测试，它最初被设计用于web应用测试，后来逐渐的扩展到其他领域。

jmeter可以用于对静态和动态的资源(文件、Servlet、Perl脚本、Java对象，数据库查询、FTP服务器或者是其它资源)的性能进行测试。jmeter可以用于分析不同压力条件下的总体性能情况。也可以使用jmeter提供的图形化界面分析性能指标。

Servlet(Server Applet)是Java Servlet的简称，称为小服务程序或服务连接器，用]ava编写的服务器端程序，具有独立于平台和协议的特性，主要功能在于交互式地浏览和生成数据，生成动态web内容。

对比Loadrunner

Loadrunner

工业级性能测试工具，可以模拟大量用户并发，且监控性能指标，生成报表
优点：

并发量大
结果报表
支持IP伪装

缺点：

收费
体积大，功能太多
无法定制化

Jmeter

功能与Loadrunner基本相同
优点：

免费
体积小
可扩展，由Java开发

缺点：

功能性稍弱，毕竟Loadrunner是收费的

安装Jmeter

要求：Requires Java 8+
参考:

jmeter历史版本下载：Index of /dist/jmeter/binaries
jmeter最新版本下载：Apache JMeter - Download Apache JMeter

一般的，zip包适用于Windows平台，tgz包适用于linux和Mac平台。

需提前准备好相关软件包：

jmeter
java
无论哪个平台安装jmeter，都依赖java环境，所以，根据你的系统，优先配置java环境，下图为配置好的java环境

后续的操作默认你已经配置好java环境了，默认的所有imeter版本都为5.6.3

Jmeter软件目录

bin目录：启动目录和配置文件目录

jmeter.bat：Windows平台的启动文件。
jmeter.log：日志文件。
jmeter.sh：Linux平台的启动文件。
jmeter.properties：系统配置文件。
jmeter-server.bat：Windows平台测试要用到的服务器配置，
jmeter-server：Linux平台分布式测试用到的服务器配置，

docs：接口文档目录。
extras：扩展插件目录。
lib：依赖插件目录，其中全是jar包，jmeter会自动在JMETER_HOME/lib 和 ext 目录下寻找需要的类。
licenses：jmeter证书目录。
printable_docs：用户使用手册。

bin文件下运行jmeter.bat，启动jmeter

当启动后出现如上页面，表示java环境配置成功，jmeter启动完成。

基本配置

软件中变更窗口颜色和语言，只有当前使用的时候会变更，下次运行软件时，语言还是会恢复到默认配置。若想默认配置按照自己平常喜欢的样式来设置，就需要修改配置文件。如下：

bin文件下找到jmeter.properties，打开方式选择记事本方式打开：

语言默认en，改成zh_CN，保存后即可。

各功能描述

菜单栏：无需多言，对软件的各种设置。
快捷按钮栏：

新建：新建测试计划。
打开：打开保存测试计划。
保存：保存测试计划。
切换：当有多个线程组的时候，可以通过切换来指定那些线程组的禁止运行，即代码注释一样。
启动：运行测试计划内的线程组。
清除/全部清除：当线程组被执行后，可以在查看结果树中查看执行结果，通过这两个按钮来清除执行结果。
函数助手对话框：jmeter内置了很多的函数，如生成UUID、时间戳等函数，都管理在该对话框内并且可以通过下载插件来丰富该对话框。
JMeter Plugins Manager：jmeter插件管理中，管理扩展插件。

日志

当执行线程组时，会在快捷按钮栏的右侧，展示执行的日志结果。

测试计划

测试计划可以理解为一个容器，存放所有的线程组以及所有的测试内容，你的测试内容都基于测试计划。

名称/注释：给该测试计划命名和测试计划内容描述
用户定义的变量：在jmeter中，除了内置的一些变量，我们也可以在这里定义一些变量，这些变量作用于全局。
独立运行每个线程组：默认当执行测试计划时，多个线程组会并发的执行，如果勾选该项，表示从上到下依次执行线程组。
添加目录或者jar包到ClassPath：当有需要使用外部的目录或者jar包时，都在此添加。

线程组

一个测试计划下可以有多个线程组，大部分的测试内容都在线程组内实现。

如上图，jmeter提供了四种线程组：
1、线程组：普通线程组，也是用的最多的线程组，在该线程组内实现主要的测试任务。
2、setUp线程组：一种特殊类型的线程组，用于在执行常规线程组(Thread Group)之前执行一些必要的操作，这个线程组下的线程行为与常规线程组完全一致，不同的是执行顺序，它会在常规线程组执行之前被触发。主要的应用场景有：

测试数据库时，可以用来执行数据链接等操作
获取前置数据，如依赖的token和cookies

3、tearDown线程组：一种特殊类型的线程组，用于在常规线程组完成后执行一些必要的操作，这个线程组下的线程行为与常规线程组完全一致，不同的是执行顺序，它会在常规线程组执行之后被触发。主要应用场景:

关闭数据连连接
处理其他善后操作

4、开放模型线程组：它允许用户创建具有可变负载的负载配置文件。相较于传统的线程组，开放模型线程组提供了更多的灵活性和动态调整的能力。但是配置复杂，需要一定的经验。

这里主要来介绍普通的线程组，当你如上图的操作，选中测试计划右键添加一个普通的线程组时，会得到如下界面：

各参数介绍：
名称/注释：给该线程组命名的名称和测试工作的描述。
在取(采)样器（取样器就是指让线程做的事）错误后要执行的动作：

继续：忽略错误，继续执行。
启动下一个进程循环：忽略错误，结束当前循环的线程，执行下一次循环。
停止线程：停止当前线程，不影响其他的线程执行。
停止测试：当正在执行的线程执行完毕后，停止整个测试计划。
立即停止测试：整个测试计划会立即停止。

线程属性：

1、线程数：并发用户数量，每个线程可以认为就是一个虚拟用户，即多个用户同时去做同一个操作；线程之间是互不影响的，线程A中修改的变量值，不会影响到线程B。
2、Ramp-up时间(秒)：设置启动所有线程所需要的时间。如线程数设置为5，启动所有线程所需要的时间设置为1，意思为5个线程要在1秒内启动完成。

模拟性能测试场景，尽可能贴近用户习惯(如用户访问网站的时长)

3、循环次数(建议不要勾选永远)：设置线程组内线程执行的次数。如果线程数设置为5，循环次数设置为2，那么线程组内的每个线程都会执行2次，所有线程共执行了10次。

永远：勾选该选项，测试计划就会一直执行下去，不要勾选，容易被检测出蓄意破坏

4、same user on each iteration：每次迭代使用相同的线程，即线程复用，默认勾选即可。

5、延时创建线程直到需要：勾选后，只有需要线程了才会创建。(无需关注，使用少)。
6、调度器：搭配永远选项使用，有的时候，要长时间对系统进行压测，那么就要勾选永远选项，并且为永远选项添加配置：

持续时间(秒)：如要对系统持续压测1小时，那么就要在此填写3600，在3600秒后结束执行。
启动延迟(秒)：设置线程启动延时时间，是指多少秒后才开始启动所有线程，但并不是说每个线程都延迟多少秒启动。

基本元件（取样器）

jmeter内置有很多的取样器，用来模拟各种场景下发送请求的操作。

取样器——元件，可以理解取样器就是编程中定义的一个类

HTTP请求——组件，类中定义方法

理解：jmeter是java开发的程序，功能也是由代码实现而来，理念其实是一样的，把jmeter想象成java程序，测试计划就好比是一个大的功能模块，线程组就好比测试这个功能模块中某一个方法的脚本文件，元件就像这个程序，你定义了面向对象的开发模式，定义了功能类。

其他元件（定义其他类）

取样器：发送请求，类似自动化中的业务测试语句。
逻辑控制器：控制元件执行顺序，类似于自动化中的逻辑控制语句（if，while）。
前置处理器：对发送的请求参数进行预处理，类似于自动化中的参数化。
后置处理器：对收到的响应数据进行处理，类似于自动化中获得对应的测试结果（断言）。
定时器：等待一定时间，类似于自动化中的sleep语句。
测试片段：封装的脚本，供其他脚本调用。类似于自动化中封装的函数。
配置元件：测试前的环境及数据配置，类似于自动化中的初始化动作。
监听器：查看测试的结果。类似于自动化中的日志和报告。

Jmeter使用流程

启动Jmeter软件
测试计划下添加线程组
线程组添加HTTP请求、取样器
填写HTTP请求的数据
线程组添加，查看结果树，监听器
启动，查看结果

注：jmeter关键测试步骤：

先定义测试计划（准备测什么）
创建线程组（模拟大量用户访问网站），线程指的就是用户
决定用什么样的协议去访问什么样的接口（如http、https协议去访问api）

案例一：发送HTTP请求

访问www.baidu.com，类似浏览器访问

协议不填默认HTTP
端口不填默认80
填入GET请求的参数

在HTTP请求添加监听器，选择查看结果树，该结果只作用与当前请求，不影响别的线程组中的请求。

案例二：发送POST请求

将HTTP请求改为POST，执行查看结果

发POST请求成功。

独立运行每个线程组

如果不勾选该项，首先创建三个线程，在大的测试计划下建查看结果树，初始先设置第一个访问百度的线程，设置线程数为1，第二个访问淘宝的线程，设置线程数为2，第三个访问京东的线程，设置线程数为3，运行我们来看看结果：

通过上图可以看出，因为每一个线程都是并行运行的原因，并不是按照顺序执行的，所以给人直观感觉很错乱，如果线程数过多，若有失败线程出现，第一眼很难确定是哪个线程出了问题。

如果勾选该项，再来看看运行结果：

按照从上到下的线程中取样器，顺序执行，结果也和该顺序一致。