最近總結了一下在接口測試方面的知識與心得，在這里與大家分享一下，如有說的不對的地方請多多指正。

接口測試概述

定義

API testing is a type of software testing that involves testing application programming interfaces (APIs) directly and as part of integration testing to determine if they meet expectations for functionality, reliability, performance, and security. Since APIs lack a GUI, API testing is performed at the message layer.[2] API testing is now considered critical for automating testing because APIs now serve as the primary interface to application logic and because GUI tests are difficult to maintain with the short release cycles and frequent changes commonly used with Agile software development and DevOps).

WIKI定義：接口測試作為集成測試的一部分，通過直接控制API來判斷系統的功能性，可靠性，性能與安全性。API測試是沒有界面的，執行在通訊層。API 測試在自動化測試中有著重要的地位，因為API一般是應用邏輯的主要接口，而GUI測試在敏捷開發和DevOps的快速迭代和頻繁變更中很難維護。

分類

接口測試是測試系統組件間接口的一種測試。接口測試主要用于檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等。接口測試大體分為兩類：模塊接口測試和web接口測試。

模塊接口測試

模塊接口測試是單元測試的基礎。它主要測試模塊的調用與返回。經常需要編寫一些樁模塊與驅動模塊。

主要測試要點如下：

檢查接口返回的數據是否與預期結果一致。

檢查接口的容錯性，假如傳遞數據的類型錯誤時是否可以處理。

接口參數的邊界值。例如，傳遞的參數足夠大或為負數時，接口是否可以正常處理。

接口的性能，接口處理數據的時間也是測試的一個方法。牽扯到內部就是算法與代碼的優化。

接口的安全性

WEB接口測試

web接口測試又可分為兩類：服務器接口測試和外部接口測試。

服務器接口測試：是測試瀏覽器與服務器的接口。用戶輸入的數據是輸入到的前端頁面上，怎樣把這些數據傳遞的后臺的呢？通過http協議的get與post請求來實現前后端的數據傳遞。這也可認為是接口測試。

外部接口測試：這個很典型的例子就是第三方支付，比如在我們應用中在充流量時，交話費時，都會調用第三方支付接口。

主要測試要點如下：

請求是否正確，默認請求成功是200，如果請求錯誤也能返回404、500等。

檢查返回數據的正確性與格式；json是一種非常常見的格式。

接口的安全性，一般web都不會暴露在網上任意被調用，需要做一些限制，比如鑒權或認證。

接口的性能，這直接影響用戶的使用體驗。

接口測試工具

SOAPUI

JMeter

Grinder

Suds Python

在工作中主要應用SOAPUI與JMeter。SOAPUI對接口安全測試有比較好的支持。本文還是主要介紹JMeter的使用，關注的是功能測試，對于它的強項性能測試，在以后的文章中描述。

測試用例設計與原則

因為在實際工作中測試的接口都是基于HTTP協議的，所以下面的測試用例及原則也是針對此類接口。

測試用例

正面測試用例：

• 覆蓋所有的必選參數
• 組合可選參數
• 參數邊界值
• 如果參數的取值范圍是枚舉變量，需要覆蓋所有枚舉值
• 還應考慮實際業務應用場景，去設計輸入參數的組合。(這些用例可用來測試功能，作為SMOKE用例。也可將來用于壓力測試模擬實際業務場景，但要注意保證用例的獨立性，因為壓力測試是多線程的。比如我們測試ACCOUNT 創建接口，NAME是不能重的，在寫測試用例時，給NAME賦值時可以加一個時間戳, 這樣用例在多線程并發測試時也不會有問題)

負面測試用例：

• 空數據
• 包含特殊的字符
• 越界的數據
• 錯誤的數據

驗證點：

• status code (正常情況下，所有請求都應該返回200)
• 響應信息數據結構(目前大多數情況下，返回信息都是JSON, 我們應該驗證相應的結構當數據信息發生改變時)
• 驗證結點的類型
• 驗證結點的值 (主要是針對固定的值或者值遵循某些規則，我們能知道預期的結果的)
• 對于列表，應該根據請求參數，也應該驗證列表的長度是否與期望值一致
• 負面測試用例，應驗證ERROR INFO是否與實際相匹配

測試原則

測試應該是獨立的、可讀的、抗變的、可維護的，其實這也是所有自動測試應該遵循的原則

