什么是性能测试?

性能测试针对系统的性能指标，建立性能测试模型，制定性能测试方案，制定监控策略，在场景条件之下执行性能场景，分析判断性能瓶颈并调优，最终得出性能结果来评估系统的性能指标是否满足既定值。

性能测试的目的

• 压测系统看系统的前端以及后端是否满足预期
• 压测系统看系统是否可以承受的最佳压力和最大压力，来判断系统的承受极限
• 压测系统看系统在长时间运行下是否可以正常处理请求（疲劳测试）
• 容量规划

性能测试分类

一般性能测试

• 一般性能测试主要验证软件在正常环境和系统条件下，即不施加任何压力情况下重复使用系统验证其是否能满足性能指标，如响应时间、系统资源占有情况等。
• 性能基准测试，较早进行。

负载测试

• 负载测试主要是在“基于或模拟系统真实运行环境及用户真实业务使用场景”情况下，通过不断给系统增加压力或在一定压力下延长系统运行时间，来验证系统各项性能指标的变化情况，直到系统性能出现“拐点”，即某个性能指标达到了事先约定的指标阈值（极限值）。

压力测试

压力测试主要是在“模拟系统已处于极限负载下或某指标已经处于饱和状态”情况下，继续给系统增加负载或运行时间，观察系统性能表现，验证系统是否出现内存泄露、系统宕机等严重异常。

大数据量测试

• 大数据量测试主要是指使用大批量数据对系统产生压力或影响，同时验证系统各项指标运行是否正常。
  • 某些容器（如数据库、存储设备等）中有较大数量的数据；
  • 进行并发或某些操作时动态创建大量数据。

配置测试

• 通过对被测系统的软硬件环境的调整，了解各种不同对系统的性能影响的程度，从而找到系统各项资源的最优分配原则。
• 正交实验法进行用例设计
• 目的：了解各种不同因素对系统性能影响的程度。

稳定性测试

