性能测试常识05

一.什么是性能测试

性能测试是通过模拟生产运行的业务压力和使用场景的组合，来测试系统的性能是否满足软件的性能要求。即，这种方法就是要在特定的运行条件下验证软件系统的处理能力。

通俗讲，这种方法的前提是要对系统性能已经有了解，并对需求有明确的目标，并在是已经在确定的环境下运行的系统。

性能的表现：

性能测试重点关注有哪些？

选择合适的性能测试工具；

部署一套合适的性能测试环境；

设立实际的性能测试目标；

被测应用程序稳定运行无异常；

有足够的时间进行有效的性能稳定性测试；

确定编写测试业务脚本，提供高质量、可靠的测试数据；

准确的性能测试设计用例；

监控服务器和网络的准确指标；

性能测试的介入时机，一般是在功能、接口测试都已经完成之后再来做性能测试

性能测试使用时机

上新系统：用户场景（大量用户、同时使用、某个时间段内使用）适合用基准测试、负载测试、压力测试、容量测试

扩容：分析了历史系统自身的性能标新，适当的扩容。基准测试、负载测试、压力测试、容量测试

调优：针对以上线的系统越来越慢，对系统进行优化配置，提升性能表现。基准测试、配置测试

修复：解决线上系统的并发死锁、内存泄漏等问题。并发测试

秒杀、团购：基准测试、负载测试、压力测试

二.性能测试的分类：

性能测试包括：基准测试、负载测试、压力测试、并发测试、容量测试、可靠性测试（稳定性测试）、配置测试、失败测试。

1、简述性能测试的8大类，并对这8大类进行描述。

答：

基准测试：在给系统施加较低压力时，查看系统的运行状况并记录相关数做为基础参考

负载测试：是通过逐渐增加系统的负载，测试系统性能的变化，并最终确定在满足系统性能指标的情况下，系统所能承受的最大负载量的测试。简而言之，负载测试是通过逐步加压的方式来确定系统的处理能力和能够承受的各项阈值。

压力测试：是通过逐步增加系统的负载，测试系统性能的变化，并最终确定在什么负载条件下，系统性能处于失效状态，并获得系统能提供的最大服务级别的测试。压力测试是逐步增加负载，使系统某些资源达到饱和甚至失效。

并发测试：测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题，几乎所有的性能测试都会涉及一些并发测试。

容量测试：在一定的软、硬件条件下，在数据库中构造不同数量级的记录数量，通过运行一种或多种业务场景在一定虚拟用户数量的情况下，获取不同数量级别的性能指标，从而得到数据库能够处理的最大会话能力，最大容量等。系统可处理同时在线的最大用户数，通常和数据库有关。

可靠性测试（稳定性测试）：通过给系统加载一定的业务压力（如CPU资源在70%~90%的使用率）的情况下，运行一段时间，检查系统是否稳定因为运行时间较长，通常可以测试出系统是否有内存泄漏等问题。

配置测试：主要是通过对被测试软件的软硬件配置进行测试，找到系统各项资源的最优分配原则。配置测试能充分利用有限的软硬件资源，发挥系统的最佳处理能力，同时可以将其与其他性能测试类型联合应用，从而为系统提供重要依据。

失败测试：对于有冗余备份和负载均衡的系统，通过失败测试来检验如果系统局部发生故障，用户能否继续使用系统，用户受到多大的影响，如几台机器做均衡负载，一台或几台机器垮掉后系统能够承受的压力。

性能测试应用场景（领域）主要有：能力验证、规划能力、性能调优、缺陷发现、性能基准比较，下表简单介绍和对比了这几个场景的各自用途和特点：

2.性能测试的分类

1. 基于代码的性能测试（关注点是函数或方法执行的效率）
2. 基于协议的性能测试（关注服务器的性能）

1. 客户端的性能测试（页面或者客户端的响应时间）

3 .服务端测试的分类

压力测试：在一定的软硬件、网络条件下，模拟用户高并发（峰值负载），持续一段时间，检测系统的各项性能指标，关注峰值下的系统的性能表现（秒杀、团购、抢票）

目的：监测被测系统在峰值下的运行情况，给最坏情况（系统崩溃）设计预案

