淺談postman和jmeter的用法與區別

前階段作了一個小調查，發現軟件測試行業作功能測試和接口測試的人相對比較多。在測試工做中，有高手，天然也會有小白，但有一點咱們沒法否定，就是每個高手都是從小白開始的，因此今天咱們就來談談一大部分人在作的接口測試，小白變高手也許你只差這一次深刻了解！

接口測試的目的

已是老生常談了，我想不用我說，凡是說到接口總會被問及這個話題，的確，沒有目標就沒有評定標準，知道其目的也是相當重要的。

接口測試的目的經過英文翻譯呈現以下：

API 測試是一種做爲集成測試的一部分，經過直接控制被測應用的接口（API）來肯定是否在功能、可靠性、性能和安全方面達到預期的軟件測試活動。因爲 API 都沒有 GUI 界面，API 測試都是在通信層進行的。如今 API 測試在自動化測試中有着很重要的地位，由於 API 通常是應用邏輯的主要接口，同時 GUI 測試在敏捷開發和 DevOps 的快速迭代和頻繁變動中很難維護。

在進行接口測試前，還須要瞭解：

1）、GET和POST請求：若是是get請求的話，直接在瀏覽器裏輸入就好了，只要在瀏覽器裏面直接能請求到的，都是get請求，若是是post的請求的話，就不行了，就得藉助工具來發送。

GET請求和POST請求的區別：

一、GET使用URL或Cookie傳參。而POST將數據放在BODY中。

二、GET的URL會有長度上的限制，則POST的數據則能夠很是大。

三、POST比GET安全，由於數據在地址欄上不可見。

四、通常get請求用來獲取數據，post請求用來發送數據。

2）、http狀態碼

每發出一個http請求以後，都會有一個響應，http自己會有一個狀態碼，來標示這個請求是否成功，常見的狀態碼有如下幾種：

一、200 2開頭的都表示這個請求發送成功，最多見的就是200，就表明這個請求是ok的，服務器也返回了。

二、300 3開頭的表明重定向，最多見的是302，把這個請求重定向到別的地方了，

三、400 400表明客戶端發送的請求有語法錯誤，401表明訪問的頁面沒有受權，403表示沒有權限訪問這個頁面，404表明沒有這個頁面

四、500 5開頭的表明服務器有異常，500表明服務器內部異常，504表明服務器端超時，沒返回結果

3）web service的接口如何測試：

它不須要你在拼報文了，會給一個webservice的地址，或者wsdl文件，直接在soapui導入，就能夠看到這個webservice裏面的全部接口，也有報文，直接填入參數調用，看返回結果就能夠了。

4）cookie與session的區別：

一、cookie數據存放在客戶的瀏覽器上，session數據放在服務器上。

二、cookie不是很安全，別人能夠分析存放在本地的cookie並進行cookie欺騙考慮到安全應當使用session。

三、session會在必定時間內保存在服務器上。當訪問增多，會比較佔用你服務器的性能考慮到減輕服務器性能方面，應當使用cookie。

四、單個cookie保存的數據不能超過4K，不少瀏覽器都限制一個站點最多保存20個cookie。

五、因此我的建議：

將登陸信息等重要信息存放爲session

其餘信息若是須要保留，能夠放在cookie中

接口測試怎麼測：

1）、通用接口用例設計

①、經過性驗證：首先確定要保證這個接口功能是好使的，也就是正常的經過性測試，按照接口文檔上的參數，正常傳入，是否能夠返回正確的結果。②、參數組合：如今有一個操做商品的接口，有個字段type，傳1的時候表明修改商品，商品id、商品名稱、價格有一個是必傳的，type傳2的時候是刪除商品，商品id　　是必傳的，這樣的，就要測參數組合了，type傳1的時候，只傳商品名稱能不能修改爲功，id、名稱、價格都傳的時候能不能修改爲功。

③、接口安全：

一、繞過驗證，好比說購買了一個商品，它的價格是300元，那我在提交訂單時候，我把這個商品的價格改爲3元，後端有沒有作驗證，更狠點，我把錢改爲-3，是否是個人餘額還要增長？

二、繞過身份受權，好比說修改商品信息接口，那必須得是賣家才能修改，那我傳一個普通用戶，能不能修改爲功，我傳一個其餘的賣家能不能修改爲功

三、參數是否加密，好比說我登錄的接口，用戶名和密碼是否是加密，若是不加密的話，別人攔截到你的請求，就能獲取到你的信息了，加密規則是否容易破解。

四、密碼安全規則，密碼的複雜程度校驗

五、異常驗證：

所謂異常驗證，也就是我不按照你接口文檔上的要求輸入參數，來驗證接口對異常狀況的校驗。

2）、根據業務邏輯來設計用例

