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 Files\apache-jmeter-5.1.1\lib目錄下
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 測試結果
分析：
根據表中數據可知，隨着用戶請求數量的增加，數據庫服務器的每分鍾處理請求數即吞吐量也在逐步增加，平均響應時間大幅減少。
經過分析可得出以下結論：
數據庫服務器的系統性能隨着用戶數量的增加而大大提高，此數據庫服務器的系統性能良好，測試的數值在其承受范圍內。