场景模型：门型场景，大量线程同时开始，经过一段时间后，又同时结束

负载测试：在一定的软硬件、网络条件下，通过改变负载的方式，监测系统的各项性能指标，得到系统在正常工作情况下，系统的最大用户数、最佳用户数，定位系统的瓶颈

场景模型：拱门场景。线程不同时开始，经过一段时间后，陆续结束线程

配置测试：改变软硬件配置（架构配置、参数配置），观测不同配置条件下的性能状态

基准测试：在一定的软硬件、网络条件下，模拟单用户操作系统，检测系统各项性能指标。为后面深入的性能测试做一个数据对比。

并发测试：测试同一模块、同一应用在高并发的情况下，接口工作是否正常。目的是主要检查应用或者接口在多用户情况下，是否存在缺陷（比如死锁等）

容量测试：在一定的软硬件、网络条件下，改变数据库的容量，模拟多用户，监测各项性能指标的过程。寻找数据容量的极限值

稳定性测试：主要强调长时间、正常负载情况下，观测系统各项指标的稳定性，不会出现致命的问题。7*24小时。8小时、24小时、48小时。目的是检测系统长时间运行，系统的稳定性、是否有异常表现（宕机、出现致命问题等）

三.性能测试的指标和术语

1.指标：响应时间：用户发出请求到服务器处理完成请求返回给客户端的这段时间

吞吐量：衡量系统的业务处理能力。TPS:每秒事务数。QPS:每秒请求数

资源利用率：cpu、内存、网络、磁盘读写io。一般资源的利用率不高于70%-80%,如果某项高于这个值，则可能是性能瓶颈

错误率：系统在负载情况下，失败请求的概率。错误率=（失败请求数/总请求数）*100。和功能测试的错误相区别，在性能测试中，所谓的错误一般是指由系统超时引起的错误，而不是指功能错误。不同的系统错误容错率不同。普通的业务系统，错误率不超过万分之一就可以了，有的大型系统，亿分之一。

1、请求

客户端向服务器发出的请求获得数据或文件、图片等资源。

2、响应

服务器向客户端发送数据或文件、图片等资源。

3、协议

传输层协议：tcp、udp

应用层协议:ftp、http、dns、dhcp、smtp、pop

4、响应时间

应用系统从用户发出请求开始，到客户端接收到所有数据所消耗的时间。

网页响应时间细分

网络传输时间：N1+N2+N3+N4。

应用服务器处理数据：A1+A3。

数据库处理时间：A2。

5、在线用户

正在使用软件的用户。

6、并发用户

指同一时刻与服务器进行数据交互的所有用户数量。

在线用户未必是并发用户。

计算并发用户数

一般都根据以往经验和行业标准进行估算。

如电信业并发用户数常为在线用户的万分之一；

OA软件并发用户数一般在在线用户数的5%-20%。

参考其他同类产品。

分析历史数据（一年或半年内的每天需要处理的交易业务量）。

试上线运行。

7、虚拟用户

性能测试工具使用虚拟用户模拟真实用户的行为。

8、吞吐量与吞吐率

吞吐量

指一段时间内服务器处理的字节数，直接体现服务器的承载能力。

从吞吐量和VU关联图可看出，吞吐量在VU增长到一定数量时，软件系统出现性能瓶颈，此时吞吐量不再随VU增多而增大，而是趋于平衡。

实际测试时，吞吐量在测试前是不知道的，必须通过不断添加虚拟用户来测试，以找到吞吐量的拐点，即吞吐量的最大值

吞吐率（Throughout）

指单位时间内从服务器返回的字节数，即吞吐量/测试时间，也可以是单位时间内处理的客户请求数。

它是衡量网络性能一个重要指标。通常情况下吞吐量越大，吞吐率的值也越大，吞吐率越大表示系统的负载能力越强。

9、每秒事务数（TPS，TransactionPerSecond）

表示每秒系统处理的事务数，是衡量系统处理能力的重要指标。

如果每个事务对应一笔业务，那么TPS即表示服务器每秒处理的业务笔数。

10、点击率（HitPerSecond）

指每秒钟用户向服务器提交的HTTP请求的数量。