• 每個測試用例都是獨立的
• 測試用例都是可重復運行的 (這主要是說一些測試數據不能寫死，不同的環境數據可能不同。在實際工作中，解決方案有二：自已創建所需要的數據，比如你要測試接口需要輸入參數ACCOUNTID,你可以先調用創建ACCOUNT API, 然后從響應值拿到ACCOUNTID, 當你測試完你要測的接口后，再把新建的ACCOUNT刪除，也就是說一個測試用例分了三步。另外一種方法就是讀取數據庫，從數據庫獲取數據，這種方法在測試開發與測試環境還OK，但如果測線上環境就比較困難了，因為我們不能隨意更新上面的數據，也不能放過多的測試數據在上面。因此我個人比較推崇第一種方法，雖然增加開發用例的工作量，但一勞永逸)
• 測試能被運行在不同的環境里(平常測試環境至少會分DEV/TEST/STAGING/ONLINE，我們在測試過程中，應該把域名，token/apikey等應放在一個變量里，當切換環境時，我們只需改變變量的值即可
• 測試數據與業務相分離(測試數據包括參數接口數據/ 測試執行所需要的系統數據)
• 盡量統一共用的測試環境變量
• 測試完成后，要刪除不必要的測試數據。

JMeter 使用

在實際工作中，我主要應用JMeter對接口做功能測試，所以下面主要介紹一下JMeter的使用

基本介紹

下面是我的一個測試腳本，通常一個文件會包含下面這些組件。我通過簡單控制器與DEBUG Sampler來組織管理不同的接口，驗證點主要通過寫一些Beanshell腳本來實現。對于一些復雜的操作，如果網上能找到到現成的資源，比如JAR,CLASS文件會直接在Beanshell PreProcessor/PostProcessor引用。另外在Jmeter里寫Beanshell不容易DEBUG,所以還是建議復雜的功能直接在Eclipse里編寫，然后生成JAR包. 關于Beanshell使用會在后面介紹

使用Beanshell 在 JMeter

BeanShell是一種完全符合Java語法規范的腳本語言,并且有自己的一些語法和方法

我的腳本幾乎所有驗證都是通過Beanshell腳本，只有少部分應用了Response Assert。

Beanshell 常用內置變量

下面是一些實際的例子

• 操作變量：(vars)

• 獲取前面的sample返回的信息(prev)

• 寫入信息到jmeter.log文件

log.info("log information")

• 獲取屬性(props)

它是類似的與vars, 相應的屬性在在文件jmeter.properties中定義

• 引用外部文件(jar/class/java)

另外如果引用外部JAR包，也可在TEST PLAN中配置，在JMeter中點擊Test Plan 結點，就會看到下面的界面，可以直接添加JAR包所在路徑

其它

CSV配置組件使用

CSV_Data_Set_Config 當發送多組同樣的請求，只是所帶參數不同，這時可以加這個配置組件

然后在SAMPLER中可以應用上面這些變量配合循環控制器

連接數據庫

在測試過程中，我們需要一些測試數據來自于數據庫，這時我們需要在Jmeter連接數據庫

下面以連接MySQL數據庫為例

• 下載 MySQL JDBC driver
• 拷貝這個文件到JMeter安裝路徑下的“lib"文件夾
• 建立“JDBC Connection Configuation"

其它數據庫連接請參考下圖：

• 添加JDBC request

因為我們在接口測試中，更多的時候是獲取數據，所以基本都用“SELECT"。如果想INSERT數據，需要選擇“Callable Statement"在"Query Type"

在使用過程中注意以下幾點：

• SQL語句不要加分號
• 如果查詢條件是變量，在語句中用“?”號代替，具體的值在下面的“Parameters Value"定義，如果有多個參數，中間要用分號隔開。當然也可以用${變量名｝(在用戶定義變量組件中已經定義)
• 對于“variable names" 數據表中有多少列就可以設置多少變量，對于不需要設置變量的列用逗號占位就可以了。
• 獲取查詢結果數據在Beanshell里

添加監聽器

• View result tree

• Aggregate report

Aggregate Report 是 Jmeter 常用的一個Listener, 中譯為“聚合報告”，每一列具體表示如下。

Label：每個 JMeter 的 element(例如 HTTP Request)都有一個 Name 屬性，這里顯示的就是 Name 屬性的值

#Samples：表示你這次測試中一共發出了多少個請求，如果模擬10個用戶，每個用戶迭代10次，那么這里顯示100

Average：平均響應時間——默認情況下是單個 Request 的平均響應時間，當使用了 Transaction Controller 時，也可以以Transaction 為單位顯示平均響應時間

Median：中位數，也就是 50％ 用戶的響應時間

90% Line：90％ 用戶的響應時間

Min：最小響應時間

Max：最大響應時間

Error%：本次測試中出現錯誤的請求的數量/請求的總數

Throughput：吞吐量——默認情況下表示每秒完成的請求數(Request per Second)，當使用了 Transaction Controller 時，也可以表示類似 LoadRunner 的 Transaction per Second 數 KB/Sec：每秒從服務器端接收到的數據量，相當于LoadRunner中的Throughput/Sec

Jmeter 與 Jekins 集成

說這個之前簡單說一下如何在命令行執行JMeter

• 首先配置JMETER_HOME環境變量，值即為你Jmeter解壓路徑
• 在命令行運行jmeter -v , 正確返回當前版本，證明環境OK
• 運行jmeter -n -t script.jmx -l log.jtl

接口持續集成

在這塊卡了好久，主要是report展示。之前是不想再用其他工具(如：Ant, Maven ), 就想將jtl文件的報告展現出來，弄了很久沒成功。最后還是向工具屈服，用的Ant來編譯.

主要是配置build.xml

一個示例：

out="${jmeter.result.htmlName}"

style="${jmeter.home}/extras/jmeter-results-detail-report_21.xsl" />

Jenkins 上安裝 “Publish performance test result report” ，“Publish HTML reports” 的插件，配置一下。

運行。

結果如下：

如果加上一些并發，負載等，就是性能測試報告了。

性能測試報告：

之前一直出了個錯：

Performance: Recording JMeter reports '**/*.jtl'

Performance: no JMeter files matching '**/*.jtl' have been found. Has the report generated?. Setting Build to FAILURE

Build step 'Publish Performance test result report' changed build result to FAILURE

Finished: FAILURE

導致結果出不來。后面在 Jmeter/bin 下將 jmeter.properties 中的：

jmeter.save.saveservice.output_format=csv

改成：

jmeter.save.saveservice.output_format=xml

結果就是這樣的：

作者：xuxinhong&snake

總結

以上是生活随笔為你收集整理的jmeter mysql驱动jar包_用 Jmeter 做 Web 接口测试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。