http接口測試相關介紹
常見的幾種測試模式
功能測試：
編寫測試用例（測試用例當中最主要的是測試步驟和預期結果）—-》測試人員根據測試用例執行操作步驟—–》然後通過眼睛和思考判斷實際結果與預期結果是否相等（如果相等，測試通過；如果不相等，測試失敗）
自動化測試：
自動化測試要做的事情與功能測試是一致。這裏的自動化主要包含三個層面的自動化，單元測試自動化，接口測試自動化和web測試自動化。當然，不同層面的自動化關注點是不一樣的
單元測試自動化：
調用被測試的類或方法，根據類或方法的參數，傳入相應的數據。然後，得到一個返回結果。最終斷言返回的結果是否等於預期結果。如果相等，測試通過；如果不相等，測試失敗。所以，這裏單元測試關注的是代碼的實現與邏輯。
接口測試自動化：
根據接口文檔，到底是傳get請求呢？還是post請呢？調用被測試的接口，構造相應的數據（id=1,name=zhangsan），得到返回值，是200成功，並返回查詢結果。還是10021，用戶名不能爲空。不管輸入的參數是怎樣的，我們都將得到一個結果。最終斷言返回的結果是否等於預期結果。如果相等，測試通過；如果不相等，測試失敗。所以，接口測試關注的是數據。只要數據正確了，功能就做成大半，剩下的無非是如何把這些數據展示在頁面上。
web測試的自動化（UI自動化）：
這種測試更貼近用戶的行爲，模擬用戶點擊了某個按鈕，向個輸入框裏輸入了什麼。但是用戶可以看到登錄成功了，但web自動化並不知道它剛纔的點擊有沒有生效。所以，要找“證據”，比如，登錄成功後頁面右上角會顯示“歡迎，xxx”。這就是登錄成功的有力“證據”。於是，當web自動化登錄成功後，就去獲取這個數據進行斷言。斷言如果相等，測試通過；如果不相等，測試失敗。所以，web自動化的關注點用戶操作形爲，頁面上真正的按鈕和輸入框是否可用。
各種測試的區別：
本質上沒啥區別，唯一的區別是，一個由人來執行，一個由代碼或工具執行
什麼是接口測試？爲什麼要做接口測試？（注意接口測試的重點是接口交互數據的準確性，不是測試功能）
接口測試是測試系統組件間接口的一種測試。接口測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關係等。
接口測試適用於爲其他系統提供服務的底層框架系統和中心服務系統，主要測試這些系統對外部提供的接口，驗證其正確性和穩定性。接口測試同樣適用於一個上層系統中的服務層接口，越往上層，其測試的難度越大。
接口測試實施在多系統多平臺的構架下，有着極爲高效的成本收益比，接口測試天生爲高複雜性的平臺帶來高效的缺陷監測和質量監督能力。平臺越複雜，系統越龐大，接口測試的效果越明顯。
基於接口測試的重要性，以及它比較容易自動化的特性，通過持續集成的接口監控能夠及時的發現項目中存在的問題，這對持續運營的項目來說，非常重要
接口測試的流程
1、項目啓動後，測試人員要儘早找到開發人員拿到接口測試文檔
2、獲取接口測試文檔後，就可以進行接口用例的編寫和調試
3、接口用例編寫調試完成後，部署到持續集成的測試環境中，
4、設定腳本運行頻率，告警方式等基本參數，進行接口的日常監控
5、每日進行接口腳本的維護更新，接口異常的處理
接口測試的用例設計
假設我要驗證發表朋友圈的 接口，它的工作流程如下：
- 上傳圖片，服務器返回這些圖片的 url
- 發表朋友圈，包含朋友圈文字內容和各個圖片 url 兩個主要字段。服務器只會返回是否成功以及這條朋友圈的 id
我設計的正常發朋友圈的用例如下：
- 用上傳圖片接口上傳圖片，驗證圖片是否上傳成功，各 url 對應文件的 md5 是否和我本地上傳的圖片的 md5 吻合。
- 用發本地圈接口發本地圈，其中圖片 url 來自第一步的返回值
- 用查看本地圈接口查看發出的本地圈，檢查它的內容、圖片是否正確.
咋看之下好像沒啥問題（相信做過 api 測試的童鞋已經看出問題了），但其實這個用例本身存在一個嚴重的問題： 接口成爲了手段，驗證點其實是功能。
我交流後得到的 api 測試用例主要應該有兩類：
1.單一接口測試。調用一個接口就是一個用例
2.多接口的業務測試。會調用多個接口，且接口之間可能存在數據傳遞。api 測試最簡單，並且每個接口都應該至少有一個的用例應該就是使用 默認參數調用 單個接口。重點在這裏：單個。像我上面這樣的用例已經不是驗證發朋友圈的接口了，而是驗證 發朋友圈的功能。
那麼發朋友圈的接口應該有什麼用例呢？我按照現在的測試接口的思路重新想了一下，主要有這幾個：
1.有圖片、有文字，預期返回發佈成功
2.無圖片，有文字，預期返回發佈成功
3.有圖片，無文字，預期返回發佈成功
4.無圖片，無文字，預期返回發佈失敗
5.有圖片、有文子，預期返回發佈成功，同時數據庫中的記錄符合預期
每一個用例測試一個點，發佈成功這個返回值是否正確由一個單獨的用例來覆蓋就足夠了。
開源框架那麼多，爲什麼還要自己碼代碼造輪子
好處：
1）可解決一些不常用的body格式數據的解析
2）對於多接口關聯的處理比使用工具更方便
3）可方便的使用第三方庫，如數據加密處理等
4）維護起來更方便，但初期用例編寫時間相對較長
5）將代碼稍作修改即可用於穩定性、性能測試及測試環境準備