根據業務邏輯來設計的話，就是根據本身系統的業務來設計用例，這個每一個公司的業務不同，就得具體的看本身公司的業務了，其實這也和功能測試設計用例是同樣的。列出測試點，而後再去造數據測試對應的測試點。

用什麼工具測

接口測試的工具不少，好比 postman、RESTClient、jmeter、loadrunner、SoapUI等，這裏主要說下最近看到的一些接口測試工具方面的帖子，簡單彙總一下他們的實現方式：

本人首推的測試工具是postman和jmeter，接下來就簡單介紹下如何使用這兩款工具進行接口測試，其餘工具本次暫不介紹。

1.建立接口用例集（沒區別）

Postman是Collections，Jmeter是線程組，沒什麼區別。

2.步驟的實現（有區別）

Postman和jmeter都是建立http請求
區別1：postman請求的請求URL是一個總體，jmeter分紅了4個部分（協議、主機、端口、路徑）
區別2：postman能夠在請求中直接填寫請求頭信息，  jmeter須要經過添加http請求頭管理器添加請求頭
區別3：對於cookie，postman能夠對cookie作管理，可是jmeter只需添加http cookie管理器便可完成cookie的處理，而且是自動處理cookie信息，因此jmeter的cookie管理更簡單

Postman在pre-request script能夠添加前置請求，獲取響應數據，比較容易進行json結果的處理，很方便的提取json數據——————jmeter不只能夠處理json數據，（json提取器），還能夠提取其餘數據（正則表達式提取器）

3數據用例的實現

區別1：jmeter比較適合進行數據與操做分離，而postman比較適合把數據和操做放在一塊兒，顯然postman操做更簡單，jmeter更便於維護

區別2： postman也支持csv數據文件的導入，可是每次執行時都須要收工加載數據文件。不方便（因此只能作半自動化）
  Jmeter能夠進行徹底自動化，特別是引入ant後效果更明顯

4斷言的實現

區別1：Postman有不少自帶的斷言函數，直接引用便可，操做很是方便。。。 jmeter也自帶斷言組件，操做很是直觀。 區別： postman用函數斷言， jmeter用元件進行斷言

區別2：jmeter支持正則表達式斷言，postman不支持

區別3：Jmeter的斷言更豐富。 postman須要經過編程來實現一樣的效果，因此難度更大

5執行

區別：默認執行，postman不能保存結果，jmeter能夠報存結果
Postman能夠經過newman實現批量執行和保存結果，jmeter能夠經過ant實現批量執行和保存結果

6其餘

Postman比較適合作手工接口測試，由於簡單，能夠實現半自動化
Jmeter比較適合自動化接口測試，由於功能強大而且能夠保存腳本，批量執行設置很容易
Postman通常用來作接口測試，用來發現BUG，驗證後臺程序
Jmeter通常用來作自動化測試，作冒煙測試。

Postman是谷歌的一款接口測試插件，它使用簡單，支持用例管理，支持get、post、文件上傳、響應驗證、變量管理、環境參數管理等功能，能夠批量運行，並支持用例導出、導入。

jmeter是一款100%純Java編寫的免費開源的工具，它主要用來作性能測試，相比loadrunner來講，它內存佔用小，免費開源，輕巧方便、無需安裝，愈來愈被大衆所喜好。

注：如下用例中所用地址皆爲本人在本地所搭的環境，外網沒法訪問，見諒。

①、獲取用戶信息：該接口用於經過userid獲取用戶信息

請求地址：http://192.168.1.102:8081/getuser

請求方式：POST/GET

入參：

 

出參：

postman中請求以下

jmeter中請求以下：

②、獲取用戶信息：須要添加header，Content-Type application/json

1.1 請求地址

http://192.168.1.102:8081/getuser2

1.2 請求方式

get/post

1.3 入參

1.4 出參

postman測試以下，本次入參爲json類型，固然文檔中沒說非要用json，用其餘方式也是能夠的

jmeter測試以下

③、修改用戶餘額2

1.1 功能描述

功能描述：須要添加cookie，token token是寫死的token12345

1.2 請求地址

http://192.168.1.102:8081/setmoney2

1.3 請求方式

Post

1.4 入參

1.5 出參

postman測試以下：

jmeter測試以下：

④文件上傳

postman：

jmeter:

⑤、請求webService接口

請求webService接口須要用到的工具是SoapUI，以下圖

在jmeter裏請求以下：

總結：

作好接口測試並無那麼簡單，固然只要找對方法和工具，一切都沒有你想象中那麼複雜！

無論怎樣，既然開始了，那就要想辦法把它作好。接下來我會使用新的設計用例思路作我未完成的接口測試用例，並修改Java 代碼讓其支持使用excel做爲用例。上述分享中若是有不對的地方，歡迎你們及時提出