• 稳定性测试主要强调的是连续运行被测系统，检查系统运行时的稳定程度。通常采用MTBF(错误发生的平均时间间隔）来衡量系统的稳定性，MTBF越大，系统的稳定性越强。

性能测试术语

虚拟用户

Vuser→真人

并发及并发用户数

• 并发：大量用户且同时对服务器的操作
  • 系统允许500个用户并发访问系统
  • 系统支持500个用户并发进行登录操作
• 系统用户数：系统可有1000个使用用户
• 在线用户数：系统允许800个用户同时在线
• 参考公式：使用系统的用户数量*（5%~20%）

响应时间

• 请求响应时间：从客户端发出请求到得到响应的整个过程的时间，单位通常为“秒”或“毫秒”。网络响应时间 + 服务器端响应时间 TTLB(Time to last byte)
• 事务响应时间：完成该事务所用的时间。其包含一个或多个“请求响应时间”。
• 事务相应时间>=请求响应时间

每秒事务数

• TPS指每秒钟系统能够处理的交易或事务的数量。
• 取款业务成功率达到1000次/s。

吞吐量、吞吐率

• 吞吐量：单次业务中，客户端与服务器端进行的数据交互总量。通常，该参数受服务器性能和网络性能的影响。
• 吞吐率：吞吐量除以传输时间。
• 吞吐量也被称为TPS（单位时间内能完成的事物数）
• exa：1个用户登录需要1秒，支持10个用户登录，且响应时间为1秒，
  则系统吞吐率为10个/秒

点击率

• HPS指每秒钟内，用户向Web服务器提交的HTTP请求数。
• 点击率越大，表明对服务器产生的压力也越大

性能计数器

• 一系列用于描述各类服务器或操作系统性能的指标，在进行资源监控和系统瓶颈分析中起着重要的作用。
• 在Windows任务管理器中使用的内存数（Memory In Usage）、CPU使用率（%Processor time）、进程时间（Total Process Time）。

资源利用率

3000用户并发进行登录操作时，服务器的CPU使用率不超过75%，内存占有率不超过10%”

上图横坐标是并发用户数
绿线是CPU使用率；
紫线是吞吐量，即tps；
蓝线是响应时间

性能测试流程

测试计划阶段

1. 明确测试对象
2. 定义测试目标
3. 定义测试通过的标准
4. 规划测试进度
5. 规划测试参与人员（需求、开发、测试、运维和配置）
6. 申请测试资源
7. 风险控制

测试设计阶段

1. 设计测试用例
2. 设计测试数据
3. 设计测试场景

测试开发阶段

1. 测试环境搭建
2. 测试过程文档定义以及配置
3. 测试脚本开发、调试
4. 测试数据准备
5. 基准测试

测试执行阶段

1. 执行测试用例模型，包括执行脚本和场景
2. 测试过程监控，包括查看log、监控服务器资源、数据库和中间件等

测试结果阶段

1. 根据测试结果和监控结果进行测试分析
2. 根据性能测试目标，分析出系统存在的性能瓶颈，并给出优化建议

测试报告阶段

1. 测试范围
2. 测试执行以及参与人员
3. 基准测试数据
4. 测试执行的详细步骤
5. 场景设计）
6. 测试数据记录、监控结果
7. 测试结果对比以及总结性评价

常见的性能问题

资源泄露

• 包括内存泄漏。系统占用的资源（如内存、CPU等）随着运行时间的不断增长，而降低了系统性能。系统响应越来越慢，甚至系统出现混乱。只有重启系统才能恢复到最初水平。
• 这类问题产生的主要原因是有些对象（如GDI使用、JDBC连接等）没有及时被销毁、内存没有释放干净、缓冲区没有回收等。

资源瓶颈

• 内部资源（线程池、连接池）变得稀缺。随着负载增加，系统越来越慢甚至系统挂起或出现异常错误。
• 这类问题产生的主要原因是线程过度使用或资源分配不足。

CPU使用率达到100%、系统被锁定等。

• 代码中可能存在无限循环、缺乏保护（如对失败请求不断的重试）等问题，
• 对网络应用系统，问题常常出现在数据库服务器上，如频繁对数据库存取、未使用连接池或者连接池配置参数不当、单个SQL请求的数据量过多、没有使用高速缓存等。

线程死锁、线程阻塞等造成系统越来越慢，甚至系统挂起或出现异常错误、系统混乱局面等。

• 可能是由程序对事务并发处理上的错误、 资源争用引起锁阻塞和死锁等引起的
• 例如线程获得顺序的算法不对而造成死锁、线程同步点上备份过多而造成通信阻塞等

查询速度慢或列表效率低

主要原因是列表查询未使用索引、过于复杂的SQL语句、分页算法效率低等；也可能是查询结果集过大或不规范的查询，如查询全部字段而不是所需字段、返回全部的数据等。

受外部系统影响越来越大，最终造成应用系统越来越慢

主要原因有向后端系统发出太多的请求、页面内容过多、经第三方系统认证比较复杂、网络连接不稳定或延迟等。

JMeter简介

JMeter是免费、开源、纯Java开发的性能测试工具，JMeter可以用于对服务器、网络或对象模拟巨大的负载，来自不同压力类别下的测试它们的强度和分析整体性能。能够对应用程序做功能/回归测试，通过创建带有断言的脚本来验证你的程序是否返回了你期望的结果，JMeter允许使用正则表达式来创建断言。
JMeter官网

JMeter特点

• 能够对HTTP和FTP服务器进行性能测试，也可以对任何数据库进行同样的测试（通过JDBC）
• 完全的可移植性和100%纯java
• 完全多线程框架，允许通过多线程开发取样和通过单独的线程组对不同的功能同时取样
• 各种负载统计表和可链接的计时器可供选择
• 数据分析和可视化插件提供了很好的可扩展性以及个性化
• 具有提供动态输入到测试的功能

JMeter安装

• JMeter是Java应用程序，需要有JDK环境
• 官网下载：http://JMeter.apache.org

JMeter目录结构分析

• Bin:放置了各项配置文件（如JVM设置、日志设置）、启动文件、示例脚本等
  • JMeter.properties:JMeter的系统配置文件，可以针对JMeter做各种配置操作，比如：远程负载机等
  • remote_hosts=127.0.0.1
  • remote_hosts=127.0.0.1:1099,172.168.1.13:1099, 172.168.0.16:1099
  • server_port=1099
• Docs:放置了JMeter API离线帮助文档
• Extras：JMeter辅助功能，提供与Ant、Jenkins集成的可能性，利用Ant与Jenkins来构建性能测试自动化构架
• Lib: JMeter组件以jar包形式放置在lib/ext目录下，如果要扩展JMeter组件，扩展后的jar包即放在此目录
• printable_docs：JMeter的离线帮助文件放置目录

JMeter工作区介绍

• 区域1：目录树，存放测试设计过程中使用到的元件；
  • 执行过程默认从根节点开始顺序遍历树上的元件
  • 元件：比如HTTP请求就是一个元件
• 区域2：菜单栏，图标是菜单快捷方式
• 区域3：测试元件编辑区域

JMeter常用功能

• 测试计划：用来描述一个性能测试，所有内容都是基于这个计划的。
• 线程（虚拟用户）
  • 一般线程组：设置JMeter按照什么场景来运行（添加/Threads/线程组)
  • setUp Thread Group：可用于执行预测试操作。这些线程行为完全像一个正常的线程组元件。类似于LR 的init方法。
  • tearDown Thread Group：可用于执行测试后动作。这些线程的行为完全像一个正常的线程组元件。类似于LR的end方法。
  • Sampler取样器：是性能测试中向服务器发送请求，记录响应信息，记录响应时间的最小单元，JMeter原生支持多种不同的Sampler
  • 逻辑控制器：用来控制测试脚本的逻辑判断，编程中的逻辑控制if，循环等。
  • 定时器：设置操作之间的等待时间，一旦设置，对所有请求有效。
  • 前置处理器：发送请求之前的处理，例如参数化。
  • 后置处理器：发送请求之后得到的服务器响应进行处理（LR关联）。
  • 断言：对实际结果和预期结果的判断（LR检查点）。
  • 监听器：对测试结果进行可视化展示。

