本節大綱
- 接口測試概述
- 通信協議原理解析
- HTTP與HTTPS協議講解
- HTTP之cookie、session、token解析
01.接口測試概述
接口測試定義
接口 是前后端溝通的橋梁，是數據傳輸的通道，包括外部接口、內部接口。內部接口又包括：上層服務與下層服務接口，同級接口
生活中常見接口：電腦上的鍵盤、 USB 接口，電梯按鈕， KFC 下單
接口測試 ：是對系統或組件之間的接口進行測試，主要校驗數據的交換、傳遞和控制管理 過程，以及相互邏輯依賴關系
接口自動化測試 ：讓程序代替人為對接口項目進行自動化驗證測試的過程
接口測試是一種功能測試：只要管輸入數據后得到的輸出結果是怎么樣的 -- 功能測試
接口測試也是一種自動化測試：從接口測試的執行方式來說，接口必須要借助工具來實現
性能測試： jmeter--> 接口 --> 對接口進行壓測 -- 》接口性能測試
接口測試意義
接口測試使 ” 測試更早投入 ” 這句話變成現實
接口測試可以測試一些界面測試非常難以實現或無法測試的范圍
從對項目的影響，接口測試直接測試后端服務，更加接近服務器上運行代碼，也更能發 現影響范圍廣泛的bug
接口測試更容易和自動化測試系統相結合
總結：熟練接口測試，能夠獨立搭建接口測試框架是測試工程師能力分水嶺的體現
接口測試的實現
實現方式：
1. 使用接口測試 工具 來實現，比如 jmeter,postman
2. 通過編寫代碼來實現，比如 python+requests
兩者比較
1. 接口工具：更容易上手；測試數據不好控制；不方便測試加密接口；擴展能力不足
2. 代碼實現：比較難；測試數據容易控制；可以使用加密函數對接口加密；容易擴展
02.通信協議原理解析
接口測試的原理
接口測試是基於 協議 進行測試的，實際上是黑盒測試，基本的測試思路是 通過輸入和輸
出來判斷被測系統或對象的邏輯是否符合用戶需求 。
原理：客戶端發送網絡請求 -- 》 API 網關（阿里雲， apache,IIS,nginx ） -->services
03.HTTP與HTTPS協議講解
HTTP協議
HTTP 協議是 Hyper Text Transfer Protocol （ 超文本傳輸協議 ）的縮寫；
是用於從萬維網（ www ）服務器傳輸超文本到本地瀏覽器的傳送協議
HTTP 是一個基於 TCP/IP 通信協議（建立連接 -3 次會話 - 斷開連接 -4 次會話 ) 來傳遞數據（ HTML 文件、 圖片、查詢結果等）
HTTP特點：
簡單快速、靈活、 無狀態、無連接
無連接：限制每次連接時處理一個請求
無狀態：對於事務處理沒有記憶能力 。缺少狀態意味着如果后續處理需要前面的信息，則必須
要重傳，這樣可能導致每次傳輸的數據量增大。
HTTP工作原理
HTTP 協議工作於客戶端 / 服務端（ C/S ）架構上，比如瀏覽器作為客戶端通過 url 向服務器 （web 服務器）發送所有請求。 web 服務器根據接收到的請求后，想客戶端發送響應信息。
web 服務端有：阿里雲 ,apache,IIS,nginx
HTTP 默認端口為 80 ，也可以自定義修改
HTTP組成
http 消息是服務器和客戶端之間交互數據的方式。有兩種類型的消息：
1. 請求 ：由客戶端發送，用來觸發一個服務器上的動作
請求由三個部分組成： 請求行、請求頭、請求體
2. 響應 ：來自服務器的應答
響應也由三個部分組成： 狀態行、響應頭、響應正文
HTTP請求組成
http 請求（ request ）一般由三部分構成：
1. 請求行（request line ）
2. 請求頭部(request header)
3. 空行
4. 請求體（request body ）
請求行
請求行（ request line ） ：一般指請求包中第一行內容。
通常包含以下信息：
1. 請求方法 （ request method ）：重點（ get/post/head 。。。）
2. 請求路徑 （ request path ）：就是 URL 的 PATH 部分
3. 協議版本 （ protocol/version ）：包括協議和版本號
請求方法
請求方法（ request method ）： http 協議里定義了一些請求的方法，這些方法可以進一 步定義請求的目的，比如是獲取資源還是提交資料還是刪除資源， 常用的是 get ， post
請求頭
請求頭部：緊接着請求行（即第一行）之后的部分，用來說明服務器要使用的附加信息 , 主要是為了去完成通信的控制
請求頭的名稱（類型）都是由 http 協議提前約定好的，具有特定的通信效果的，一般不 能自定義
請求頭含義解釋： https://jingyan.baidu.com/article/375c8e19770f0e25f2a22900.html
請求體
請求體：請求主體。是指第一個空行之后的內容，可以添加任意的數據。 比如說get方法，一般來說 body 就是空的。 post 方法才會產生 body 內容。
注意：請求頭部后面的空行是必須的，即使第四部分的請求數據為空，也必須有空行
post請求參數傳遞方式總結
post 請求的參數是在 body 中傳遞，有多種傳值方式，需要根據頭部參數的 Content-Type 的 值來確定選擇哪種方式傳值。
Content-Type 取值與 body 傳值方式對應關系
HTTP響應組成
HTTP 響應也由四個部分組成 :
1. 狀態行 (response line)
2. 消息報頭/ 響應頭 （ response header ）
3. 空行
4. 響應正文/ 響應報文 （ response body ）
狀態行
狀態行 : 通常就是響應數據包中的第一行 。
由 HTTP 協議 / 版本號， 狀態碼， 狀態消息 三部分組成
狀態碼
狀態代碼（ HTTP Status code ）：由三位數字組成，第一個數字定義了響應的類別，共分
五種類別 :
常見狀態碼
常見狀態代碼：
1. 200-請求成功
2. 301-資源被永久轉移到其他 url
3. 404-請求的資源（網頁）不存在
4. 500-內部服務器錯誤
狀態碼匯總
響應頭
消息報頭：第二行和第三行為消息報頭，用來說明客戶端要使用的一些附加信息。例如 服務器類型，響應報文格式。
1. Date:生成響應的日期和時間
2. Content-Type:指定了內容的數據類型 HTML(text/html) Charset: 編碼類型是 UTF-8
響應頭參數說明
響應正文
響應正文：空行后面的 html 部分為響應正文。表示服務器返回給客戶端的文本信息。
注意：消息報頭后面的空行是必須的，即使第四部分的返回數據為空，也必須有空行
04.HTTP之cookie、session、token解析
HTTP無狀態處理方案
http 協議本身是無狀態的 , 但是在實際的 web 開發中常有一些操作需要有狀態。比如想要 訪問一些私人訪問權限的文章, 或者這種操作需要明確當前用戶身份。
顯然，最簡單的方案就是每次都發送賬戶和密碼，但是這樣重復操作用用戶並不友好， 對服務器頁增添了額外的壓力。為了解決無狀態帶來的鑒權問題, 一般有以下幾種解決方 案:cookie 、 session 、 token
Cookie
Cookie 是儲存在客戶端的一串字符，一般說來大小不超過 4kb 。比如我們常見的記住密碼功能，或者 一些基於之前輸入的提醒和默認配置，就是通過cookie 來實現的。
cookie 簡單說來就是一種 本地存儲方法 。但是這里 存儲的信息常用來進行鑒權操作（狀態信息）
cookie 只能保存文本信息，瀏覽器可以禁止 cookie 。 cookie 的期限可以被自由設定，可以是僅僅一次瀏 覽起效，也可以長達一年。如果是短期的，那么這些信息會被存儲在內存中，如果是長期則會存儲在 硬盤上。
問題：單純的采用 cookie 來 認證身份 會帶來一個比較麻煩的問題，就是 偽造比較容易 。因為這樣處理， cookie中必然要帶有身份信息，但是服務器也要解析這個身份信息，所以必然要在原理上支持雙向的 編碼和解碼，那么這個信息很容易被破解和進一步偽造。
Cookie
Session
如果想要解決上述 cookie 偽造的這個問題 , 我們常用的方案應該是加一個 secret ，而這個 secret 應該是 放在服務器上的，服務器返回這樣一個帶有secret 編碼的字符串，而在服務器端再帶上這個 secret 反 向解密，如此一來，問題不就解決了，這個就是我們要講的第二個對象: session 。
session 是保存在服務器端的，是跟蹤用戶的一種上下文保持的機制 。當服務器創建了一個 session 時， 就給客戶端發送的響應頭中包含了 set-cookie 字段 。瀏覽器會將 set-cookie 的字段信息，將其保存在本 地，並且之后發送的請求報文都包含了 cookie ， cookie 中包含了 set-cookie 返回的字段值。
Session 也可以設定有效時間。
session
Token鑒權
定義：訪問令牌 access token, 用於接口中，用於標識接口調用者的身份、憑證。簡單來說就是不要登 錄。
目的：減少用戶名和密碼的傳輸次數
token類型：
1. API Token(接口令牌 ) ：用於訪問不需要登錄的接口
2. USER Token(用戶令牌 ) ：用於訪問需要用戶登錄之后的接口
3. Token的實效性： token 可以是一次性的、也可以在一段時間范圍內是有效的
4. Token一般放在請求頭 headers 或者 body 參數里面。 -- 一般在接口文檔會有說明
Token鑒權流程
使用基於 Token 的身份驗證方法，在服務端不需要存儲用戶的登錄記錄。大概的流程是這樣的：
1. 客戶端使用用戶名跟密碼請求登錄
2. 服務端收到請求，去驗證用戶名與密碼
3. 驗證成功后，服務端會簽發一個 Token ，再把這個 Token 發送給客戶端
4. 客戶端收到 Token 以后可以把它存儲起來，比如放在 Cookie 里或者 Local Storage 里
5. 客戶端每次向服務端請求資源的時候需要帶着服務端簽發的 Token
6. 服務端收到請求，然后去驗證客戶端請求里面帶着的 Token ，如果驗證成功，就向客戶端返回
請求的數據
微信搜一搜【程序員阿沐】關注這個文縐縐的程序員，這樣的干貨內容還有近百篇。關注后主頁點擊【領取資料】有我准備的一線大廠面試資料和簡歷模板，希望大家都能找到心儀的工作，學習是一條時而郁郁寡歡，時而開懷大笑的路，加油。如果你通過努力成功進入到了心儀的公司，一定不要懈怠放松，職場成長和新技術學習一樣，不進則退。如果有幸我們江湖再見！
————————————————
分享的內容如果對你有幫助記得點贊讓更多的朋友看到！這個對我很重要！
————————————————