使用 Jmeter 做 Web 介面測試

標籤：介面   sso   快速   log檔案   命令列   listener   cad   服務   獨立   

介面測試概述定義

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文法規範的指令碼語言,並且有自己的一些文法和方法[官網](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），我覺得已經充分說明問題了，所以這裡不再詳述。
（本文完）

使用 Jmeter 做 Web 介面測試