JMeter运行原理

JMeter以线程方式运行，通过线程组来驱动多个线程（类似LoadRunner中的
虚拟用户）运行测试脚本对被测试服务器发起负载，每个负载机上都可以运行
多个线程组。

JMeter使用

创建测试计划

• 测试计划：是JMeter测试的起点，是存放脚本的容器，JMeter中一个脚本即是一个测试计划。
• 测试计划四要素：
  • 脚本中计划只能有一个
  • 至少要有一个线程组
  • 至少有一个取样
  • 至少有一个监听器
• 在测试计划里面可以配置用户的一些全局变量
• 独立运行每个线程组：一个测试计划下面可能会包含多个线程组，勾选此项的话，则会顺序执行每个线程组，而不是同时启动所有的线程组

新建线程组

• 线程组：相当于有多个用户，同时去执行相同的一批次任务。每个线程之间都是隔离的，互不影响的。一个线程的执行过程中，操作的变量，不会影响其他线程的变量值
• 启动线程组的方法：
  • Test Plan 右键——Adds——Threads—Thread Group

开发脚本

手工书写、JMeter使用代理方式录制

Http请求设置-保持默认

• 名称：用于标识一个取样器，建议采用一个有意义的名称。
• 注释：对于测试没有任何作用，仅记录用户可读的注释信息。
• 端口号：目标服务器的端口号，默认80。
• 协议：向目标服务器发送HTTP请求时的协议，可以是https或者是http，默认是http。
• 方法：发送http请求的方法，可用方法包括GET、HEAD、POST、PUT、OPTIONS、TRACE、DELETE等。
• Content encoding：内容的编码方式。
• 路径：目标URL路径（不包括服务器的地址和端口）
• 自动重定向：如果选中该选项，当发送HTTP请求后得到的响应是302/301时，JMeter自动重定向到新的页面
• Use keep Alive：当该选项被选中时，JMeter和目标服务器之间是有Keep-Alive方式进行HTTP通信，默认选中。
• Use multipart/from-data for HTTP　POST：当发送HTTP POST 请求时，使用Use multipart/from-data 发送，默认不选中。
• 同请求一起发送参数：在请求中发送URL参数，对于带参数的URL，JMeter提供了一个简单的对参数化的方法。用户可以将URL中所有参数设置在本表中，表中的每一行是一个参数值对（对应URL中的名称1=值1）
• 同请求一起发送文件：在请求中发送文件，通常，HTTP文件上传行为可以通过这种方式模拟。
• 从HTML文件获取所有内含的资源：选中时，JMeter在发出HTTP请求并获得响应的HTML文件内容后，还对该HTML进行Parse并获取HTML中包含的资源。默认不选中，如果用户只需要获取页面中的特定资源，可以在下方中的URLs must match文本框中填入需要下载的特定资源表达式，这样，只有匹配成功的资源才会被下载。
• 用作监视器：此取样器被当成监视器，在Monitor Results Listener中可以直接看到基于该取样器的图形统计信息。默认不选中。
• Save response as MD5 hash：选中时，在执行时仅记录服务器端响应数据的MD5值，而不记录完整的响应数据。在需要进行数据量大的测试时，建议选中该项以减少取样器记录响应数据的开销。

