接口測試

接口測試：接口是聯繫前端和後端的橋樑，負責數據的傳輸，或者移動端和服務端的橋樑。
1. 接口分類：a.get， b.post， c.delete， d.put
2. 接口測試工具三劍客：Fildder， postman，python自己開發
3. get和post請求的區別：
a.get以“？”爲分隔，有參數數據；post直接顯示的接口，post請求的數據是放在WebForm裏面，以表單形式提交的
b.將數據放在地址欄中（get請求），提交數據小一些；WebForm以表單的形式請求數據多；
c.以表單的形式請求數據較爲安全

爲什麼要做接口測試?
不同端的工作進度不一-樣
需要對最開始出來的接口進行接口測試

1、節約時間,縮短項目時間
2、提高工作效率
3、提高系統的健壯性

示例：
postman中
在最上面的地址信息欄輸入地址點擊發送：
下面是服務器端返回的信息，選爲json格式：

如果將發送的請求中loginname去掉，那麼就會報錯了
客戶操作，然後系統會不斷地調用接口，比如銀行，支付寶

接口的分類

接口測試流程

爲什麼要設計測試用例
理清思路,避免漏測
提高測試效率
跟進測試進度
告訴領導做過

對於接口的用例設計

1.功能
2.邏輯業務
3.異常
4.安全

用例設計–功能用例設計
1.看功能是否都能實現
（比如在postman中，輸入連接，如果返回的數據，數據結構是正確的，那麼認爲功能是正確的）
2.功能是否按照接口文檔實現
例1：比如博客園添加隨筆，需要登錄才能添加。也就是業務要求不支持遊客添加隨筆功能，如果設計一個沒有登錄的用戶，然後去測試添加隨筆接口，結果接口能添加到隨筆，說明功能不正常，不符合需求和接口文檔描述。
例2：接口文檔裏描述了登錄，而且他有兩個參數，一個是用戶名，一個是密碼：

雖然功能實現了，但是寫的時候把loginname寫成了user，雖然功能實現了，但是這樣是不合理的，因爲開發的接口文檔是給所有的開發用的，其他人都用的login，他自己用了user，最後肯定是會出問題的呀

用例設計–邏輯用例設計
是否依賴業務
比如你要下單，那你是不是應該先登陸成功呢？登陸之前需要短信驗證

用例設計–異常測試用例設計
參數異常
1.關鍵字參數（開發語言裏的關鍵字，html，mysql，php等）
比如把以下的登錄名和密碼改成關鍵字

返回提示賬戶名不能爲空，說明是沒問題的
2.參數爲空
將以下本來是loginname的變爲空，返回提示賬戶名不能爲空，說明是沒問題的
3.多、少參數、
No1.多參數：多寫一個email郵件

竟然返回成功了？？那是不是應該給開發反饋呢？因爲這是接口測試呀，這是不合理的

No2.少參數：把下圖框起來的給刪掉，

返回賬戶名不能爲空，說明沒問題

4.錯誤參數
把以下的loginname，password如果改成username，pdd會是什麼反應呢？

用戶名改了：

密碼改了：

數據異常

1.關鍵字數據關鍵字
把loginname對應的內容改成NULL，提示用戶不存在，說明他把null轉義成了一個用戶

2.數據爲空

3.長度不一致
數據庫建表的時候對每個字段有長度限制，所以在請求驗證的時候，應當驗證輸入的內容是否超長
比如將loginname=123123123123234354666…非常長，卻只提示了用戶不存在，那麼是不是就不大合理呢？特別是對銀行這種，這種情況是不允許存在的

4.錯誤數據
輸入錯誤的賬號信息，當然就

總結：
不管數據異常還是參數異常，測試點差不多，一個參數有key和value，key表示參數，value表示數據。第一，看看參數和數據能不能支持關鍵字，例如Java中的保留關鍵字等等。第二個就是參數和數據都爲空，看看是否做了判斷。第三個，參數多和少，例如有兩個參數的接口，你需要設計一個三個參數的用例，一個只有一個參數的用例。數據那邊長度不一致，例如設計很長的字符串是否支持，因爲數據庫創建表過程都設置好了每個字段的長度。輸入錯誤的參數和數據，例如故意輸出單詞等等。

用例設計–安全接口測試用例設計

1)cookie：有cookie才能獲取數據，如果不帶cookie還有信息返回，說明有問題
2)header：正常接口帶header信息，刪除header看是否能夠返回數據。
3)唯一識別碼：app手機識別碼，一般是唯一的。
安全測試主要從上面三點檢查。第三個是唯一識別碼，主要是指app上手機的識別碼，一般很少用到，除非很嚴格的接口測試，例如銀行app登錄，需要指紋，而指紋來源手機，一般有一個手機識別碼判斷過程。

1、cookie；
下單或者一些邏輯依賴業務用，比如說如果用戶都沒登錄，就可以下單，那是不是不應該成功，如果成功的話，是不是就應該報錯。
例子：
有header值，有cookie信息

是會把從服務器端獲取的一些信息返回給我們

如果把這個header信息的cookie刪掉，服務器端卻沒有驗證，而是仍然返回了信息，說明這個接口是不合格的。