陸續在幾個公司都有接觸過介面測試，每個公司的介面測試需求都差不多。但是，專案的大小會影響介面測試任務的簡繁。
涉及到TCP協議的介面，也涉及到http協議的介面。
前段時間，剛接到一個走HTTP協議的介面測試需求。
開發提供過來的介面如下：
1. get_list
a. url - subject_id / compliance_id
b. ajax - subject_id / compliance_id
2.get_map
a. url -
b. ajax - qry_id / extra_col
3............
由上得出：
1.每個介面有兩種請求方式
a）走位址列url-----GET請求
b）走ajax模式
2.兩種請求方式後端帶有引數的key
3.無其他資訊
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
諮詢開發同個介面為什麼走兩種請求方式？
得到的回覆：
1.url----Get請求獲取靜態資訊，即處理獲取資料後的前端頁面處理
2.ajax----POST請求為處理資料，返回json資料，即使用者需要的資料
請根據這個回覆，確認測試的需求範圍！！！
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
通過以上資訊，測試在開始介面自動化之前，需要將開發提供的介面轉換為測試熟悉的模式。
HTTP協議，正常情況下需要包括頭部資訊，地址，引數等。而開發提供的資訊並沒有這麼豐富。
所以，測試要自己進行抓包獲取剩餘未知的資訊！！！
以百度新聞為範例，谷歌瀏覽器做為抓包工具
1.進入百度新聞網址：http://news.baidu.com/
2.右鍵點選網頁->【檢查】（如果您的網站右鍵被禁止，請使用F12開啟開發者模式）
3.請在開啟工具選單欄選擇network
4.重新整理網頁，觀察工具變化（請選擇XHR，我們僅觀察html頁面，js/css等不需要）
5.點選，出現的Name，即開發提供中的模組--test如下：
a)General顯示內有我們需要的資訊：URL地址，請求模式（GET）等
b)response headers為我們傳送請求過去，伺服器返回響應的頭部資訊
c)request headers內有我們需要的資訊，當你不知道哪些是介面特殊需要的，請完整保留該區域的所有資訊
d)query string parameter為傳送請求需要帶的引數
6.通過第5點，將介面整理成測試比較熟悉的格式
get_list介面 | |||||||||||||
| 介面功能：xxxx | |||||||||||||
請求url | http://IP:PORT/test/get_list | ||||||||||||
請求模式 | POST | ||||||||||||
請求頭 |
| ||||||||||||
引數 | subject_id：11 compliance_id：11 | ||||||||||||
響應(json) | {data:[{}]} | ||||||||||||
備註 | 描述該介面依賴的其他介面名稱，該介面的特殊點 |
備註
如果是移動端的web獲取app，請使用第三方工具進行抓包如flddler
如果知道產品的開發語言，並且可以看懂程式碼的話，請根據介面名稱檢視原始碼，確定引數是否必填/返回的錯誤響應等等資訊
開始介面測試之前，請考慮清楚介面測試的範圍（功能？冒煙迴歸？壓測？），這將影響工具的選擇及介面覆蓋率的指令碼編寫
感興趣的小夥伴可以加群：747981058，大家一起來交流~