介面自動化測試（1）
一、架構
CRM客戶關係管理系統
SAAS Software As A Service 軟體即服務
PAAS Platform AS A Service 平臺即服務
快速交付→ 快：自己去幹、有結果、事事有迴音、持續改進
單體架構——》垂直架構——》面向服務架構——》微服務架構（分散式）
二、介面測試
方法論：類比，不同的事物中找到共同點
學習維度：
協議：本質是什麼？
主流工具：
程式碼框架：
MockServer
三、API自動化測試
接⼝測試⼜被稱為API測試，是軟體測試的⼀種測試模式，它包含了兩個維度，在狹義的⻆度上指的是對應⽤程式接⼝的功能進⾏測試，在⼴義的維度上是指整合測試中，通過調⽤API測試整體的功能來完成度，可靠性，安全性和效能。
介面測試這兩年為什麼這麼火？
SAAS架構全面落地，服務端的穩定性顯示的尤為重要
開發的模式改變，主要體現在前後端分離的模式上
測試工作：（面試題！！）
質量管理+測試效率提升
質量管理指的是：能夠積極的尋求推動問題解決方法和持續改進質量
提升測試效率可以說是：通過技術手段來提升研發效率從而進一步提升測試效率。
早會：昨天干了什麼？今天準備幹什麼？
四、金字塔模型：
UI層：可以理解為功能測試；
service：介面測試（API）；
Unit（單元測試）。
五、工具：
有很多主流的測試⼯具都可以做接⼝測試，如PostMan,JMeter,SoupUi等，除了⼯具還有在Python語⾔中很多 的第三⽅的庫都是可以來做接⼝測試的，如：urllib,requests,aiohttp等。
六、協議（重點！！！）
1、協議：是一套標準，大家都遵循
HTTP協議，也可以稱呼為“超⽂本傳輸協議”。
2、預設的埠是80。
3、HTTP目前使用的版本是HTTP/1.1 最新的版本是HTTP/2.0
網路請求的檢視步驟：
開啟網站→檢查→Network→重新整理網頁
HTTP/2.0版本使用：
在分散式架構以及微服務架構中，基於新⼀代的架構設計有了gRPC的協議，它就是基於HTTP/2.0的版本來進⾏設計的。（gRPC協議：應用在網際網路金融等領域。）
書：
圖解TCP/IP
網路分層
TCP/IP協議按層次主要為：應⽤層，傳輸層，⽹絡層，資料鏈路層。
應用層：
應⽤層決定了向⽤戶提供應⽤服務時通訊的活動。⽽HTTP的協議和gRPC的協議就是屬於應⽤層的協議。
傳輸層 ：
應⽤層的下層是⽹絡傳輸層，提供處於⽹絡連線中的兩臺計算機之間的資料傳輸。
⽹絡層 ：
主要是⽤來處理⽹絡上流動的資料包，所謂資料包就是⽹絡傳輸中的最⼩單位，在該層協議中，規範了通過怎樣的 路徑到達⽬標計算機，並且把資料包傳送給對⽅。 網路層：1、保障資料傳輸 2、知道資料傳輸的目的地
鏈路層：
主要是處理連線⽹絡的硬體部分，如作業系統，硬體裝置的驅動等。
三次握手（面試必問！！！）
（三次握手解決的問題？保障資料傳輸的安全性和可用性）
為了確保把資料能夠送到⽬標的伺服器，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就可以開始傳輸資料。
URI和URL
URI可以稱為統⼀資源識別符號，⽽URL是統⼀資源定位符。URI可以理解為標識某⼀個互聯⽹的資源，⽽URL表示的資源的地點。HTTP協議中使⽤URI定位到互聯⽹上的資源，這也是為什麼互聯⽹任意位置的資源我們都能夠獲取到的原因。
HTTP協議
在微服務的架構模式下，使⽤的也是輕量級的通訊模式（REST API），在微服務的架構模式中，需要清楚的是它的通訊可以分為同步通訊模式和非同步通訊模式， 或者更加具體本質的說就是請求/響應和非同步請求/響應（釋出/訂閱模式）。
HTTP請求流程：（重點！！！）
1、客戶端與服務端之間建立TCP的連結請求
2、客戶端傳送Request請求到服務端
3、服務端Response響應回覆客戶端的請求
4、客戶端與服務端之間關閉TCP的連結請求
持久連線：connection:keep-alive
持久連線 在HTTP的早期版本中，每次傳送請求，都需要進⾏⼀次TCP的連線和斷開（相當於上圖的步驟1和4），很明顯這對服務端的效能損耗是非常大的，同時也是增加了通訊量的開銷。在HTTP/1.0版本開始以及後⾯的版本中，有了持久連線，也就是keep-alive， 它的特點是隻要客戶端或者是服務端沒有明確斷開連線，那麼就得⼀直保持TCP的連線請求，持久連線減少了TCP 連線的重複連線和斷開造成的效能損耗，減輕了服務端的負載，也提升了整體相求響應時間的效能。