轉自:https://www.cnblogs.com/jiadan/articles/8546015.html

一、 接口

接口：什麽是接口呢？接口一般來說有兩種，一種是程序內部的接口，一種是系統對外的接口。

系統對外的接口：比如你要從別的網站或服務器上獲取資源或信息，別人肯定不會把數據庫共享給你，他只能給你提供一個他們寫好的方法來獲取數據，你引用他提供的接口就能使用他寫好的方法，從而達到數據共享的目的，比如說咱們用的app、網址這些它在進行數據處理的時候都是通過接口來進行調用的。

程序內部的接口：方法與方法之間，模塊與模塊之間的交互，程序內部拋出的接口，比如bbs系統，有登錄模塊、發帖模塊等等，那你要發帖就必須先登錄，要發帖就得登錄，那麽這兩個模塊就得有交互，它就會拋出一個接口，供內部系統進行調用。

二、 接口的分類

現在我們最常用的兩種接口就是webservice接口和http api接口。

webService接口是走soap協議通過http傳輸，請求報文和返回報文都是xml格式的，我們在測試的時候都用通過工具才能進行調用、測試。

http api接口是走http協議，通過路徑來區分調用的方法，請求報文都是key-value形式的，返回報文一般都是json串，有get和post等方法，這也是最常用的兩種請求方式。

三、前端和後端

前端 後端 前端語言 html css js

客戶端 服務端、server端 後端語言 java php python

接口返回的數據都是json

通用的數據類型：json

前端是什麽呢，對於web端來說，咱們使用的網頁，打開的網站，這都是前端，這些都是html、css寫的；對於app端來說呢，它就是咱們用的app，android或者object-C（開發ios上的app）開發的，它的作用就是顯示頁面，讓我們看到漂亮的頁面，以及做一些簡單的校驗，比如說非空校驗，咱們在頁面上操作的時候，這些業務邏輯、功能，比如說你購物，發微博這些功能是由後端來實現的，後端去控制你購物的時候扣你的余額，發微博發到哪個賬號下面，那前端和後端是怎麽交互的呢，就是通過接口。

四、接口測試

接口測試是測試系統組件間接口的一種測試。接口測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等。

五、為什麽要做接口測試

假如現在在京東app上買東西，支付訂單，訂單金額是500元，支付的話，那肯定要調用支付接口，你在頁面上操作的話，訂單金額是修改不了的，那如果你想測試一下服務端有沒有校驗訂單的金額，我想把訂單金額改成5元，那在頁面上點是測試不了的，這個時候我們就可以直接用接口來調用，修改一下訂單金額的值，然後再發請求就可以了。

是為了更好的提高我們產品的質量。

小結：

1. 接口一般來說有兩種，一種是程序內部的接口，一種是系統對外的接口。
2. 咱們測的都是程序對外部的接口。
3. 接口其實就是各種操作數據庫。

六、接口測試的必要性

• 可以發現很多在頁面上操作發現不了的bug
• 檢查系統的異常處理能力
• 檢查系統的安全性、穩定性
• 前端隨便變，接口測好了，後端不用變

七、接口測試流程

• 需求評審，熟悉業務和需求
• 開發提供接口文檔
• 編寫接口測試用例
• 用例評審
• 提測後開始測試
• 提交測試報告

八、接口規範文檔

接口文檔至少包括：

• 接口說明
• 調用url
• 請求方法（get\post）
• 請求參數、參數類型、請求參數說明
• 返回參數說明

測接口的話，必須得有接口文檔：

1、url

2、請求方式 post、get

3、入參（請求參數）

4、返回參數

5、請求、返回示例

6、 狀態碼說明

Referer 判斷請求是從哪跳轉過來的，可以通過它來判斷是否合法

如果是get請求，直接用瀏覽器就能發，不需要借助工具。

例如：get 請求

http://XXXXXXXX/api/user/stu_info?stu_name=小黑&id=1

• 接口測試可以發現一些頁面上操作發現不了的bug。
• 越早發現bug，解決bug的成本是越低的。

post 和 get請求的區別

http請求

請求頭

請求體

get請求他沒有請求體，只有請求頭

get請求的參數只能寫在url裏面

或者cookie裏面

post

請求頭

請求體

請參數放在請求體裏面

九、GET請求和POST請求的區別：

GET和POST請求：

