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

轉載于:https://www.cnblogs.com/sheropan/p/5210099.html