一.基礎

1.API測試技術棧

1、協議
2、介面測試的工具:PostMan,JMeter
3、介面測試的框架
4、MockServer

2.單體架構的開發模式

圖書管理系統：

業務場景：看到喜歡的書，然後下單，支付，購買

單體架構的模式是把前後以及所有的業務場景的程式碼都整合到一起

業務模組：書籍管理、支付模組、賬戶模組、物流模組

3.微服務架構模式

微服務架構就是根據業務場景，把每個獨立的業務場景單獨分離成一個服務，這樣服務和服務之間通訊，通訊通過REST API 或者gRPC的協議來進行互動。

4.場景

開發：

1、前端程式設計師把程式碼寫完，後端程式設計師把程式碼寫完

2、前端和後端進行聯調（前端把輸入的賬戶和密碼拿到，然後傳送給(HTTP的協議)後端）

3、後端拿到前端傳送的資料進行驗證

測試：

1、驗證這個過程中業務邏輯是否能夠成功

5.金字塔模型

在⾦字塔的模型中，在測試分為三個維度來進⾏思考，分別是單元，服務和UI三個層級。這地⽅主要的說下服務層的測試，在服務層的測試維度中，主要針對的是業務接⼝的測試，來驗證接⼝功能是否完整，如內部邏輯，異常處理。這樣的⽬的是驗證接⼝它是否穩定，所以接⼝的測試相對⽽⾔⽐較容易⽽且更加⾼效,測試⽤例的維護成本也低。 有很多主流的測試⼯具都可以做接⼝測試，如PostMan,JMeter,SoupUi等，除了⼯具還有在Python語⾔中很多的第三⽅的庫都是可以來做接⼝測試的，如：urllib,requests,aiohttp等。

在金字塔的模型中：
1、金字塔模型把開發測試的模型分為三層，分別是單元測試，介面測試，和UI測試
2、unit:單元測試 services:介面測試（API自動化測試） UI：UI測試(功能測試,ui自動化測試)
3、越底層的，越應該投入更多的精力去保障，越上層的，投入少量的精力去保障

6.HTTP

1989年的3⽉份了，誕⽣了HTTP的協議，也可以稱呼為“超⽂本傳輸協議”。

HTTP/0.9
HTTP從發展開始，⼀直沒有⼀個統⼀的標準，最典型的版本是HTTP/0.9
HTTP/1.0
HTTP協議作為正式的標準是在1996年的5⽉份，版本被命名為HTTP/1.0的版本。
HTTP/1.1
1997年釋出的HTTP
 
/1.1的版本是⽬前⽐較主流的HTTP的版本，很遺憾的是從HTTP/1.1的版本之後，就⼀直停⽌不
前，⽽且⽬前⼀直使⽤的也是HTTP/1.1的版本。
HTTP/2.0
新⼀代的HTTP協議是HTTP/2.0的版本，它⽀持流式的處理，以及進⾏了很多的優化，但是很遺憾的是沒有被⼤規
模的應⽤。在分散式架構以及微服務架構中，基於新⼀代的架構設計有了gRPC的協議，它就是基於HTTP/2.0的版
本來進⾏設計的。

7.微服務的架構通訊模式：

微服務的通訊模式使用的方式有兩種：
1、一種是採用基於REST API的輕量級的基於HTTP的協議
2、使用的是gRPC的協議

二.網路分層

1.TCP/IP分層管理

應用層
應⽤層決定了向⽤戶提供應⽤服務時通訊的活動。⽽HTTP的協議和gRPC的協議就是屬於應⽤層的協議。
傳輸層
應⽤層的下層是⽹絡傳輸層，提供處於⽹絡連線中的兩臺計算機之間的資料傳輸。
核心的協議就是TCP/IP的協議
TCP/IP通訊傳輸流
網路層
主要是⽤來處理⽹絡上流動的資料包，所謂資料包就是⽹絡傳輸中的最⼩單位，在該層協議中，規範了通過怎樣的
路徑到達⽬標計算機，並且把資料包傳送給對⽅。
鏈路層
主要是處理連線⽹絡的硬體部分，如作業系統，硬體裝置的驅動等。

2.websoket協議（auth2.0）：

websocket協議：客戶端與服務端始終保持持久連線 不會斷開


