介面測試工具怎麼測試加密介面

Ⅰ 介面測試怎麼才能做好

這個問題還是從需求、測試用例設計、執行來說吧。

首先要了解這個介面提供的服務的需求定義，那麼我們就知道大概測試的結果是啥。同時理論上要先提供介面規范，方便後續測試，以及給調用者聯調的一個文檔約定。

根據測試的介面規范，基於業務進行場景設計，再結合邊界值設計方法、等價類劃分等常用設計方法進行用例設計。

1.設計的方向是常規的測試用例設計：協議規范測試、介面入參、介面出參。

協議規范測試：比如HTTP協議：URL地址、Header測試。不過一般情況下，默認調用者按照介面規范正常調用。這個不用過於詳細測試。

2.介面入參：參數個數測試(注意是否必傳欄位），參數值測試（為空、正常值、非法值等，以及首尾有空格是否過濾）。

3.介面出參：至少涵蓋一條成功的響應和一條失敗的響應，當然我們測試出更多錯誤碼，我們的覆蓋率也就更全面。

4.業務場景用例： 這個需要你對於這個介面的業務的了解程度，而且這是最重要的部分。

比如中間使用了緩存服務（第一次緩存沒有，是不是直接讀數據源，並存入緩存；第二次直接讀取緩存是否正確）；

比如需要考慮請求外部的介面獲取相應的信息的時間損耗（連接不上外部介面，外部介面下線了，外部介面響應太慢）；

1.需要你對介面協議有一定的了解，選擇適當的開源工具（如postman）或者自己編寫腳本進行模擬請求。

2.需要熟悉介面所使用的中間件等知識（比如redis、kafka、mysql資料庫）。

3.需要模擬外部介面返回給你現在正在驗證的程序的介面。（比如扣費業務，你不可能每測一個業務，就去調真實扣費）。

是web開發介面嗎？建議使用Postman

一、什麼是介面？

介面測試主要用於外部系統與系統之間以及內部各個子系統之間的交互點，定義特定的交互點，然後通過這些交互點來，通過一些特殊的規則也就是協議，來進行數據之間的交互。

二、 常用介面採用方式：

1、webService介面：是走soap協議通過http傳輸，請求報文和返回報文都是xml格式的，我們在測試的時候都用通過工具才能進行調用，測試。可以使用的工具有apipost、jmeter、loadrunner等；

2、http api介面：是走http協議，通過路徑來區分調用的方法，請求報文都是key-value形式的，返回報文一般都是json串，有get和

post等方法，這也是最常用的兩種請求方式。可以使用的工具有apipost、jmeter、loadrunner等；

三、前端和後端

前端：網站前端是對網頁靜態頁面的設計，通俗的來說，就是我們肉眼能看的到的東西，當我們瀏覽網站的時候所看到的頁面上的內容幾乎都是屬於前端，前端的工作就是網站頁面，靜態的頁面是沒有後端成分的，前端主要包括html和css外加js等一些樣式和布局。

後端: 網站的後端就是動態網站的技術，比如網站上的一些注冊登錄和一些彈窗，這些都是後端的邏輯，常用的後端語言有php，jsp等，後端的資料庫也包含myspl等，都是對後端進行存儲數據。

四、 介面測試概念

介面測試是測試系統組件間介面的一種測試。介面測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等(通俗來說就是，檢查業務邏輯是否滿足業務需求，校驗欄位是否正常你實際結果是否滿足預期)

五、 介面的組成:

a、介面說明

b、調用url

c、請求方法（getpostput等）

d、請求參數、參數類型、請求參數說明

e、返回參數說明

六、為什麼要做介面測試，介面測試的目標

介面其實app和前端交互用的,所以好多人問，為啥做功能測試還要測介面，目標是啥不是多此一舉嗎?首先我告訴大家，這種想法是錯誤的

那麼舉一個例子:

例如一個登陸介面，例如產品上規定用戶名6-10個字元數字下劃線，但後端沒做判斷。但我們業務人員測試肯定驗證，但只是前端做了校驗，後端壓根就忘了這個小需求.那麼後果來了如果一個懂的直接抓包去篡改你的介面，然後繞過校驗，通過sql注入直接隨意登錄。如果你這是一個下單業務，是不是給公司造成了很大損失

所以此時此刻介面測試目標來了:

1.可能發現客戶端沒有發現的bug(那麼也叫隱藏bug)

2.及早爆出風險（保證質量正常上線）

3.介面穩定了，前端隨便改

4.最重要檢查系統安全性，穩定性

七、如何進行介面測試

1.使用介面測試工具進行測試，介面測試和介面文檔生成工具apipost，介面測試和性能測試工具jmeter

2.介面狀態碼表示含義

例如:200(成功)/300（重定向別的地方）/400（請求語法錯誤）/500(伺服器異常)

測試點:

B. 參數組合（傳入不同值）

C. 介面安全(繞過驗證/繞過身份驗證/參數是否加密等)

D. 異常驗證（輸入異常參數邊界值）

練

Ⅱ MeterSphere介面測試中使用beanshell腳本進行md5加密

import org.apache.commons.codec.digest.DigestUtils;

//導入org.apache.commons.codec.digest.DigestUtils;

String timeStamp = "${__time(/1000,)}";

//定義時間timeStamp=伺服器時間;

String randomStr = "${__Random(11111111,99999999)}";

//定義時間隨機數=8位1-9的隨機數;

String tmp = timeStamp + randomStr + "xxxxx";

//定義tmp=時間timeStamp，8位隨機數和密碼xxxxx;

log.info("timeStamp:" + timeStamp);

//列印timeStamp;

log.info("randomStr:" + randomStr);

//列印randomStr;

log.info("tmp:" + tmp);

//列印tmp;

//String un = DigestUtils.sha1Hex(tmp);

//定義un=哈希sha1加密的tmp;

//log.info("un:" + un);

//列印un;

String signature = DigestUtils.md5Hex (DigestUtils.sha1Hex(tmp)).toUpperCase();

//定義signature==哈希sha1加密的tmp然後再進行md5加密後進行大寫;

log.info("signature:" + signature);

//列印signature;

vars.put("signature", signature);

//列印signature;

vars.put("timeStamp", timeStamp);

//列印timeStamp;

vars.put("randomStr", randomStr);

//列印randomStr;

Ⅲ 如何做介面測試

1、可以使用postman軟體進行介面測試，這里以較復雜的上傳圖片的介面為例進行測試，首先打開postman軟體選擇Post方式，輸入後台介面調用地址。

Ⅳ 介面測試面試題，等你來看

1.你們公司的介面測試流程是？

介面測試我們是在xx項目做的，主要有xx介面，xx介面等

1.首先是從開發那裡拿到API介面文檔，了解介面業務、包括介面地址、介面方式、入參、出參、token鑒權，返回格式等信息。

2.然後使用postman或jmeter工具執行介面測試，一般使用Jmeter的步驟是這樣的：

3.最後調試並執行用力，最後編寫介面測試報告。

4.其實我們做介面的時候也碰到過很多的問題，都是自己獨立解決的，比如返回值亂碼（修改jmeter的配置文件為UTF-8編碼方式），比如需要登陸後才能取得token鑒權編碼並且這個鑒權碼在下面的請求中需要用到（使用正則表達式提取器提取token的值等等。

2.簡述cookie、session及token的區別

1.cookie數據存放在客戶的瀏覽器上，session數據放在伺服器上。而token是介面數據的鑒權碼，一般情況下登錄後才可以獲取到token，然後在每次請求介面時需要帶上token參數。

2.cookie不是很安全，別人可以分析存放在本地的cookie並進行cookie欺騙，考慮到安全應到使用seesion，seesion會在一定時間內保存在伺服器上。當訪問增多，會比較佔用你伺服器的性能，考慮到減輕伺服器性能方面應當使用cookie。

3.可以將登錄信息等重要信息存放為session；其他信息需要保存，可以放在coolie。

3.對於加密介面，如何進行測試？

在調用介面的時候，要搞清楚介面的加密方式是什麼。

如果是對稱加密，要先從開發哪裡獲取對稱密鑰，基於對稱密鑰可以加密請求數據，以及解密響應報文。

如果是非對稱加密，先從開發獲取伺服器公鑰和私鑰，也要知道當前用戶的公鑰和私鑰信息。以便完成介面的數據加密和解密。

4.介面測試執行中比對資料庫嗎？

肯定，因為介面返回值的數據來源於資料庫，介面對數據的操作還要進行深層次的資料庫檢查！

5.如何分析一個bug是前端還是後端

這種情況很容易判斷，先抓包看請求報文，對著介面文檔，看請求報文有沒有問題，有問題就是前端發的數據不對；

請求報文沒問題，那就看返回報文，返回的數據不對那就是後端開發的問題。

6.談談你對HTTP協議的了解？

超文本傳輸協議，埠為80，特點（無記憶功能、快速）是由請求和響應兩部分組成請求由請求頭、請求行、請求正文組成；響應是由響應頭、響應行、響應正文組成，之前我們公司的介面是採用https協議的。

httpshttp+ssl協議埠443面向安全的超文本傳輸協議。

7.get和post請求有什麼區別？

get和post請求都是客戶端向伺服器提交的一種請求方式；

get是明文傳輸參數、傾向於請求伺服器資源。比如打開網站；

post傳輸數據不可見，安全性高，傾向於向伺服器提交數據，比如注冊等。

8.依賴於第三方數據的介面如何進行測試

可以使用SoapUI等工具直接調用第三方數據介面的webservice,通過返回值來查看第三方數據的介面是否調用正常。

也可以利用一些工具來模擬第三方的數據返回，最大限度地降低對第三方數據介面的依賴。

9.介面測試中要注意的測試點有哪些？

介面中返回了圖片地址，要手工去進行圖片的測試（大小、內容）；

介面完成查詢功能的時候，數據返回的排序顯示；

10.介面執行測試返回結果比對哪部分？

之前必須要對比的就是返回狀態碼，其次再去對比返回其它關鍵內容。

11.做介面測試工作的意義是什麼？

這個是開發性題目，面試官主要考察對測試的理解。

根據測試的金字塔模型來說介面測試是測試左移的最方便，最簡單的測試，當然最厲害的測試是做白盒測試，這個是在介面測試之前，相對於單元測試。

12.用過抓包工具嗎？如何使用？

之前在項目中用過fiddler抓包工具進行HTTP協議請求的抓取。

打開fiddler之後，默認瀏覽器配置了127.0.0.18888埠的代理，在fiddler設置好過濾策略後，打開需要進行抓包的網站進行操作，就可以進行抓包。

13.介面測試中需要哪些注意點？

14.postman中設置環境變數有什麼用？

在之前項目中，介面測試測試的環境有開發環境，測試環境等，為了測試的時候方便，就在postman設置環境變數，到時所有介面都引用該環境變數，這樣就不用為了切換環境導致每次都去修改被測系統介面的主機地址；點擊右上角環境變數管理按鈕-新建環境變數，在腳本中使用{undefined{變數名}}去調用。

15.關聯是什麼？如何postman設置關聯？

關聯就是把上一個介面返回值的部分截取出來，作為下一個介面的參數，能讓介面串聯運行。

在postman中設置關聯的步驟如下：

先通過正則表達式提取的方式或json取值的方式把下一個介面需要的信息從上一個介面截取出來；

使用設置全局變數的代碼把取出來的值保存到全局變數；

在下一個介面中，使用{undefined{全局變數}}代替要替換的靜態值。

Ⅳ fiddler抓包詳細教程--介面測試

前言

Fiddler最大的優勢在於抓包，我們大部分使用的功能也在抓包的功能上，fiddler做介面測試也是非常方便的。

對應沒有介面測試文檔的時候，可以直接抓完包後，請求參數，修改下就可以了。

Composer簡介

點開右側Composer區域，可以看到如下界面，就是測試介面的界面了

1.請求方式：點開可以勾選請求協議是get、post等

2.url地址欄：輸入請求的url地址

3.請求頭：第三塊區域可以輸入請求頭信息

4.請求body：post請求在此區域輸入body信息

5.執行：Execute按鈕點擊後就可以執行請求了

6.http版本：可以勾選http版本

7.請求歷史：執行完成後會在右側History區域生成歷史記錄

模擬get請求

1.在Composer區域地址欄輸入博客首頁： http://www.cnblogs.com/yoyoketang/

2.選擇get請求，點Execute執行，請求就可以發送成功啦

3.請求發送成功後，左邊會話框會生成一個會話記錄，可以查看抓包詳情

4.右側history區域會多一個歷史請求記錄

5.會話框選中該記錄，查看測試結果：

選中該會話，點開Inspectors

response區域點開Raw區域

Raw查看的是HTML源碼的數據

也可以點WebView，查看返回的web頁面數據

Json數據

1.有些post的請求參數和返回參數是Json格式的，如博客園的登錄請求： https://passport.cnblogs.com/user/signin

2.在登錄頁面手動輸入賬號和密碼，登錄成功。

3.找到這個登錄成功的會話，查看json數據如下圖：

模擬post請求

1.請求類型勾選post

2.url地址欄輸入對應的請求地址

3.body區域寫登錄的json參數，json參數直接上一步抓包的數據，如下圖紅色區域

4.header請求頭區域，可以把前面登錄成功後的頭部抓包的數據過來

（注意，有些請求如果請求頭為空的話，會請求失敗的）

5.執行成功後查看測試結果：

–執行成功如第三所示的圖，顯示success=True

–執行失敗如下圖所示，顯示

message=Invalid length for a Base-64 char array or string.

success=False

get請求（url詳解）

前言

上一篇介紹了Composer的功能，可以模擬get和post請求，get請求有些是不帶參數的，這種比較容易，直接放到url地址欄就行。有些get請求會帶有參數，本篇詳細介紹url地址格式。

url詳解

1.url就是我們平常打開網路在地址欄輸入的： https://www..com ,如下圖，這個是最簡單的url地址，打開的是網路的主頁

2.再看一個稍微復雜一點的url，在網路輸入框輸入：上海悠悠博客園

3.查看url地址欄，對比之前的網路首頁url地址，後面多了很多參數。當然最主要的參數是:wd=上海悠悠博客園（後面的一大串可以暫時忽略）。

4.那麼問題來了，這些參數有什麼作用呢？

可以做個簡單的對比，在地址欄分別輸入：

https://www..com

https://www..com/s?wd=上海悠悠博客園

對比打開的頁面有什麼不一樣，現在知道作用了吧，也就是說這個多的」/s？wd=上海悠悠博客園」就是搜索的結果頁面

url解析

1.以」 https://www..com/s?wd=上海悠悠博客園」這個url請求的抓包為例

2.那麼一個完整的url地址，基本格式如下：

https://host :port/path?xxx=aaa&ooo=bbb

http/https：這個是協議類型，如圖中所示

host:伺服器的IP地址或者域名，如圖中2所示

port:HTTP伺服器的默認埠是80，這種情況下埠號可以省略。

如果使用了別的埠，必須指明，例如：192.168.3.111:8080，這里的8080就是埠

path:訪問資源的路徑,如圖中3所示/s (圖中3是把path和請求參數放一起了)

？:url裡面的？這個符號是個分割線，用來區分問號前面的是path，問號後面的是參數

url-params:問號後面的是請求參數，格式：xxx=aaa，如圖4區域就是請求參數

&：多個參數用&符號連接

請求參數（params）

1.在url裡面請求參數一般叫params，但是我們在fiddler抓包工具看到的參數是：QueryString

2.QueryString是像服務端提交的參數，其實跟params是一個意思，每個參數對應的都有name和value值

3.多個參數情況如下：

UrlEncode編碼

1.如果url地址的參數帶有中文的，一般在url裡面會是這樣的，如第二點里的wd=%E4%B8%8A%E6%B5%B7%E6%…

像看到%E4這種編碼的就是經過url編碼過的，需要解碼就能看到是什麼中文了

2.用urlencode在線編碼/解碼工具，地址： http://tool.chinaz.com/tools/urlencode.aspx

post請求（body）

前言上一篇講過get請求的參數都在url里，post的請求相對於get請求多了個body部分，本篇就詳細講解下body部分參數的幾種形式。

注意：post請求的參數可以放在url，也可以放在body，也可以同時放在url和body，當然post請求也可以不帶參數。

只是一般來說，post請求的參數習慣放到body部分

body數據類型

常見的post提交數據類型有四種：

1.第一種：application/json：這是最常見的json格式，也是非常友好的深受小夥伴喜歡的一種，如下

2.第二種：application/x-www-form-urlencoded：瀏覽器的原生 form 表單，如果不設置 enctype 屬性，那麼最終就會以 application/x-www-form-urlencoded 方式提交數

3.第三種：multipart/form-data:這一種是表單格式的，數據類型如下：

4.第四種：text/xml:這種直接傳的xml格式

json格式

1.打開博客園的登錄頁面，輸入賬號密碼後抓包，查看post提交數據，點開Raw查看整個請求的原始數據

2.前面講過post的請求多一個body部分，上圖紅色區域就是博客園登錄介面的body部分，很明顯這種格式是前面講到的第一種json格式

3.查看json格式的樹狀結構，更友好，可以點開JSON菜單項

4.查看這里的json數據，很明顯傳了三個參數：

input1:這個是登錄的賬號參數（加密過）

input2:這個是登錄的密碼參數（加密過）

remember:這個是登錄頁面的勾選是否記住密碼的選項，False是不記住，True是記住

x-www-form-urlencoded

1.登錄博客園後，打開新隨筆，隨便寫一個標題和一個正文後保存，抓包數據如下

2.如上圖的這種格式，很明顯就屬於第二種了，這種類型的數據查看，在WebFrom裡面查看了

3.上面紅色框框的Query String是url裡面的參數，下面紅色框框的body部分就是這次post提交的body參數部分了。

WebFrom

1.為什麼登錄請求的WebFrom的body部分為空呢？

2.看上圖紅色框框的顯示：這里只支持application/x-www-form-urlencoded這種格式的body參數，也就是說json格式的，需要在JOSN這一欄查看了。

Ⅵ 談談單介面測試

如果只是單個介面的測試還是歸屬於功能測試。

平時我們是怎麼做介面測試的？
介面文檔、介面文檔，一定要看介面文檔。
初學者做介面測試必須要先會一個工具，postman、fiddler、charles。後兩者更多應用於抓包，但都可以使用。
也可以自己寫一個介面請求函數，然後給返回的響應數據做斷言。達到介面測試的目的。
一般做單介面測試我們是從這幾個方面考慮：
1、通過性驗證，在測這個介面之前必須保證這個介面是可用的，是通的，相當於冒煙測試。
2、請求介面參數組合傳參，在正常規則內進行組合傳參，請求參數各個欄位值驗證，參數是否必傳。
3、請求介面順序（繞過驗證），例如，登錄後才能下單購買，當未進行登錄時，下單介面請求是不能成功的。
4、異常驗證，必填項驗證、字元類型、長度等等，就是不按照介面文檔進行傳參。
5、安全性，驗證header，敏感數據加密等。
6、響應結果，各種場景下請求介面的返回結果，對應的結構體和參數。
7、響應時間，遵守1357規則，根據實際場景而定。
8、介面邏輯，提交多次介面、並發，業務邏輯等。

當然有些小公司為了趕工期或者其他各種原因是沒有介面文檔的，那麼這樣情況該怎麼辦？
一句話，沒有介面文檔很難搞，抓包看參數，先保證介面通過性驗證，然後從開發和產品獲取信息，決定對那些進行驗證。

再說下怎麼判斷bug是前後端誰的問題？
介面請求參數有問題找前端，返回參數有問題先分析下具體問題，一般是找後端（常見的40X/50X），路徑或者是伺服器的問題。

Ⅶ MeterSphere介面測試中使用beanshell腳本進行參數哈希sha1加密

需求是這樣的，token是從第三步介面進行產生的。通過腳本

import org.apache.commons.codec.digest.DigestUtils;

//導入org.apache.commons.codec.digest.DigestUtils包;

String sign = DigestUtils.sha1Hex ("${__time}${token}xxxxx").toUpperCase( );

//定義sign=伺服器時間+token+固定密碼xxxxx;然後.toUpperCase( )大寫傳出;

vars.put("sign", sign); 

//導出簽名以第四條介面使用;

第4條case直接使用${sign}就可以使用上一步的sign進行加密

Ⅷ 如何使用WebSocket做介面測試

如果遇見了一個全新的協議，怎麼從零開始，完成介面測試？以 WebSocket 為例。

WebSocket 協議在2008年誕生，2011年成為國際標准。現在所有瀏覽器都已經支持了。WebSocket 的最大特點就是，伺服器可以主動向客戶端推送信息，客戶端也可以主動向伺服器發送信息，是真正的雙向平等對話。

WebSocket 的其他特點：

1. 建立在 TCP 協議之上，伺服器端的實現比較容易。

2. 與 HTTP 協議有著良好的兼容性。默認埠也是80和443，並且握手階段採用 HTTP 協議，因此握手時不容易屏蔽，能通過各種 HTTP 代理伺服器。

3. 數據格式比較輕量，性能開銷小，通信高效。

4. 可以發送文本，也可以發送二進制數據。

5. 沒有同源限制，客戶端可以與任意伺服器通信。

6. 協議標識符是ws（如果加密，則為wss），伺服器網址就是 URL。

· ws–>http（未加密） 無證書
· wss–>https（加密） 有證書

第一步：

很多時候第一反應向開發工程師求助，因為開發工程師基於新協議已經完成了介面開發，向開發工程師求助顯然是最好的辦法。找到一些學習脈絡，包含了協議的說明文檔、代碼開發文檔、實現代碼等內容，了解協議的原理。向開發求助是個方法。

那麼 WebSocket 用 Fiddler 怎麼搞定？，其實主要就是修改了 Fiddler 中 Rules 下的 Customize Rules，如果感興趣可以自己去搜一下。當面對陌生技術問題的時候，應該使用最熟悉的技術去嘗試解決問題。雖然 Fiddler 截獲 WebSocket 介面的辦法，所截獲的全部消息都在日誌裡面，根本無法操作。但是，可以藉助 Fiddler 分析 WebSocket 的介面，一開始給 Fiddler 這款工具的定位一樣，那就是通過它輔助分析我們的被測介面。處理HTTP、HTTPS，推薦用Fiddler。

但是在處理TCP,UDP 就用WireShark。Websocket是應用層協議，建立在 TCP 協議之上，伺服器端的實現比較容易。因為應用層是在傳輸層的基礎上包裝數據，所以我們還是從底層開始了解Websocket到底是個啥?是如何工作的?

可以通過---- wireshark（網路封包分析軟體）抓包工具抓到WebSocket介面

wireshark下載地址：https://www.wireshark.org/download.html

以下是python實現的websocket 介面連接。

Ⅸ 介面sign加密怎麼做介面測試

對於介面測試來說，項目測試用例的重復運行首先是表現在單個測試用例的獨立性方面的，也就是說，每一個測試用例的運行除了依賴被測對象和對應的資料庫環境外，是不依賴於其他任何測試用例的，並且這個測試用例執行完畢後

Ⅹ 介面測試中的加密演算法如何實現

加密實現對於測試而言，的確是件頭疼的事情，畢竟大多數測試沒有編碼基礎，即便有編程也是短板，要是實現加密演算法的話，主要有兩種方式:
1. 可以以純編碼的方式實現,比如使用 Java 或 Python等
2. 如果是測試工具的話，比如Jmeter，可以求助開發將加密演算法導出為 jar 包，然後我們測試再在 Jmeter 中導入jar包，再調用類似於 BeanShell 取樣器的組件，調用開發提供的加密函數(可以一定程度的減少代碼量) 獲得更多關於測試的知識，建議你去找視頻學習一下，黑馬程序員官網就有很多專業的視頻，應該挺適合你的。