JMeter——使用 Jmeter 做 Web 接口測試

接口測試概述

定義

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的快速迭代和頻繁變更中很難維護。

什么是接口測試？

　　接口測試是測試系統組件間接口的一種測試。接口測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等。
　　接口測試適用於為其他系統提供服務的底層框架系統和中心服務系統，主要測試這些系統對外部提供的接口，驗證其正確性和穩定性。接口測試同樣適用於一個上層系統中的服務層接口，越往上層，其測試的難度越大。
　　接口測試實施在多系統多平台的構架下，有着極為高效的成本收益比，接口測試天生為高復雜性的平台帶來高效的缺陷監測和質量監督能力。平台越復雜，系統越龐大，接口測試的效果越明顯。
　　基於接口測試的重要性，以及它比較容易自動化的特性，通過持續集成的接口監控能夠及時的發現項目中存在的問題，這對持續運營的項目來說，非常重要。

接口測試的流程

　　1、 項目啟動后，測試人員要盡早找到開發人員拿到接口測試文檔
　　2、 獲取接口測試文檔后，就可以進行接口用例的編寫和調試
　　3、 接口用例編寫調試完成后，部署到持續集成的測試環境中，
　　4、 設定腳本運行頻率，告警方式等基本參數，進行接口的日常監控
　　5、 每日進行接口腳本的維護更新，接口異常的處理

分類

接口測試是測試系統組件間接口的一種測試。接口測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等。接口測試大體分為兩類：模塊接口測試和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語法規范的腳本語言,並且有自己的一些語法和方法[官網](http://www.beanshell.org/）
我的腳本幾乎所有驗證都是通過Beanshell腳本，只有少部分應用了Response Assert。

Beanshell 常用內置變量

（http://jmeter.apache.org/api/org/apache/jmeter/threads/）

下面是一些實際的例子

• 操作變量：(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 從（http://dev.mysql.com/downloads/connector/j/5.1.html）

• 拷貝這個文件到JMeter安裝路徑下的“lib"文件夾

• 建立“JDBC Connection Configuation"

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

• 添加JDBC request

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

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

• SQL語句不要加分號

• 如果查詢條件是變量，在語句中用“?”號代替，具體的值在下面的“Parameters Value"定義，如果有多個參數，中間要用分號隔開。當然也可以用${變量名｝（在用戶定義變量組件中已經定義）

• 對於“variable names" 數據表中有多少列就可以設置多少變量，對於不需要設置變量的列用逗號占位就可以了。

• 更具體的使用細節請參考（http://jmeter.apache.org/usermanual/component_reference.html#JDBC_Request）

• 獲取查詢結果數據在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

接下來做的事，lose同學已經推薦了一個鏈接 （https://testerhome.com/topics/2580），我覺得已經充分說明問題了，所以這里不再詳述。
（本文完）

 

轉自：https://testerhome.com/topics/4059#rd?sukey=014c68f407f2d3e110df8a19e94b469a8d7c439f82b16c670a12defe62ac9b58e57b2e066f2d71fb347a038858bf784a，https://testerhome.com/topics/2580