线程组设置

• 线程数：虚拟用户数
• ramp up period:设置的虚拟用户需要多长时间全部启动。如果线程数为20，时间为10，也就是每秒钟启动2个线程
• 循环次数：每个线程发送请求的次数。如果线程数为20，循环次数为100，那么每个线程发送100次请求。总请求数为20*100=2000。如果勾选了“永远”，那么所有线程会一直发送请求，直到选择停止运行脚本。
• 调度器：可以灵活设置运行时间
• Scheduler：调度器
  • Duration（seconds）：持续时间，测试计划持续多长时间
  • Startup delay(seconds):启动延时。点击启动按钮后，仅初始化场景，不运行线程，等待延时时间到才运行

运行场景

查看监控

JMeter 中使用监听器元件收集取样器记录的数据并以可视化的方式来呈现。JMeter有各种不同的监听器类型，这里添加聚合报告来查看结果

聚合报告

• 注意：单位是毫秒，后缀是jtl
• Label：定义请求的名称，就是我们在进行测试的httprequest sampler的名称
• Samples：这次测试中一共发给服务器的请求数量
• Average：单个请求的平均响应时间，单位是毫秒。当使用了Transaction Controller时，也可以以Transaction 为单位显示平均响应时长。
• Median：中位数，50%的请求的响应时间
• 90%Line：90%的请求的响应时间
• 95%Line：95%的请求的响应时间
• 99%Line：99%的请求的响应时间
• Min：访问页面最小的响应时间
• Max：访问页面最大的响应时间
• Error%：错误率=错误的请求的数量/请求的总数
• Throughput:：吞吐量即表示每秒完成的请求数。当使用了Transaction Controller时，也可以表示Transaction per Second数
• Received KB/sec:：每秒从服务器端接收到的数据量

添加监听器

• View Results Tree：如果我们的请求成功发送给服务器，那么结果树里面的模拟请求会显示为绿色，可以通过取样器结果里面的响应状态码信息来判断
• 里面有我们发送的请求的方法、协议、地址以及实体主体数据，以及数据类型，大小，发送时间，客户端版本等信息

Badboy录制脚本

• Badboy是用C++开发的，被用于测试和开发复杂的动态应用。它提供了强大的屏幕录制和回放功能，同时也提供了丰富的图形结果分析功能
• 下载Badboy:http://www.badboy.com.au/
• 使用Badboy录制脚本，然后将录制的脚本导出为JMeter格式的脚本，最后将该脚本导入到JMeter，借助于JMeter强大的测试功能模拟大量的虚拟用户，进行复杂的性能测试
• 在Badboy中，step就类似于Loadrunner中事务的概念，我们可以通过添加
  step的方式来定义事务

1. badboy下载：www.badboy.com.au
2. 点击工具栏上的红色原型按钮，在地址栏目输入被测地址。
3. 录制完成后，点击工具栏旁边的黑色按钮，结束录制。选
   择“文件”/“Export to JMeter”
4. 打开JMeter工具，选择“文件”/“打开”选择刚才保存的
   文件（.jmx类型），将文件导入

代理方式录制脚本

1. 创建模板【录制方式】
2. 配置浏览器的代理为 “127.0.0.1” 端口是8888
3. HTTP(S) Test Script Recorder 点击【run】