• 如果是get請求的話，直接在瀏覽器裏輸入就行了，只要在瀏覽器裏面直接能請求到的，都是get請求，如果是post的請求的話，就不行了，就得借助工具來發送。

GET請求和POST請求的區別：

• GET使用URL或Cookie傳參。而POST將數據放在BODY中。
• GET的URL會有長度上的限制，則POST的數據則可以非常大。
• POST比GET安全，因為數據在地址欄上不可見。
• 一般get請求用來獲取數據，post請求用來發送數據。

其實上面這幾點，只有最後一點說的是比較靠譜的，第一點post請求也可以把數據放到url裏面，get請求其實也沒長度限制，post請求看起來參數是隱式的，稍微安全那麽一些些，但是那只是對於小白用戶來說的，就算post請求，你通過抓包也是可以抓到參數的。所以上面這些面試的時候你說出來就行了。

十、Http狀態碼

每發出一個http請求之後，都會有一個響應，http本身會有一個狀態碼，來標示這個請求是否成功，常見的狀態碼有以下幾種：

1、200 2開頭的都表示這個請求發送成功，最常見的就是200，就代表這個請求是ok的，服務器也返回了。

2、300 3開頭的代表重定向，最常見的是302，把這個請求重定向到別的地方了，

3、400 400代表客戶端發送的請求有語法錯誤，401代表訪問的頁面沒有授權，403表示沒有權限訪問這個頁面，404代表沒有這個頁面

4、500 5開頭的代表服務器有異常，500代表服務器內部異常，504代表服務器端超時，沒返回結果

十一、通用接口用例設計

通過性驗證：首先肯定要保證這個接口功能是好使的，也就是正常的通過性測試，按照接口文檔上的參數，正常傳入，是否可以返回正確的結果。

參數組合：現在有一個操作商品的接口，有個字段type，傳1的時候代表修改商品，商品id、商品名稱、價格有一個是必傳的，type傳2的時候是刪除商品，商品id是必傳的，這樣的，就要測參數組合了，type傳1的時候，只傳商品名稱能不能修改成功，id、名稱、價格都傳的時候能不能修改成功。

接口安全：

1. 繞過驗證，比如說購買了一個商品，它的價格是300元，那我在提交訂單時候，我把這個商品的價格改成3元，後端有沒有做驗證，更狠點，我把錢改成-3，是不是我的余額還要增加？
2. 繞過身份授權，比如說修改商品信息接口，那必須得是賣家才能修改，那我傳一個普通用戶，能不能修改成功，我傳一個其他的賣家能不能修改成功
3. 參數是否加密，比如說我登陸的接口，用戶名和密碼是不是加密，如果不加密的話，別人攔截到你的請求，就能獲取到你的信息了，加密規則是否容易破解。
4. 密碼安全規則，密碼的復雜程度校驗

異常驗證：

• 異常的，也就是我不按照你接口文檔上的要求輸入參數，來驗證接口對異常情況的校驗。比如說必填的參數不填，輸入整數類型的，傳入字符串類型，長度是10的，傳11，總之就是你說怎麽來，我就不怎麽來，其實也就這三種，必傳非必傳、參數類型、入參長度。

根據業務邏輯來設計的話，就是根據自己系統的業務來設計用例，這個每個公司的業務不一樣，就得具體的看自己公司的業務了，其實這也和功能測試設計用例是一樣的。

• 舉個例子，拿bbs來說，bbs的需求是這樣的：
• 登錄失敗5次，就需要等待15分鐘之後再登錄
• 新註冊的用戶需要過了實習期才能發帖
• 刪除帖子扣除積分
• 4、......
• 像這樣的你就要把這些測試點列出來，然後再去造數據測試對應的測試點。

登錄

本地寫了一個

cookie

niuhanyang sdfjsdkf342342

服務端

session

niuhanyang sdfjsdkf342342

cookie

存在你本地的一個鍵值對。

niuhanyang sdfjsdkf342342

session

存在服務端的一個鍵值對。

niuhanyang sdfjsdkf342342

接口簽名

為了防止別人惡意刷請求。

它一個加密之後的字符串。

http://XXXXX/reg?username=xxx&passwd=xxx&sign=8eea855efc702130d9c9cafcd9f4d91a

用POSTMAN上傳文件

接口測試-Http狀態碼-postman上傳文件