点击一次可能会向服务器发出多个HTTP请求。

通常服务器都具有防刷新机制，以防刷新导致的巨大压力。

点击率仅仅反映客户端提交的请求数，不能表现服务器当前承受的压力，因为服务器不能处理全部请求时可以拒绝客户端的部分请求。

若把每次点击作为一次提交事务来对待，则点击率与TPS同义。

11、思考时间（ThinkTime）

也称"休眠时间"、等待时间。

指用户在进行操作时，每个请求之间的时间间隔。

负载测试一般忽略思考时间，压力或可靠性测试根基实际情况设置一个思考时间。通常思考时间设置为3-5s。

12、资源利用率

资源利用率

指服务器系统中不同硬件资源被占用的程度，主要包括CPU利用率、内存利用率、磁盘利用率、网络等。

性能测试中常用资源利用率进行横向对比，如CPU使用率很高，而其他资源较低，可知CPU是系统瓶颈。

配置调优测试中，通过比较配置调优前后的系统资源利用率来判断调优效果。

性能计数器（Counter）

是描述服务器或操作系统性能的一些数据指标。主要是通过添加计数器来观察系统资源的使用情况。

计数器在性能测试中发挥着“监控和分析”的关键作用，尤其是分析系统可扩展性和定位性能瓶颈时。

性能测试中分析测试结果时，必须基于多个不同的计数器进行分析。

Web 服务器指标指标：

　　* Avg Rps: 平均每秒钟响应次数＝总请求时间 / 秒数；

　　* Successful Rounds：成功的请求；

　　* Failed Rounds ：失败的请求；

　　* Successful Hits ：成功的点击次数；

　　* Failed Hits ：失败的点击次数；

　　* Hits Per Second ：每秒点击次数；

　　* Successful Hits Per Second ：每秒成功的点击次数；

　　* Failed Hits Per Second ：每秒失败的点击次数；

* Attempted Connections ：尝试链接数；

2.性能测试中，各项指标之间关系

压力测试工具中的线程数和TPS并不会完全等于服务端的线程数和TPS，在具体的项目性能测试过程中，我们应该尽可能关注服务端能处理的请求数即关注服务端的TPS。

并发

建议做性能测试不要总说系统能支持多少并发，这个瞬时概念不能很好的衡量系统性能，那还是用TPS来的和谐。

并发数和TPS

有50个并发线程，每个线程都可以在1秒内完成100个事务，那么TPS=5000。

在线用户估算TPS

很多业务中，并发度都会低于5%，甚至低于1%。假设5%并发度，100w用户来计算：

TPS=100w x 5%=50000

根据TPS估算并发线程数

如果这时响应时间是 10ms，那显然并发线程数理论上是 50000TPS/(1000ms/10ms)=5000(响应时间是波动的所以是理论值)。

压测机器与线程数

运行压力测试工具的机器所能启动的线程数是与其硬件相关的，所以使用线程数一定要合理，并且把压测机器纳入压测的监控范围

1.基准性能场景

这里要做的是单交易的容量，为混合容量做准备。

2.容量性能场景

是较核心的性能执行部分。根据业务复杂度的不同，这部分的场景会设计出很多个。

3.稳定性性能场景

较核心的元素是时间，而时间的设置应该来自于运维周期，而不是来自于老板、产品和架构等这些人”。

4.异常性能场景

要做异常性能场景，前提就是要有压力。在压力流量之下，模拟异常。

3常用专业术语

集合点：大量进程统一开始的地方

关联

检查点：断言

用户数：在线用户数，并发用户数，系统用户数

PV：页面访问量。客户端向服务器请求的数量，通常是作为网站系统的处理能力的衡量标准

UV：独立用户访问量，根据用户数量来进行统计，访问系统一次算一个UV

四.性能测试流程

1.性能测试需求分析

弄清楚本次性能测试的需求，性能测试的目的是什么，明确后续性能的要点

主要需求有几种：新系统的能力验证、历史系统（明确的客户需求）、找出系统的性能瓶颈、稳定性验证（强度测试）

2.了解系统架构

在环境搭建阶段，了解项目的部署

