測試 - Postman篇之特殊接口

目錄

• about
• 簽名接口
• cookie
• token
• webservice接口

• 返回Postman目錄

about

除了快速上手部分的那些基本的接口，還有一些其他特殊的接口，比如簽名接口校驗、攜帶cookie和token的接口等等。

簽名接口

在寫開放的API接口時是如何保證數據的安全性的？我們通過http Post或者Get方式請求服務器的時候，會面臨着許多的安全性問題，例如：

1. 請求來源(身份)是否合法？
2. 請求參數被篡改？
3. 請求的唯一性(不可復制)

為了保證數據在通信時的安全性，我們可以采用參數簽名的方式來進行相關驗證。

那postman中怎么校驗這種類型的接口呢？

這個url接口，來演示一下：

# URL
http://www.neeo.cc:6002/pinter/com/userInfo	
# 類型
POST
# 參數
{"phoneNum":"123434","optCode":"testfan","timestamp":"12112121212","sign":"Md5(手機號+鹽+時間戳)"}

上面的參數中，需要手機號，optCode字段是個固定值testfan，這個別改；時間戳字段timestamp是當前的時間戳，sign字段是需要一個算法來生成的。

這個接口的簽名算法為：

sign = Md5(手機號+鹽+當前時間戳)  # 加號代表拼接

很明顯，這些操作，都要在postman中操作，那么比如獲取時間戳和加密都需要JavaScript來完成，我們先來把用到的知識點列出來：

// 獲取時間戳
var t = new Date().getTime();
// 加密
var md5 = CryptoJS.MD5("需要加密的字符串").toString();
// postman保存變量
pm.environment.set("要保存的變量名", md5)

來看postman中怎么測試。

首先要說的是，參數中的需要的數據，都需要在發送請求之前配置到位，那么在哪處理，又怎么處理呢？

// 1. 處理手機號 phoneNum
var myPhone = "18211101111"

// 2. 操作碼 optCode
var myOptCode = 'testfan'

// 3. 時間戳
var myTimeStamp = new Date().getTime();

// 4. 將上面的3個變量拼接起來
var myData = myPhone + myOptCode + myTimeStamp;

// 5. 使用md5加密
var mySign = CryptoJS.MD5(myData).toString();
console.log(myOptCode, myTimeStamp, myData, mySign);

// 6. 將相關變量添加到postman中
pm.environment.set("myPhone", myPhone);
pm.environment.set("myOptCode", myOptCode);
pm.environment.set("myTimeStamp", myTimeStamp);
pm.environment.set("mySign", mySign);

首先，我們確定了這些操作要在請求發送之前處理好，那么我們就先將上述整理好的代碼粘貼到合適的位置。

如下圖，在Pre-request Script中，編寫代碼。然后在控制台中，看看查打印結果，可以看到，已經加密成功了，說明我們的代碼邏輯沒有問題。

來看原來的參數：

{"phoneNum":"123434","optCode":"testfan","timestamp":"12112121212","sign":"Md5(手機號+鹽+時間戳)"}

現在， 我們需要將相關的字段替換為我們之前添加到postman中的變量，下面是替換后的json串。

{"phoneNum":"{{myPhone}}","optCode":"{{myOptCode}}","timestamp":"{{myTimeStamp}}","sign":"{{mySign}}"}

然后，我們將替換后的json字符串替換到請求的body中，然后發送請求，查看響應結果。

ok，經過一系列的操作，我們終於將這個簽名接口調通了。

cookie

再來看postman如何處理需要攜帶cookie的接口。

先來一個場景，用戶需要登錄某網站，登錄成功，返回一個cookie，然后用戶需要攜帶cookie在進行進一步操作，比如查詢余額等。

我們測試這種類型的接口時，有兩種方式：

• 第一種，就是我們使用瀏覽器登錄，獲取cookie值，然后手動攜帶。
• 第二種，就是借助postman幫我們自動的管理cookie值。

先來看第一種方式。

登錄接口的相關參數：

url: http://www.neeo.cc:6002/pinter/bank/api/login
類型：POST
參數：userName=admin&password=1234

查詢余額接口相關參數：

url: http://www.neeo.cc:6002/pinter/bank/api/query
類型：GET
參數：userName=admin

查詢余額接口必須依賴登錄成功返回的cookie。

首先，我們需要在瀏覽器中訪問http://www.neeo.cc:6002/pinter/bank/page/login連接， 輸入admin&1234進行登錄，登錄成功后，我們獲取到了cookie值。

現在，保持登錄狀態，我們使用postman訪問查詢余額接口http://www.neeo.cc:6002/pinter/bank/api/query?userName=admin。

暫時還沒有加cookie，我們查詢余額失敗。現在，我們從瀏覽器中拷貝cookie值，添加到查詢余額的請求頭中，再次訪問。

這種相對比較麻煩。

我們來看第二種，在postman中，新建一個登錄的接口。

