接口測試
一、常見接口：
1、WebService接口：是走soap協議通過http傳輸，請求報文和返回報文都是xml格式的，我們在測試的時候都用通過工具才能進行調用，測試。可以使用的工具有SoapUI、JMeter、Loadrunner等;
2、http api接口：是走http協議，通過路徑來區分調用的方法，請求報文都是key-value形式的，返回報文一般都是json串，有get和post等方法，這也是最常用的兩種請求方式。可以使用的工具有Postman、RESTClient、JMeter、Loadrunner等;
二、接口組成
接口都有那些部分組成呢?
首先，接口文檔應該包含以下內容：
1、接口說明
2、調用url
3、請求方法(get\post)
4、請求參數、參數類型、請求參數說明
5、返回參數說明
接口文檔可知，接口至少應有請求地址、請求方法、請求參數(入參和出參)組成，部分接口有請求頭header。
標頭 (header)：是服務器以HTTP協議傳HTML資料到瀏覽器前所送出的字串，在標頭與 HTML 文件之間尚需空一行分隔，一般存放cookie、token等信息
有人問我header和入參有什麼關係?它們不都是發送到服務器的參數嗎?
首先，它們確實都是發送到服務器裡的參數，但它們是有區別的，header裡存放的參數一般存放的是一些校驗信息，比如cookie，它是為了校驗這個請求是否有權限請求服務器，如果有，它才能請求服務器，然後把請求地址連同入參一起發送到服務器，然後服務器會根據地址和入參來返回出參。也就是說，服務器是先接受header信息進行判斷該請求是否有權限請求，判斷有權限後，才會接受請求地址和入參的。
三、為什麼要做接口測試？
大家都知道，接口其實就是前端頁面或APP等調用與後端做交互用的，所以好多人都會問，我功能測試都測好了，為什麼還要測接口呢?
OK，在回答這個問題之前，先舉個例子：
比如測試用戶註冊功能，規定用戶名為6~18個字符，包含字母(區分大小寫)、數字、下劃線。首先功能測試時肯定會對用戶名規則進行測試時，比如輸入20個字符、輸入特殊字符等，但這些可能只是在前端做了校驗，後端可能沒做校驗，如果有人通過抓包繞過前端校驗直接發送到後端怎麼辦呢?試想一下，如果用戶名和密碼未在後端做校驗，而有人又繞過前端校驗的話，那用戶名和密碼不就可以隨便輸了嗎?如果是登錄可能會通過SQL注入等手段來隨意登錄，甚至可以獲取管理員權限，那這樣不是很恐怖?
所以，接口測試的必要性就體現出來了：
①、可以發現很多在頁面上操作發現不了的bug
②、檢查系統的異常處理能力
③、檢查系統的安全性、穩定性
④、前端隨便變，接口測好了，後端不用變
四、那麼接口測試怎麼測？
在進行接口測試前，還需要了解：
1)、GET和POST請求：
如果是get請求的話，直接在瀏覽器裡輸入就行了，只要在瀏覽器裡面直接能請求到的，都是get請求，如果是post的請求的話，就不行了，就得藉助工具來發送。
GET請求和POST請求的區別：
1、GET使用URL或Cookie傳參。而POST將數據放在BODY中。
2、GET的URL會有長度上的限制，則POST的數據則可以非常大。
3、POST比GET安全，因為數據在地址欄上不可見。
4、一般get請求用來獲取數據，Post請求用來發送數據。
2)、http狀態碼
每發出一個http請求之後，都會有一個響應，http本身會有一個狀態碼，來標示這個請求是否成功，常見的狀態碼有以下幾種：
1、200 2開頭的都表示這個請求發送成功，最常見的就是200，就代表這個請求是ok的，服務器也返回了。
2、300 3開頭的代表重定向，最常見的是302，把這個請求重定向到別的地方了，
3、400 400代表客戶端發送的請求有語法錯誤，401代表訪問的頁面沒有授權，403表示沒有權限訪問這個頁面，404代表沒有這個頁面
4、500 5開頭的代表服務器有異常，500代表服務器內部異常，504代表服務器端超時，沒返回結果
現在來說一下接口測試到底怎麼測：
1)、通用接口用例設計
①、通過性驗證：首先肯定要保證這個接口功能是好使的，也就是正常的通過性測試，按照接口文檔上的參數，正常傳入，是否可以返回正確的結果。
②、參數組合：現在有一個操作商品的接口，有個字段type，傳1的時候代表修改商品，商品id、商品名稱、價格有一個是必傳的，type傳2的時候是刪除商品，商品id是必傳的，這樣就要測參數組合了，type傳1的時候，只傳商品名稱能不能修改成功，id、名稱、價格都傳的時候能不能修改成功。
③、接口安全：
1、繞過驗證，比如說購買了一個商品，它的價格是300元，那我在提交訂單時候，我把這個商品的價格改成3元，後端有沒有做驗證，更狠點，我把錢改成-3，是不是我的餘額還要增加?
2、繞過身份授權，比如說修改商品信息接口，那必須得是賣家才能修改，那我傳一個普通用戶，能不能修改成功，我傳一個其他的賣家能不能修改成功
3、參數是否加密，比如說我登陸的接口，用戶名和密碼是不是加密，如果不加密的話，別人攔截到你的請求，就能獲取到你的信息了，加密規則是否容易破解。
4、密碼安全規則，密碼的複雜程度校驗
④、異常驗證：
所謂異常驗證，也就是我不按照你接口文檔上的要求輸入參數，來驗證接口對異常情況的校驗。比如說必填的參數不填，輸入整數類型的，傳入字符串類型，長度是10的 寫11。總之就是你說怎麼來，我就不怎麼來，其實也就這三種，必傳非必傳、參數類型、入參長度。
2)、根據業務邏輯來設計用例
根據業務邏輯來設計的話，就是根據自己系統的業務來設計用例，這個每個公司的業務不一樣，就得具體的看自己公司的業務了，其實這也和功能測試設計用例是 一樣的。
舉個例子，拿bbs來說，bbs的需求是這樣的：
1、登錄失敗5次，就需要等待15分鐘之後再登錄
2、新註冊的用戶需要過了實習期才能發帖
3、刪除帖子扣除積分
4、......
像這樣的你就要把這些測試點列出來，然後再去造數據測試對應的測試點。
五、用什麼工具測
接口測試的工具很多，比如 Postman、RESTClient、JMeter、Loadrunner、SoapUI等，本人首推的測試工具是Postman和JMeter
閱讀更多 川石信息 的文章