在性能测试分析阶段，要通过不同的系统架构去设计相应的测试模型（真实模拟用户实际操作场景）

在性能测试定位和调优阶段，更要深入这些技术细节才能发现具体问题的位置

3.分析性能测试点（场景设计）

场景选择有哪些原则

使用频率高的业务

关键程度非常高的业务

资源占用非常严重的业务

4.测试工具选型

开源工具

商业工具

自研工具

5.测试计划

简介

性能测试的需求

测试环境

数据准备

测试工具

测试策略

人力和时间安排

6.测试环境搭建

主要保证测试环境与生产环境一致

硬件环境（服务器、网络）机器数与请求数按比例一致

软件环境（系统版本、软件版本）

使用场景的一致性

7.测试执行

准备测试数据

使用测试工具实现测试操作

根据测试策略，使用不同的虚拟用户和测试组合来进行测试

监控系统资源利用率

重复3,4步，直到找到性能问题

8.瓶颈定位及性能调优

调优需要开发、运维工程师参与和主导

反复验证性能是否有提升

性能调优的顺序，从易到难

硬件问题

网络问题

应用服务器、数据库的配置问题

源码、数据库脚本问题

系统架构问题

（1）性能测试调优应该注意的要点：

要点1：在应用系统的设计开发过程中，应始终把性能放在考虑的范围内。

要点2：确定清晰明确的性能目标是关键。

要点3：必须保证调优后的程序运行正确。

要点4：系统的性能更大程度上取决于良好的设计，调优技巧只是一个辅助手段。

要点5：调优过程是迭代渐进的过程，每一次调优的结果都要反馈到后续的代码开发中去。

要点6：性能调优不能以牺牲代码的可读性和可维护性为代价。
                                                                   

（2）一般性能测试调优的步骤：

步骤一：确定问题

步骤二：分析问题

步骤三：确定调整目标和解决方案

步骤四：测试解决方案

步骤五：分析调优结果

最后，如果达到了预期目标，调优工作就基本可以结束了。

9.编写性能测试报告

jmeter

目录结构

bin 目录：存放可执行文件和配置文件

jmeter.bat：Windows的启动文件

jmeter.log：日志文件

jmeter.sh：Linux的启动文件

jmeter.properties：系统配置文件

jmeter-server.bat：Windows分布式测试要用到的服务器配置

jmeter-serve：linux分布式测试要用到的服务器配置

docs和printable_docs目录：存放api的帮助文档

lib目录：存放jmeter所依赖的jar包和用户扩展所依赖的jar包

常用设置

修改语言：jmeter.properties文件中添加：language=zh_CN

修改编码：jmeter.properties文件中添加：sampleresult.default.encoding=UTF-8

基本使用流程

启动jmeter

在“测试计划”下添加“线程组”

在“线程组”在添加“HTTP请求”取样器

填写“HTTP请求”的相关请求数据

在“线程组”下添加‘察看结果树’监听器

点击“启动”按钮运行，并查看结果

常用元件介绍

线程组：用户模拟多线程，一个线程代表一个用户的操作

配置元件：进行测试环境和测试数据的初始化，类似于自动化脚本中的setup

前置处理器：对要发送的请求进行预处理，类似于自动化脚本中的参数化

取样器：往服务器发送请求，类似于自动化脚本中的发送请求

后置处理器：对收到的服务器的响应数据进行处理，类似于自动化叫嗯中获取响应中特定字段的操作

断言：将收到的响应结果与预期结果做对比

监听器：查看测试脚本运行的结果和日志，类似于自动化测试脚本中的测试报告

定时器：等待一段时间，类似于自行化测试脚本中的sleep

测试片段：封装基本功能的代码块，不单独执行，需要脚本进行调用，类似于自动化中封装的函数

元件作用域

在jmeter中，元件的作用域是根据测试计划的树形结构中元件的父子关系来确定的

元件中取样器是核心，其他组件都是以取样器为核心运行的，组件添加的位置不同，生成的取样器也不同

取样器：取样器都是一个独立的请求，不合其他元件相互作用，因此不存在作用域的问题

逻辑控制器：该元件只对其子节点的取样器和逻辑控制器起作用

