（1）什么是介面測驗
介面測驗是測驗系統組件間介面的一種測驗，
介面測驗主要用于檢測系統內部各個子系統之間、外部系統與系統之間的互動，
測驗的重點是檢查資料交換，傳遞和控制管理的程序，以及系統間相互邏輯依賴關系等，
通俗來說介面測驗就是介面提供方、介面呼叫方之間的互動，及邏輯處理的測驗，
資料交換：注冊
資料傳遞：將注冊資料傳遞到服務器，呼叫程式，執行資料庫sql陳述句，往資料表中插入資料
控制管理：在程式中設定欄位的長度
系統間相互邏輯依賴關系：注冊成功之后呼叫登錄進行登錄；共享充電寶是否收取押金依賴芝麻信用分
介面：
1. GUI：圖形用戶界面，并不是介面測驗的重點，
2. API：應用程式介面，介面測驗的主要物件，API專門用來提供給其他系統進行呼叫的程式介面，
Browser/Server、Client/Server架構必然需要前端和服務器進行互動，介面就是它們互動的樞紐，
其本質就是前臺發送一個request（請求）報文給服務器，然后服務器回應回傳一個response（回應）報文，我們對response報文進行分析，判斷是否和我們的預期一致，從而檢驗業務是否正確實作，
通過輸入看輸出
模擬實際場景（服務架構（Java、Python、php）、資料場景（CRUD）、業務場景），對介面進行模擬呼叫，驗證其回應性能、輸出結果、例外處理等測驗點，
HTTP介面測驗知識點：
考試系統網址：http://182.92.178.83:8088/student/index.html#/login
Request URL(請求地址)
URL形式: http[s]://host[:port][abs_path][parameter]
比如: http://182.92.178.83:8088/api/student/user/register
Request Headers(請求頭):頭資訊，包含了報文的描述資訊
Accept(接收形式): application/json, text/plain, */*
Content-Type(提交形式): application/json
Cookie: JSESSIONID=C68ED1A8DA1A3B2CDACC5612F158467D
# Content-Type的幾種形式:
- form-data
- application/x-www-form-urlencoded
- application/json
比如：{"username":"ctt","password":"123456",age:21,"a":[{"b":123},{"c":456}]}
Request Method(提交方法): GET/POST DELETE/PUT
GET: 獲取服務器資訊的一些操作，一般用于獲取資料
比如：
Request URL: http://182.92.178.83:8081/article/all?state=-1&page=1&count=6&keywords=
Request Method: GET
PS：直接在url后面連接引數，url有長度限制，
POST: 一些提交等操作，一般用于提交資料，注冊、上傳檔案，
DELETE: 一般用于洗掉操作（物理洗掉）
比如：
Request URL: http://182.92.178.83:8081/admin/category/56
Request Method: DELETE
PUT: 跟post功能一致，但是有一個對等加密的程序，比如兩人同時提交就會對比誰先提交，執行先提交的那個操作，后提交的不做處理，比如邏輯洗掉，（邏輯洗掉：比如將state=0）
比如：
Request URL: http://182.92.178.83:8081/article/dustbin
Request Method: PUT
這四種形式無論用哪一種都能實作對資料庫的增刪改查，那么為什么會分四種呢，它更像是一種約定，
（面試題）get和post的區別?
- 傳參方式不同，get是通過url？后面去傳參的，post是在請求體里面傳參，
- 有些約定里面，get更多的是做獲取資訊的操作，post更多的是做提交資訊的一些操作，
Request Parameters(請求引數)
Status Code(回應狀態碼)
200(服務器回應成功)
404(找不到路徑)
500(服務器內部錯誤)
Response(回應資訊)
（2）為什么要進行介面測驗
介面測驗相對于UI來說，更加穩定；
也可以說介面測驗是一種特殊的單元測驗；
當一個系統提供了大量的后臺服務，有較少或者基本沒有頁面操作，比較適合開展介面測驗；例如：某個系統大概有100多個對外的介面，每次上線，測驗人員不得不一個一個驗證，此時如果開展自動化，將大大提高回歸的效率和測驗的覆寫率，
為什么介面比UI更加穩定：如果介面回應資訊都變了，UI也需要變，
??前后端分離，一個介面給多個端使用（web端、app端）
??什么時候做介面測驗？
- 有大量用戶的時候，前端頁面限制了但是沒有限制完，
（3）怎樣做介面測驗
- 方式一：先拿到介面測驗規范檔案，再去做介面測驗，
- 方式二：抓包（瀏覽器F12、Charles、fiddler），
1.介面測驗在作業中的流程
-
準備階段（20%）
拿到開發的介面檔案，并理解每個介面的引數及含義；
了解被測系統的業務流程，
-
撰寫介面測驗用例、執行階段（70%）
測驗用例/測驗場景執行
測驗資料/系統資料收集
-
分析階段（5%）
資料匯總/日志分析
測驗報告
2.介面測驗規范檔案
介面功能
URL
支持格式
HTTP請求方式
請求引數
??為提高介面測驗效率，及TDD（測驗驅動開發）模式，前期我們需要推動開發規范，介面說明檔案，
3.如何獲取介面（Charles、fiddler）
抓包工具Charles、fiddler，web端瀏覽器的F12，
（4）介面測驗用例的設計
介面測驗用例撰寫要點：
- 測驗每個引數型別不合法的情況，
- 測驗每個引數取值范圍不合法的情況，
- 測驗引數為空的情況，
- 測驗引數前后臺定義的一致性，
- 測驗每個引數的上下限（這里容易出致命的BUG，如果程式員處理不當，可能導致崩潰），
- 測驗每個引數取值不合理的情況（包括取的值不屬于自己，取值在這階段不會出現，取值超出了自己所謂的數量或者范圍），
- 如果兩個請求有嚴格的先后順序，需要測驗調轉順序的情況，
（5）介面測驗的流程規范（團隊中）
- 與產品、開發一起梳理需求，確定實作哪些介面和功能，
- 撰寫測驗計劃（開發人員預估時間、風險預估及解決時間，測驗人員用例準備、資料準備、環境準備、與開發產品協調測驗時間等）
- 測驗計劃review，請各部門再進行溝通，確定最終計劃，
- 撰寫用例及自動化腳本，
- 用例review（以該用例為最終驗證的用例），
- 執行測驗，提交bug，驗證bug，
- 測驗總結（包括測驗程序、開發程序遇到的問題、解決問題、小組內討論以后遇到這種問題如何可以處理更快、對自己啟發）
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/242237.html
標籤：其他