然后，我們在查詢余額接口中，就不用攜帶cookie了，直接訪問即可。

現在，發現，訪問成功了。如上圖，我們打開Temporary Headers，發現本次請求，postman自動的幫我們攜帶了cookie，才能訪問成功。

其實，postman自動的幫我門管理了cookie。在哪看呢，點擊上圖中的綠色框中的Cookies可以發現那個cookie值。

這里也可以自己添加cookie，看你需求吧。

token

來研究一下postman如何處理需要攜帶token的接口。

這里用到postman的數據管理的功能，該功能對token進行處理。

關鍵步驟：

// 從響應中獲取json數據
var jsonData = pm.response.json();

// 從json中的相應字段提取token
var myToken = jsonData.meassage;

// 將token值set到postman中，方便后續引用
pm.environment.set("myToken",myToken)

來個場景， 還是登陸后進行后續操作，只是需要攜帶token了。

登錄/查詢余額接口相關參數：

# 登錄
url：http://www.neeo.cc:6002/pinter/bank/api/login2
類型：POST
參數：userName=admin&password=1234

# 查詢余額
url：http://www.neeo.cc:6002/pinter/bank/api/query2
類型：GET
參數：userName=admin

第一種方式，仍然為自己在瀏覽器（建議是用火狐瀏覽器抓包，谷歌貌似抓不到）登錄，然后抓包，抓到token值。

然后在查詢余額中攜帶。

現在就OK了。

第二種，就是使用postman的數據關聯的功能了。

首先，我們配置登錄接口，然后從響應的json中提取token，然后將token保存到postman的環境變量中。那在哪寫提取token的代碼呢？還記得Tests嗎？它是響應后要干的事情，之前我們用它來做斷言。現在用它來提取token值。

我們也可以去環境變量中查看剛剛添加的token值。

然后在后續的查詢余額中，引用環境變量中的token值，只要這個token值不過期，我們查詢余額就能一直用，過期了，再訪問一下登錄接口就行了。

ok，完事了。

webservice接口

還有一種接口就是webservice類型的接口。

簡單來說，webservice是通過xml進行交互的web請求。

Web Service也叫XML Web Service WebService是一種可以接收從Internet或者Intranet上的其它系統中傳遞過來的請求，輕量級的獨立的通訊技術。是通過SOAP在Web上提供的軟件服務，使用WSDL文件進行說明，並通過UDDI進行注冊。

XML：(Extensible Markup Language)擴展型可標記語言。面向短期的臨時數據處理、面向萬維網絡，是Soap的基礎。

Soap：(Simple Object Access Protocol)簡單對象存取協議。是XML Web Service 的通信協議。當用戶通過UDDI找到你的WSDL描述文檔后，他通過可以SOAP調用你建立的Web服務中的一個或多個操作。SOAP是XML文檔形式的調用方法的規范，它可以支持不同的底層接口，像HTTP(S)或者SMTP。

WSDL：(Web Services Description Language) WSDL 文件是一個 XML 文檔，用於說明一組 SOAP 消息以及如何交換這些消息。大多數情況下由軟件自動生成和使用。

UDDI (Universal Description, Discovery, and Integration) 是一個主要針對Web服務供應商和使用者的新項目。在用戶能夠調用Web服務之前，必須確定這個服務內包含哪些商務方法，找到被調用的接口定義，還要在服務端來編制軟件，UDDI是一種根據描述文檔來引導系統查找相應服務的機制。UDDI利用SOAP消息機制（標准的XML/HTTP）來發布，編輯，瀏覽以及查找注冊信息。它采用XML格式來封裝各種不同類型的數據，並且發送到注冊中心或者由注冊中心來返回需要的數據。

可以通過soupui來測試，也可以通過jmeter來測試。

常用webservice接口網站：

http://wcf.open.cnblogs.com/news/help/operations/GetNewsList#response-xml

http://www.webxml.com.cn/zh_cn/index.aspx # 這個網站提供了很多webservice接口

url和相關參數：

# http://fy.webxml.com.cn/webservices/EnglishChinese.asmx
# post類型

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <TranslatorSentenceString xmlns="http://WebXml.com.cn/">
      <wordKey>string</wordKey>
    </TranslatorSentenceString>
  </soap:Body>
</soap:Envelope>

在Body中選擇raw，類型選擇XML，參數中，需要將string替換為實際的單詞。

現在，點擊Send發送請求。

遇到了問題，響應狀態碼是415，不支持的媒體類型，這是怎么回事？原因是，當我們選擇類型為XML時，postman會自動的在headers中添加Content-Type:application/xml。

原因就是出在Content-Type這里，類型自動添加的不對，那到底是什么呢？我們看人家網站的說明：

是Content-Type: text/xml，我們在postman中手動修改，然后再發送請求即可。

現在，這個接口就通過了。

---

歡迎斧正，that's all