其他六大元件：除取样器和逻辑控制符外，如果是某个取样器的子节点，则该元件对其父子节点起作用；如果其父节点不是取样器，则其作用域是该元件父节点下的其他所有后代节点（包括子节点，子节点的子节点等）

元件的执行顺序

配置元件

前置处理器

定时器

取样器

后置处理器

断言

监听器

注意：

jmeter元件执行顺序和自动化脚本执行顺序差不多

前置处理器，后置处理器，断言等元件功能只对取样器起作用，如果在它们的作用域内没有取样器，则不会执行

如果在同一作用域范围内有多个同一类型的元件，则这些元件按照它们在测试计划中的上下顺序依次执行

组件

重点组件有：

线程组

HTTP取样器

查看结果树

Cookie管理器

线程组

线程组是控制用于执行测试的线程数，也可以把一个线程理解为一个测试用户，线程组即一组用户。

线程组的特点：

设定线程数（模拟多人操作）

取样器（请求）和逻辑控制器必须依赖线程组才能使用

线程组可以添加多个，多个线程组可以并行和串行，默认是并行。设置串行的方式：“测试计划”的设置里面，勾选独立运行每个线程组

线程组下可以添加其他元件下的组件

线程组的分类

线程组

setUp线程组：最先执行

tearDown线程组：最后执行

线程组属性设置

取样器错误后要执行的动作

继续：如果取样器中执行出现错误失败的时候，请求不会停止，继续执行。一般选择此项

启动下一进程循环：如果出错，则同一线程中的余下请求将不再执行，直接开始新一轮迭代

停止线程：只限当前线程停止，不影响其他线程执行，一般不会设置此项

停止测试：当前执行的线程全部执行完毕后结束

立即停止测试：立刻停止所有线程操作

Ramp-Up时间（秒）：这些线程总共需要多少时间启动完成

循环次数：

可以设置次数；

也可以选择永远，选择永远时，要配合调度器使用

勾选调度器，设置持续时间（想要运行多久，如60*60*24表示持续24小时）

s设置启动延迟(延迟多少秒后起送线程)

same user on each iteration： 每次迭代使用相同的线程，节省创建新线程的资源。一般会结合cookie管理中的 use Threadgroup configuration to control cookie cearing使用，避免每次迭代都使用相同的cookie信息

http请求

属性配置

名称：自定义

注释：自定义

协议：默认是http

服务器名称或ip：只填域名或ip

端口：默认是80

方法：get/post……

路径：资源路径

内容编码：请求的编码格式，如：utf-8

对post使用multipart/form-data：需要上传文件时候勾选

与浏览器兼容的头：对于只能浏览器请求的网站，可以勾选这个

参数：以key-value形式的传参的

消息体数据：利用json的形式来传参的，写在这里面

文件上传：文件删除上传的时候利用这个

请求默认值设置

“添加”-》“配置元件”-》“HTTP请求默认值”这个路径中设置，请求的协议、域名或ip、端口号。

这样其他请求就可以使用这个默认配置，而不用再配置协议、域名或ip、端口号了

发送get请求

直接在路径中带参数

以key-value的形式传参数

发送post请求

以键值对形式传参

直接在“参数”的下面添加参数，适合于content-type为application/x-www-form-urlencoded的时候，不需要单独设置请求头。

以json的形式传参

在“http请求”页面中-》“消息体数据”中添加参数的json字符串"

必须为该http请求添加一个“配置元件”-》“HTTP信息头管理器”，并且在该页面设置：conten-type为application/json

传文件

只传文件的情况：

选中“对post会用multipart/form-data”

在文件上传中设置

文件名称：即文件的全路径

参数名称

MIME类型：multipart/form-data

除了文件，还要传其他普通参数的情况：

选中“对post会用multipart/form-data”

在文件上传中设置

文件名称：即文件的全路径

参数名称

MIME类型：multipart/form-data

在“参数”中设置普通参数

察看结果树

会显示“查看结果树”作用域中的所有http请求。可以查看请求的结果

cookie管理器

cookie管理器专门用于管理客户端的cookie信息，一般用于需要登录的场景保持与服务器端的会话。如果不设置该管理器，则无法再jmeter中保持会话

