性能测试指南
性能测试指南
概念
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。
- 负载测试是模拟实际软件系统所承受的负载条件的系统负荷，通过不断加载（如逐渐增加模拟用户的数量）或其它加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源（如CPU、内存）等，以检验系统的行为和特性，以发现系统可能存在的性能瓶颈、内存泄漏、不能实时同步等问题。负载测试更多地体现了一种方法或一种技术。
- 压力测试是在强负载（大数据量、大量并发用户等）下的测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间（如24小时以上）的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。
关键指标
性能测试监控指标主要分为：资源指标和系统指标，资源指标与硬件资源消耗直接相关，而系统指标则与用户场景及需求直接相关
系统性能
重要参数
- 并发数 系统同时处理的请求数/事务数
- 系统吞吐量（Throughput） 吞吐量是指系统在单位时间内处理请求的数量，度量单位是reqeust/s
- 系统延迟（Latency）系统延迟是指系统在处理一个请求或一个任务时的延迟。系统延迟和响应时间的意思大致是一致的。
一般来说，一个系统的性能受到这两个条件的约束，缺一不可。比如，我的系统可以顶得住一百万的并发，但是系统的延迟是2分钟以上，那么，这个一百万的负载毫无意义。系统延迟很短，但是吞吐量很低，同样没有意义。所以，一个好的系统的性能测试必然受到这两个条件的同时作用。
下面的两个概念对比系统吞吐量是更为针对性的定义，虽然和吞吐量的计量单位不同，但基本是成正比的
- TPS Transactions Per Second 即服务器每秒处理的事务数。TPS包括一条消息入和一条消息出，加上一次用户数据库访问。
- QPS Queries Per Second
每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。
它们之间的关系，Throughput(TPS/QPS) = 并发数/平均响应时间
NOTE: 负载测试的目的就是找出这个Throughput(TPS/QPS)的最大值
系统吞吐量评估
找出系统吞吐量的极限后，我们需要估算我们实际对系统吞吐量的需求值，看前者是否能够满足后者。
PV到TPS的转换
日PV对于一个网站，很容易就统计出来。 日PV和TPS之间如何对应？公式就是80%的日PV，发生在T小时内。则公式为：
|
|
性能测试工具Jmeter
原理
Jmeter工具和其他性能工具在原理上完全一致，工具包含4个部分：
- 负载发生器 用于产生负载，通常以多线程或是多进程的方式模拟用户行为
- 用户运行器 通常是一个脚本运行引擎，用户运行器附加在线程或进程上，根据脚本要求模拟指定的用户行为
- 资源生成器 用于生成测试过程中服务器、负载机的资源数据
- 报表生成器 根据测试中霍地的数据生成报表，提供可视化的数据显示方式
测试计划元件
- 测试计划(Test Plan) 用来描述一个性能测试，包含与本次性能测试所有相关的功能。也就说本的性能测试的所有内容是于基于一个计划的。
- Threads(Users) 这个就是我们通常添加运行的线程。通俗的讲一个线程组,，可以看做一个虚拟用户组，线程组中的每个线程都可以理解为一个虚拟用户。线程组中包含的线程数量在测试执行过程中是不会发生改变的。
- 取样器(Sampler) 取样器(Sample)是性能测试中向服务器发送请求，记录响应信息，记录响应时间的最小单元，JMeter 原生支持多种不同的sampler ，如 HTTP Request Sampler 、 FTP Request Sample 、TCP Request Sample 、JDBC Request Sampler 等，每一种不同类型的 sampler 可以根据设置的参数向服务器发出不同类型的请求
- 逻辑控制器(Logic Controller) 逻辑控制器，包括两类无件，一类是用于控制test plan 中 sampler 节点发送请求的逻辑顺序的控制器，常用的有 如果(If)控制器 、switch Controller 、Runtime Controller、循环控制器等。另一类是用来组织可控制 sampler 来节点的，如 事务控制器、吞吐量控制器。
- 配置元件(Config Element) 配置元件(config element)用于提供对静态数据配置的支持。CSV Data Set config 可以将本地数据文件形成数据池(Data Pool)，而对应于HTTP Request Sampler和 TCP Request Sampler等类型的配制无件则可以修改Sampler的默认数据。(例如，HTTP Cookie Manager 可以用于对 HTTP Request Sampler 的cookie 进行管理)
- 定时器(Timer) 定时器(Timer)用于操作之间设置等待时间，等待时间是性能测试中常用的控制客户端QPS的手端。类似于LoadRunner里面的“思考时间”。JMeter 定义了Bean Shell Timer、Constant Throughput Timer、固定定时器等不同类型的Timer。
- 前置处理器(Per Processors) 用于在实际的请求发出之前对即将发出的请求进行特殊处理。例如，HTTP URL重写修复符则可以实现URL重写，当RUL中有sessionID 一类的session信息时，可以通过该处理器填充发出请求的实际的sessionID 。
- 后置处理器(Post Processors) 用于对Sampler 发出请求后得到的服务器响应进行处理。一般用来提取响应中的特定数据(类似LoadRunner测试工具中的关联概念)。例如，XPath Extractor 则可以用于提取响应数据中通过给定XPath 值获得的数据。
- 断言(Assertions) 断言用于检查测试中得到的相应数据等是否符合预期，断言一般用来设置检查点，用以保证性能测试过程中的数据交互是否与预期一致。
- 监听器(Listener) 这个监听器可不是用来监听系统资源的元件。它是用来对测试结果数据进行处理和可视化展示的一系列元件。 图行结果、查看结果树、聚合报告。都是我们经常用到的元件。
对于Jmeter这些组件可以这样理解。 配置测试计划就是通过代码来实现对服务器的访问，代码除了提供了语法级别的循环遍历，条件判断等等，还提供了各种函数库来供我们使用。Jmeter的这些组件其实就是实现了一些语法功能以及包括了各种功能的函数，不同的组件类型对函数的不能功能进行了分组。 另外除了函数，还提供了一些配置文件来控制这些函数的行为，这类组件(Config Element)通常作为子组件配置配置。
后台服务器性能测试实例
台服务器性能测试是通过工具和脚本模出真实用户的请求，通过并发的方式来放大流量测试后台服务器的性能，并记录测试结果数据。所以如何获取和通过工具模拟出单个用户的行为是一个必须首先完成的工作。
获取用户操作对应的接口请求
通过Charles、fiddler等抓包工具，分析用户的一个行为具体有哪些接口请求
模拟用户请求
接下来需要在性能测试工具中模拟模拟出这样的请求。基于棘突的协议类型和工具提供的用法，常见的有两种方式，一是在工具中配置请求，二是通过代码的方法。Jmeter主要是第一种方法，对于HTTP请求可以直接配置各种参数，同时Jmeter还提供了录制的功能。
Jmeter脚本的录制需要使用HTTP(S) Test Script Recorder，它属于非测试逻辑单元，添加需要在工作台才能进行。
Target Controller 指的是作为脚本录制结果的Contorller保存到哪，可以直接保存到测试计划下，也可以保存到HTTP(S) Test Script Recorder下。个人建议先临时保存到HTTP(S) Test Script Recorder下，重新修改组织后，再将最终的Contorlller移动的测试计划下。
Content-type filter和URL Patterns to Include都可以用来过滤需要录制的请求，去除一些不关心的内容。这里需要的是如果请求域名没有指定端口，那么URL Pattern里也需要明确指定80端口，否则无法正确过滤。
Think Time
如果直接执行录制下来的脚本有一个很大的问题。在于真实用户和脚本的不同。脚本如果是基于前面的方法录制的，两个请求的执行时间之间是没有任何的其他的停顿的，其间隔只是依赖于上一个服务的响应时间和测试机发起请求所需的时间。但是显然真实的用户不是机器，他们在做上面每一个步骤的时候都有一个思考的时间，这也是Think Time这个词的意义来源。
Think Time在Jmeter可以通Constant Timer来实现。
构建虚拟用户组
上面介绍的获取和模拟的是单个用户的行为，通过工具放大后其实代表了行为一致的一类用户。但是对于个真实的被测系统，通常有很多种使用方式，并不是每个用户做的步骤都一样，如果想看系统整体的性能，那就需要同时模拟多类不同的用户，这里我们称之为虚拟用户组。
在Jmeter中虚拟用户组通过，线程组来实现。不同的线程组定义不同的用户行为。