客戶端：拿微信來說，手機微信，電腦微信，都是客戶端
服務端：騰訊的微信伺服器

3.三次握手

為了確保把資料能夠送到⽬標的伺服器，TCP協議內部使⽤了三次握⼿的策略機制，也就是說在TCP協議中，TCP把資料包送去後，TCP會進⾏確認對⽅是否收到，或者是確認是否成功送達，那麼三次握⼿主要使⽤了TCP的標誌，具體為：SYN和ACK。⾸先Client端傳送連線請求報⽂，Server段接受連線後回覆ACK報⽂，併為這次連線分配 資源。Client端接收到ACK報⽂後也向Server段傳送ACK報⽂，並分配資源，這樣TCP連線就建⽴了。總結三次握⼿具體為：

• 第⼀次握⼿：起初兩端都處於CLOSED關閉狀態，Client將標誌位SYN置為1，隨機產⽣⼀個值seq=x，並將該資料包傳送給Server，Client進⼊SYN-SENT狀態，等待Server確認；

• 第⼆次握⼿：Server收到資料包後由標誌位SYN=1得知Client請求建⽴連線，Server將標誌位SYN和ACK都置為1，ack=x+1，隨機產⽣⼀個值seq=y，並將該資料包傳送給Client以確認連線請求，Server進⼊SYN-RCVD狀態，此時作業系統為該TCP連線分配TCP快取和變數；

• 第三次握⼿：Client收到確認後，檢查ack是否為x+1，ACK是否為1，如果正確則將標誌位ACK置為1，ack=y+1，並且此時作業系統為該TCP連線分配TCP快取和變數，並將該資料包傳送給Server，Server檢查ack是否為y+1，ACK是否為1，如果正確則連線建⽴成功，Client和Server進⼊ESTABLISHED狀態，完成三次握⼿，隨後Client和Server就可以開始傳輸資料。

三次握手的設計：

應用層的協議是為了上層應用之間的互動，但是不需要關注底層網路傳輸層之間的事情，那麼問題來了？應用層既然不關注網路傳輸層的事情，網路傳輸層怎麼保障應用層之間資料的傳輸？所以為了資料傳輸的安全和保障，就設計了三次握手。
1、服務端的確認：客戶端傳送資料出去，服務端需要確認我收到了
2、服務端反饋：服務端告訴客戶端，你傳送的資料我這邊確認收到了
3、客戶端確認：客戶端需要向服務端再次反饋，客戶端收到服務端的反饋了

4.URI和URL

URI可以稱為統一資源識別符號，而URL是統一資源定位符。URI可以理解為標識某一個網際網路的資源，而URL表示的是資源的地點。

三.HTTP協議

HTTP是應⽤層的協議，它不需要刻意的去關注底層⽹絡傳輸層協議的東⻄。在整體應⽤層的協議中，通俗的說在整個API的測試維度上，需要關注的是⼀個完整的HTTP請求流程，請求⽅法，請求頭響應頭，COOKIE請求流程，SESSION的請求流程和TOKEN的請求流程，以及HTTPS的請求流程。在微服務的架構模式下，使⽤的也是輕量級的通訊模式（REST API），在微服務的架構模式中，需要清楚的是它的通訊可以分為同步通訊模式和非同步通訊模式，或者更加具體本質的說就是請求/響應和非同步請求/響應（釋出/訂閱模式）。協議可以具體⻅如下：

1.HTTP協議請求流程

2.檢視請求

3.通訊模式

3.1同步通訊

在客戶端與服務端在進⾏互動的時候，通訊模式主要分為同步通訊和非同步通訊。同步通訊簡單的可以理解為客戶端傳送請求給服務端，服務端必須得迴應客戶端的請求。所以同步通訊它存在如下的缺點，具體為：

• 容易超時，客戶端傳送請求後，服務端遲遲沒有迴應客戶端的請求

• 如果請求是存在⼤的計算量和邏輯存在問題，就會導致請求堵塞，後⾯的都積壓

3.2非同步通訊

由於同步互動存在超時以及堵塞的情況，所以也就有了非同步的互動。在非同步的互動中，客戶端和服務端互相不需要關注對⽅的存在，只需要關注對應的MQ的訊息，客戶端與服務端的互動主要是會通過MQ的訊息中間作為訊息的傳遞來進⾏互動的，具體互動如下：