添加方式：“配置元件”-》“cookie管理器”

cookie管理器一般不需要专门设置，添加了就可以了

工具自带的录制脚本

在测试计划下，“添加”-》“非测试元件”-》“HTTP代理服务器”

设置监听的端口

“Test Plan creation”-》目标控制器下拉列表，选择一个目录，表示录制的脚本存放在jmeter的位置

“request filtering”-》“排除模式”-》“添加” 排除css,jspng等

电脑打开代理设置，ip为本机ip，端口为第2步设置的端口

这样jmeter就能录制到，点击运行的页面上的请求接口了，并将http请求存放到第3步的位置

jmeter参数化

每次请求发送不同的值，就需要用到参数化。

用户定义的变量

添加方式：“测试计划”-》“线程组”-》添加“配置元件”-》“用户定义的变量”

步骤：

添加线程组

添加用户定义的变量（通过配置元件或直接在测试计划属性内添加）

添加http请求

添加查看结果树

优势：所有要用到该值的订单，统一使用一个变量${变量名}，便于维护

劣势：多个用户也只能取一个值，无法让多个用户使用多个值

CSV文件参数化

添加方式：“测试计划”-》“线程组”-》添加“配置元件”-》“CSV数据文件设置”

步骤：

定义csv文件，各个字段之间以逗号分隔。

添加线程组

添加CSV数据文件设置

选择CSV文件路径

设置文件编码

指定变量名称，以逗号分隔: username,passeord

忽略首行：如果首行不是测试数据，是字段名，这里选true,表示不读取首行

是否允许带引号：

遇到文件结束符再次循环： 文件中的数据条数读完时，线程数还没运行完，是否需要再去从头开始读取文件中的数据

遇到文件结束符停止线程：如果文件结束时，还有未运行完的线程，是否要停止线程

添加http请求

添加查看结果树

优势：对同一个用户多次循环，可以取不同的值，适合数据量比较大的参数化测试，是在接口测试或性能测试中常用的一种方式。

jmeter断言

Xpath断言

主要用于HTML格式的响应断言。

添加方式：“测试计划”-》“线程组”-》“HTTP请求”-》右键“添加断言”-》“xpath”断言

勾选Use Tidy（tolerant parser），使其兼容

文本框中写xpath表达式。

如果有多个条件，用and连接

要获取元素的文本，用text()

要获取任意属性的值用attribute::属性名表示

1.Jmeter简介

1 JMeter简介

Apache JMeter 是 Apache 组织基于 Java 开发的压力测试工具，用于对软件做压力测试；

开源的桌面应用软件；

可用于测试静态和动态资源，如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库和 FTP 服务器等等；

可对服务器、网络或对象模拟巨大的负载，在不同压力类别下测试它们的强度和分析整体性能；

能够对应用程序做功能/回归测试；

允许使用正则表达式创建断言，通过创建带有断言的脚本来验证程序是否返回了期望结果；

2 体系结构

元件：代表JMeter工具菜单中一个子菜单（功能），比如Http请求就是一个元件；

组件：一组元件的集合，如逻辑控制器就是组件，它还包含事务控制器；

JMeter结构图：

X1-X5：使用这些组件来完成负载的模拟；

Y1：负载模拟用户请求；

Y2：负责结果验证正确性；

Z：负载结果的收集。

2.1 取样器

作用：用来模拟用户操作，向服务器发出请求，比如http请求、java请求等；

JMeter5.3版本取样器总共21个，涵盖了常用的协议，比如http、ftp、smtp等

2.2 断言

作用：用例验证结果的正确性，及一个预设的结果，到时候和实际结果进行匹配；

访问路径：

测试计划-添加-断言

2.3 监听器

作用：用来监听收集测试结果，保存结果和结果展示；

访问路径：

测试计划-添加-监听器

【取样器】-【断言】-【监听器】组合在一起，就可以完成发送请求、验证结果及记录结果三项工作。

2.4 前置处理器

作用：测试脚本开发中，在请求发送前做一些环境或参数的准备工作，比如数据库操作前的建立连接；

访问路径：

测试计划-添加-前置处理器

2.5 配置元件

