1 环境配置
1.1 测试环境准备
数据库：Oracle 11g，库名：orcl；
Jmeter：jmeter-5.1.1安装在win10系统下（到 http://jmeter.apache.org/ 下载JMeter压缩包，无需安装解压即可，点击bin目录下的jmeter.bat文件即可运行Jmeter）
JDBC驱动：找到ojdbc 14.jar并将其复制粘贴到D:Program Filesapache-jmeter-5.1.1lib目录下
1.2 测试计划
打开测试计划，添加JDBC驱动：
1.3 线程组
添加一个线程组，并配置页面。
在取样器错误后要执行的动作：在线程内的采样器失败后，接下来做什么。
1) 继续：继续执行接下来的操作；
2) Start Next Loop：忽略错误，执行下一个循环；
3) 停止线程：退出该线程（不再进行此线程的任何操作）；
4) 停止测试：等待当前执行的采样器结束后，结束整个测试；
5) Stop Test Now：直接停止整个测试。
线程属性（5个设置项）
1) 线程数：模拟的用户数量；
2) Ramp-up Period（in seconds）：达到指定线程数所需要的时间。举例：线程数设置为50，此处设置为5，那么每秒启动的线程数 = 线程数50/5 = 10；
3) 循环次数：选中“永远”，则一直循环下去；
4) Delay Thread creation until needed：（延迟创建线程直到需要）：当线程需要执行的时候，才会被创建。如果不选择这个选项，那么，在计划开始的时候，所有需要的线程就都被创建好了；
5) 调度器：详见下文“调度器配置”。
调度器配置：全部都在“调度器”复选框被选中的前提下，下面的选项才会生效。
1) 持续时间（秒）：在此选项填入N，说明这个计划，从某个开始时间算起，执行N秒后结束。（会忽略“结束时间”的选项）；
2) 启动延迟（秒）：在此选项填入N，手动点击开始执行计划，然后延迟N秒后，计划才真正开始执行。（会忽略“启动时间”的选项）；
3) 启动时间：当点击开始测试时，将等到此处填写的启动时间，然后真正开始测试；
4) 结束时间：当开始测试时，将等到指定的开始时间开始测试，然后会停在此处填写的时间点结束。
1.4 JDBC Connection Configuration
添加配置元件“JDBC Connection Configuration”，并配置页面。
Variable Name Bound to Pool：
Variable Name：数据库连接池的变量名，之后JDBC request可以通过选择不同的连接池名来选择不同的数据库连接。变量名不能重名。
Connection Pool Configuration：JDBC连接池配置，一般使用默认值就可以。
1) Max Number of Connections：数据池允许的最大连接数，通常该值设置为0，意思是每个线程都使用单独的数据库连接，例如，配置在两个线程间不共享。如果你确实想共享连接池，那么最大连接数应当和线程数一样，以便线程不用互相等待；
2) Max Wait (ms)：在连接池中取回连接的最大等待时间，如果超过改时间，将抛出一个错误；
3) Time Between Eviction Runs (ms)：数据库空闲连接的回收时间间隔。回收时，会将将空闲连接物理性的关闭掉。若为非正数，则空闲连接回收器不停运行；
4) Auto Commit：自动提交。有三个选项，true、false、编辑（自己通过jmeter变量值设置）。选择true后， 每条sql语句就是一个事务，执行结束后会自动提交；否则不会提交，需要自己手动提交；
5) Transaction Isolation：数据库事务隔离的级别设置，有6个选项（对JMX加解密）：TRANSACTION_NODE：事务节点；TRANSACTION_READ_UNCOMMITTED：事务未提交读；TRANSACTION_READ_COMMITTED：事务已提交读； TRANSACTION_SERIALIZABLE：事务序列化；DEFAULT：默认；TRANSACTION_REPEATABLE_READ：事务重复读；编辑。
Connection Validation by Pool，连接池有效性验证配置部分：这是Jmeter用来检验数据库连接是否有效的一种机制，超过5秒没有使用的话，就会用validation query去测试下这个连接是否有效，一般使用默认就可以。
1) Test While Idle：是否在空闲时进行连接有效性验证。Validation Quary被用来验证连接的有效性；
2) Soft Min Evictable Idle Time(ms)：数据库连接池中的连接至少闲置多久才能被回收。额外的条件是，在连接池中至要保留有minIdle个连接
3) Validation Query：一个验证数据库仍然响应的简单查询语句。默认是JDBC驱动的 ‘isValid()’ 方法，它适合于很多数据库。可以通过jmeter.properties中jdbc.config.check.query属性设置默认的验证sql语句，有10个选项：Hsqldb select 1 from INFORMATION_SCHEMA.SYSTEM_USERS；Oracle select 1 from dual；DB2 select 1 from sysibm.sysdummy1；MySQL select 1；Microsoft SQL Server (MS JDBC driver) select 1；PostgreSQL select 1；Ingres select 1；Derby values 1；H2 select 1；Firebird select 1 from rdb$database。
Database Connection Configuration，数据库连接配置部分。
1) Database URL: 数据库的连接字符串；
2) JDBC Driver class：驱动程序类的完全限定名；
3) Username：连接数据库的合法用户名；
4) Password：用户对应的口令。
1.5 JDBC Request
添加取样器“JDBC request”，并配置页面。
Variable Name Bound to Pool：
Variable Name：数据库连接池的名字，需要与JDBC Connection Configuration的Variable Name Bound Pool名字保持一致。
SQL Query：
1) Query Type：JDBC Request可以发送的请求类型，目前有10类：Select Statement；Update Statement - use this for Inserts and Deletes as well； Callable Statement；Prepared Select Statement；Prepared Update Statement - use this for Inserts and Deletes as well；Commit；Rollback；Autocommit(false)；Autocommit(true)；Edit - this should be a variable reference that evaluates to one of the above；
2) Query：填写的sql语句，未尾不要加“;”；
Parameter values：参数值。
Parameter types：参数类型，（比如varchar、tinyint(m)、smallint(m) ）。
Variable names：保存sql语句返回结果的变量名。
Result variable name：创建一个对象变量，保存所有返回的结果。
Query timeout：查询超时时间。
Handle result set：定义如何处理由callable statements语句返回的结果，有四个选项：Store as String；Store as Object；Count Records；编辑。
1.6 HTTP请求默认值
该组件可以为我们的http请求设置默认的值。假如，我们创建一个测试计划有很多个请求且都是发送到相同的server，这时我们只需添加一个 Http request defaults组件并设置“Server Name or IP”，然后添加多个http请求且不设置”server name or ip”，这些http请求会默认使用Http request defaults组件设置的值。
1.7 BeanShell 后置处理程序
添加后期处理器BeanShell PostProcessor，用来把查询的结果显示在log上。如果不需要设置postprocessor观察数据，可以直接添加监听器运行。
在利用jmeter进行接口测试或者性能测试的时候，我们需要处理一些复杂的请求，此时就需要利用bean shell脚本了，Bean Shell是一种完全符合Java语法规范的脚本语言,并且又拥有自己的一些语法和方法，所以它和java是可以无缝衔接的。bean shell本身自带的一些内置变量和一些方法。JMeter在其Bean Shell中内置了变量，用户通过这些变量与JMeter进行交互。
1) log 打印日志，写入信息到jmeber.log文件。
2) SampleResult 获取SampleResult对象，能通过这个对象获取想要的信息。
3) Response 获取Response对象，能通过这个对象获取响应信息。
4) Failure 查看接口调使用能否成功，假如返回false是成功的，true是失败的。
5) FailureMessage 失败信息，没有设置的时候失败信息是空的，能set这个信息。
6) ResponseData 获取response body类型是byte[]。
7) ResponseCode 返回接口code成功是200。
8) ResponseMessage 获取msg成功是OK。
9) ResponseHeaders 获取接口服务端返回的头部信息。
10) RequestHeaders 获取用户端请求的头部信息。
11) SampleLabel 获取接口请求的名称。
12) SamplerData 获取请求的url和body。
13) ctx代表上下文信息，能直接用。
14) vars即JMeterVariables，操作jmeter变量，这个变量实际引用了JMeter线程中的局部变量容器（本质上是Map），常用方法：
a) vars.get(String key)：从jmeter中获得变量值；
b) vars.put(String key，String value)：数据存到jmeter变量中；
15) prev 获取前面的sample返回的信息，常用方法：
a) getResponseDataAsString()：获取响应信息。
b) getResponseCode() ：获取响应code。
2 JDBC连接测试
2.1 测试场景
场景描述：
通过将线程数分别设置为100、200、300，以实现对100个用户同时对JDBC发出查询指令，200个用户同时对JDBC发出查询指令，300个用户同时对JDBC发出查询指令的模拟。
2.2 测试用例
|
测试需求 |
测试过程说明 |
过程标引 |
|
查询 |
以100线程数查询表格所有信息记录 |
Select 100 |
|
以200线程数查询表格所有信息记录 |
Select 200 |
|
|
以300线程数查询表格所有信息记录 |
Select 300 |
2.3 测试结果
2.3.1 100个用户同时对JDBC发出查询指令
a) 察看结果树
jmeter中最常用的监听器，可以看到请求的发送和返回信息。
b) 图形结果
图表底部参数的含义如下：
样本数目：总共发送到服务器的请求数；
最新样本：代表时间的数字,是服务器响应最后一个请求的时间；
吞吐量：服务器每分钟处理的请求数；
平均值：总运行时间除以发送到服务器的请求数；
中间值：代表时间的数字，有一半的服务器响应时间低于该值而另一半高于该值；
偏离：服务器响应时间变化、离散程度测量值的大小，或者，换句话说，就是数据的分布。
分析：在此情况下数据库管理系统服务器的平均值为588，中间值为545，响应时间差异大。响应性能不稳定。
c) 聚合报告
Label：数据请求方式，图上是数据库连接；
#samples：向服务器发送的请求数目；
Average：总运行时间除以发送到服务器的请求数；
Median：图形报表中的中间值，是代表时间的数字，有一半的服务器响应时间低于该值而另一半高于该值；
90%line：是指90%请求的响应时间比所得数值还要小；
95%line：是指95%请求的响应时间比所得数值还要小；
99%line：是指99%请求的响应时间比所得数值还要小；
Min：是代表时间的数字,是服务器响应的最短时间；
Max: 是代表时间的数字,是服务器响应的最长时间；
Error%：请求的错误百分比；
Throughput：图形报表中的吞吐量，这里是服务器每单位时间处理的请求数，注意查看是秒或是分；
KB/sec：是每秒钟请求的字节数。
分析：本次测试场景运行100线程，平均响应时间=558ms，统计意义上的响应时间中值=545ms，所有线程中90%的线程响应时间都小于1000ms，所有线程中95%的线程响应时间都小于1064ms，所有线程中99%的线程响应时间都小于1086ms，响应最小时间=20ms，响应最大时间 =1122ms，出错率 = 0，吞吐量为每秒84个请求。
2.3.2 200个用户同时对JDBC发出查询指令
a) 察看结果树
b) 图形结果
分析：在此情况下数据库管理系统服务器的平均值为102，中间值为3，响应时间差异较大。响应性能较不稳定。相应的，响应时间有所增加。
c) 聚合报告
分析：本次测试场景运行200线程，平均响应时间=102ms，统计意义上的响应时间中值=3ms，所有线程中90%的线程响应时间都小于356ms，所有线程中95%的线程响应时间都小于435ms，所有线程中99%的线程响应时间都小于514ms，响应最小时间=1ms，响应最大时间 =677ms，出错率 = 0，吞吐量为每秒163.4个请求。
2.3.3 300个用户同时对JDBC发出查询指令
a) 察看结果树
b) 图形结果
分析：在此情况下数据库管理系统服务器的平均值为2，中间值为2，响应时间明显减小。响应性能稳定。随着用户的增加，响应时间变长。
c) 聚合报告
分析：本次测试场景运行300线程，平均响应时间=2ms，统计意义上的响应时间中值=2ms，所有线程中90%的线程响应时间都小于3ms，所有线程中95%的线程响应时间都小于3ms，所有线程中99%的线程响应时间都小于3ms，响应最小时间=1ms，响应最大时间 =5ms，出错率 = 0，吞吐量为每秒235.8个请求。
3 测试结果
分析：
根据表中数据可知，随着用户请求数量的增加，数据库服务器的每分钟处理请求数即吞吐量也在逐步增加，平均响应时间大幅减少。
经过分析可得出以下结论：
数据库服务器的系统性能随着用户数量的增加而大大提高，此数据库服务器的系统性能良好，测试的数值在其承受范围内。