作用：为取样器提供预备数据，由取样器发出请求。比如可以设置参数化、记录服务器的返回数据等；

访问路径：测试计划-添加-配置元件

2.6 后置处理器

作用：放在取样器之后，用来处理服务器的返回结果；

返回路径：

测试计划-添加-后置处理器

【前置处理器】-【配置元件】-【后置处理器】，都是为取样器提供数据支持。

2.7 控制器

作用：通过控制各种控制器的组合，来完成我们的各种请求。比如邮件服务等；

访问路径：

测试计划-添加-线程（用户）-线程组；

线程组-添加-逻辑控制器。

2.8 定时器

作用：比如模拟用户请求时，在某一时刻或者同时刻发送请求；

访问路径：

测试计划-添加-线程（用户）-线程组；

线程组-添加-定时器

2.9 线程组

作用：模拟大量用户负载情况，模拟用户数，一线程一个用户；除设置线程数外还可以设置运行时长等；

访问路径：

测试计划-添加-线程（用户）-线程组；

2.10 测试片段-Test Fragment

作用：是辅助组件，可放置任何测试元件，一般不会被运行；用来备份元件，其下的元件看被模块控制器调用；

访问路径：

测试计划-添加-测试片段

2.JMeter原理及测试计划要素

1 运行原理

1.1 概述

1.2 远程运行

1.2.1 控制机

1.2.2 负载机

1.2.3 远程运行逻辑

2 测试计划要素

1 运行原理

1.1 概述

JMeter通过线程组来驱动多个线程运行测试脚本对被测试服务器发起负载；

每个负载机上都可运行多个线程组；

运行场景可在GUI方式中完成，也可使用命令行，其中命令行的运行方式对于负载机的资源消耗更小；

1.2 远程运行

1.2.1 控制机

及被选中作为管理及的那台机器；

可参与运行脚本；

担负着管理远程负载机指挥远程负载机的任务；

收集远程负载机的测试结果。

1.2.2 负载机

即向被测试引用服务器发起负载的机器；

控制机也是一台负载机；

负载机受控制机管理，要启动一个客户端程序（Agent：jmeter-server.bat），此时控制机才可接管负载机。

1.2.3 远程运行逻辑

远程负载机启动Agent程序，待控制机连接；

控制机连接远程负载机；

控制机发送指令（脚本或命令）启动线程；

负载机运行脚本，回传状态（包括测试结果）；

控制机收集结果并显示。

2 测试计划要素

一个脚本就是一个测试计划，也是一个管理单元，一个线程代表一个虚拟用户；请求模拟和并发数都在脚本文件中设置。

要素1：脚本中测试计划只能有1个

类似LR中的Controller中的测试场景，一个测试场景只能有一个。在JMeter中脚本是树形结构，测试计划是根节点。

要素2：测试计划中至少要有1个线程组

负载是通过线程组驱动，所以计划中至少要出现一个线程组；也可支持多个线程组，类似LR中的混合场景。

要素3：至少要有1个取样器

测试的目的是模拟用户请求，没有取样脚本就无任何意义了。

要素4：至少要有1个监听器

用来收集测试结果，测试结果可衡量系统性能，分析系统性能。

3.JMeter界面

注意：我这个界面没有以下三个按钮：

开始运行远程测试计划；

停止运行远程测试计划，当前线程执行完后停止；

停止运行远程测试计划，类似于杀进程。

目录

1 文档说明

1.1 测试目的

1.2 测试目的

1.3 读者对象

1.4 参考资料

1.5 术语解释

1.6 系统压力估算

2 测试环境

2.1 测试环境

2.2 测试工具

3 测试需求

3.1 测试功能点

3.2 性能需求

4 测试策略

4.1人力资源

4,2测试用例

5 测试结果

5.1 聚合报告

5.2 系统吞吐量

5.3 资源占用率

6 分析与建议

6.1 测试结论分

6.2 问题

正文

1 文档说明

1.1 编写目的

本次测试报告为xxx系统的性能测试总结报告，目的在于总结性能测试工作，并分析测试结果，描述系统是否符合xxx系统的性能需求。

1.2 测试目的

本次性能测试的目的是检测xxx系统的性能情况。即：为了xxx系统上线后能够稳定运行，有必要在上线前对核心业务场景的压力情况有充分了解。因此，希望在模拟生产环境的情况下，模拟上线后的用户并发数，对系统核心业务进行压力测试，收集相应的系统参数，并最终作为上线的依据。

1.3 读者对象

预期参考人员包括用户、测试人员、开发人员、项目管理者、质量管理人员和需要阅读本报告的高层经理。

1.4 参考资料

1.5 术语解释

线程数：并发用户数

请求数Samples：发出了多少个请求，例：模拟10个用户，每个用户迭代10次，就是100次

平均响应时间Average：单个请求平均响应时间（毫秒）

中位数Median： 50％ 用户的响应时间（毫秒）

90% Line：90％ 用户的响应时间

Min：最小响应时间（毫秒）

Max：最大响应时间（毫秒）

错误率Error%：出现错误的请求的数量/请求的总数

吞吐量Throughput：表示每秒完成的请求数（Request per Second），是指在没有帧丢失的情况下，设备能够接受的最大速率

KB/Sec：每秒从服务器端接收到的数据量；1GB＝1024MB，1MB＝1024KB，1KB＝1024Bytes。

1.6 系统压力强度估算

并发用户的经验公式为：使用系统的用户数量*（5%~20%）

系统响应时间判断原则（2-5-10原则）如下：

系统业务响应时间小于2秒，判为优秀，

用户对系统感觉很好；

系统业务响应时间在2-5秒之间，判为良好，用户对系统感觉一般；

系统业务响应时间在5-10秒之间，判为及格，用户对系统勉强接受； 

系统业务响应时间超过10秒，判断为不及格，用户无法接受系统的响应速度；

2 测试环境

2.1 测试环境

网络环境：广域网（100M）

软件环境：

1 操作系统：Windows 10

2 应用服务软件：WebSphere，Tomcat5.5

3 数据库：MySQL

硬件环境：

2.2 测试工具

3 测试需求

3.1 测试功能点

×××××××

3.2 性能需求

注：1. 如果未提出实际性能需求可简写或省略该项

2. 此项根据产品需要可适当修改

并发用户数达到x时，登录系统平均响应时间不超过x秒；

 并发用户数为x时，操作主要的业务流平均响应时间在用户接受的范围内，系统 运行正常；

X小时运行组合测试用例时，系统正常运行不崩溃；

若系统容量不能达到要求的并发数或运行时间时，验证一下达到哪一个数值时，系统将不能支持

4 测试策略

4.1 人力资源

4.2 测试用例

5 测试结果（图文）

5.1 聚合报告

情景一：（说明）

聚合报告图

情景二（说明）

聚合报告图

5.2 系统吞吐量

截图

5.3 资源占用率

最优负载条件下：

CPU使用率（图）

内存占用率（图）

磁盘使用率（图）

6 分析与建议

6.1 测试结论分析

1. 经过多次测试和数据报表分析，可以得出如下结论：

2.当总体并发用户数为450-500时，系统具有最优性能表现；当事务并发数超过500时，事务失败率整体上升，系统到达性能拐点。

3.多事务混合条件下，系统巅峰TPS在90左右，平均吞吐量在13-18/s。

4.在小压力条件下（10并发），最大事务响应时间为查询用户信息事务的2042毫秒，平均在600毫秒左右系统。整体事务微观响应速度较优。

5.满负载条件下，登录具有最佳的性能表现，平均响应时间为7000-12000毫秒；查询用户信息事务性能较差，平均响应时间在30000-40000区间。满负载条件下系统整体微观响应时间较差。查询用户接口由于其使用极为频繁，建议进行SQL效率调优

6.系统资源方面，内存占用率始终处于高位水平（90%以上），磁盘空间由于日志写入而不断被占用。

6.2 问题

1.测试过程中发现了如下显著问题：

2.加密验签功能并未生效-现阶段任何签名均可通过验签。属于功能性问题，不影响性能表现。

3.日志文件由于不断写入导致磁盘占满，建议调低系统日志级别，并做好定期日志备份。

4.内存占用处于高位水平，需要进一步探查原因。