碼上歡樂
相關內容    簡體    繁體

API接口測試

本文轉載自   查看原文   2022-01-02 22:04   1043 

一.基礎

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分層管理

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的消息中間作為消息的傳遞來進⾏交互的，具體交互如下：

 4.HTTP常用請求方法

GET 客戶端從服務端獲取資源
POST 客戶端往服務端發送請求添加新的資源
PUT 客戶端針對服務端已有的數據進行更新
DELETE 客戶端刪除服務端已有的數據
CONNEC HTTP/1.1協議中預留給能夠將連接改為管道方式的代理服務器
OPTIONS 允許客戶端查看服務器的特性
TRACE 回顯服務器收到的請求，主要用於測試或診斷
HEAD 類似於get請求，只不過返回的響應中沒有具體的內容，用於獲取報頭

 

由於PUT和DELETE請求方法不安全，所以了很多時候，往往會使用POST來進行替代。

5.HTTP請求的組成部分

5.1Requests請求部分

  • 請求地址：Request URL
  • 請求方法：Request Method
  • 請求頭：Request Headers
    • Content-Type:指的是數據格式
    • Cookie：反爬蟲，身份憑證
    • Referer：發送請求的地址是從哪里來的
    • User-Agent：發送網絡請求的時候向服務端標注請求是通過什么瀏覽器或者什么軟件(PostMan,JMeter)發送的
  • 請求參數
    • get：路徑參數 
      如：
     http://xxx.com/?name=wuya&age=18 ?key1=value1&key2=value2

       PS：get的請求參數與數據格式沒任何關系

    • post：在payload中顯示了請求的參數

5.2Response響應部分

  • 協議狀態碼

    • 200 #請求成功
    • 301 #永久重定向
     
    • 302 #臨時重定項
     
    • 400 Bad Request #客戶端請求錯誤
      1.請求參數不對
      
2.請求頭不對
    • 401 Unauthorized #無權限訪問該系統 
    • 403 Forbidden #有權限但是禁止訪問 
    • 404 #請求的資源不存在
    
      請求的地址不存在，所以導致請求的資源也是不存在
    • 405 #不被允許的請求方法
   
       你請求的方法，沒有定義對應的請求方法，但是你去進行訪問

    • 500 #服務器內部錯誤
   
      空指針 Null PointExpection
            堆棧溢出 在測試選擇項的時候，選擇很多很多的項，同時觸發，看是否會暴露該問題
            OOM（內存泄露） Out Of Memory 
            其他異常:Expection 
    • 504 #GateWay Timeout 
      網關超時
  • 響應數據 
    響應數據返回的數據格式是由響應頭里面的content-type來決定的

     

  • 響應頭
    • content-type:指明返回的響應數據的數據格式是什么
    • set-cookie:服務端返回給客戶端的登錄憑證
  • 1

5.3常用的表單數據

  • 表單 

    application/x-www-form-urlencoded; charset=UTF-8(GBK)

  • json格式

    application/json;charset=UTF-8 json數據格式：基於JSON的數據格式，但是數據類型是字符串

  • ext/html 

    返回的是基於html的數據格式

  • text/xml

    返回的是基於xml的數據格式

     

以下為百度首頁的請求響應數據：

General：

Request URL: https://www.baidu.com/   #請求地址
Request Method: GET   #請求方法
Status Code: 200 OK   #請求狀態
Remote Address: 36.152.44.95:443   #遠程地址
Referrer Policy: unsafe-url
Response Headers：   #響應頭


Bdpagetype: 2   Bdqid: 0xe010484800023fd8
Cache-Control: private
Connection: keep-alive   #連接
Content-Encoding: gzip   #響應內容編碼
Content-Type: text/html;charset=utf-8   #返回的數據類型和編碼
Date: Mon, 03 Jan 2022 15:48:08 GMT   #響應產生的時間
Expires: Mon, 03 Jan 2022 15:48:08 GMT   #有效期
Server: BWS/1.1   #服務器的信息
Set-Cookie: BDSVRTM=299; path=/
Set-Cookie: BD_HOME=1; path=/
Set-Cookie: H_PS_PSSID=35640_35468_35105_35631_35489_34584_35491_35245_35317_26350_35621_35561; path=/; domain=.baidu.com
Strict-Transport-Security: max-age=172800
Traceid: 1641224888055166925816145484138198220760
Transfer-Encoding: chunked
X-Frame-Options: sameorigin
X-Ua-Compatible: IE=Edge,chrome=1
Request Headers：   #請求頭


Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9   #指定客戶端接收的數據類型
Accept-Encoding: gzip, deflate, br   #客戶端可接受的內容編碼
Accept-Language: zh-CN,zh;q=0.9   #客戶端可接受的語言編碼
Connection: keep-alive
Cookie: BIDUPSID=1BC8669236942C81DEB0A40AA5BB8099; PSTM=1635924020; BAIDUID=1BC8669236942C8160730242377CD27E:FG=1; __yjs_duid=1_51a616f347f31a89b8d2b2cf652ce7371635924140466; __sec_t_key=c6f49002-912c-474e-bbcb-0e614ab9a6d2; BAIDUID_BFESS=1BC8669236942C8160730242377CD27E:FG=1; Hm_lvt_aec699bb6442ba076c8981c6dc490771=1637285395,1638457818,1638863850; COOKIE_SESSION=104510_1_8_9_14_3_1_0_8_3_2_0_104511_0_3_0_1638949274_1638412634_1638949271%7C9%231127298_3_1638412631%7C2; BDUSS=ZjNDZEUEI0TGdGaHNVRUFQT2xZcFo5Wm82N0YxNXd3YTZDS2NEZ2xQLWhHZWxoRVFBQUFBJCQAAAAAAAAAAAEAAAA7Sk2R556O6Ze58J-SpgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKGMwWGhjMFhUD; BDUSS_BFESS=ZjNDZEUEI0TGdGaHNVRUFQT2xZcFo5Wm82N0YxNXd3YTZDS2NEZ2xQLWhHZWxoRVFBQUFBJCQAAAAAAAAAAAEAAAA7Sk2R556O6Ze58J-SpgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKGMwWGhjMFhUD; BD_UPN=12314753; BD_HOME=1; BDRCVFR[feWj1Vr5u3D]=I67x6TjHwwYf0; delPer=0; BD_CK_SAM=1; PSINO=3; H_PS_PSSID=35640_35468_35105_35631_35489_34584_35491_35245_35317_26350_35621_35561; H_PS_645EC=477eCF32idOG1i0IqrcDOoCO%2Faa8D7RccotKPSIkoV97Agl5xRK0sbMHJZh4M8nT681n; BDORZ=B490B5EBF6F3CD402E515D22BCDA1598; baikeVisitId=44bef63e-f3f8-454f-a3a4-aa768bee9829; BA_HECTOR=8g0h2g0kal2g2404rc1gt66li0q; WWW_ST=1641224888826
Host: www.baidu.com   #請求主機的IP地址和端口號
Referer: https://www.baidu.com/　　#請求是從哪個頁面發送過來的
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="96", "Google Chrome";v="96"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36　　#識別客戶端使用的操作系統版本 瀏覽器版本信息等

 四.cookie、session、token

由於http是一個無狀態的協議，但是由於互聯網產品迭代的發展，需要記住用戶的操作行為習慣等

1.cookie

主要是存儲用戶操作行為的數據，在早期的互聯網產品中，用戶登錄系統的憑證都是由cookie來進行記錄的，但是由於是存儲在客戶端
的（本機的電腦），所以是不安全的，基本目前登錄認證的憑證不會再使用cookie的技術了

2.session

由於cookie是存儲在客戶端的，它不安全，所以session是把登錄成功后的數據存儲在服務端

session流程

客戶端輸入賬號和密碼，點擊登錄
登錄成功后，會在服務端把用戶登錄成功后的信息生成一個sessionid的憑證，並且存儲在服務端
服務端通過響應頭中的set-cookie把生成的sessionid返回給客戶端
客戶端再次查看個人主頁或其他行為，客戶端會通過請求頭中的cookie，把set-cookie返回的sessionid帶上，發送給服務端
服務端接收到客戶端發送的sessionid，和存儲在服務端的session ID作一個對比
如果對比一致，用戶可以繼續反問系統的任何功能，如果對不一致，立刻跳轉到登錄的頁面

實戰

我們以一品威客官網的登錄請求為例，服務端把sessionid通過響應頭中的set-cookie返回給客戶端

     然后我們在進行其他操作，如查看個人首頁，客戶端會通過請求頭中的cookie，把set-cookie返回的sessionid帶上，發送給服務端，服務端接收到客戶端發送的sessionid，和存儲在服務端的session ID作一個對比，如果對比一致，用戶可以繼續反問系統的任何功能，如果對不一致，立刻跳轉到登錄的頁面

 比如我們刪除Application中cookies中的信息來模擬客服端發送的sessionid與服務端儲存的sessionid不一致，重新發送請求就會重新登錄

3.token

本質上是session的原理，我們可以把它理解為一個令牌，每次登錄成功后，返回的token都是隨機的字符串 使用jwt的技術來實現

 token流程

客戶端輸入賬戶和密碼，點擊登錄
登錄成功后，會在服務端把用戶登錄成功后的信息生成一個Token的憑證，同時了存儲在服務端
服務端會通過響應數據或者是響應頭中的set-cookie返回給客戶端
那么客戶端再次向服務端發送請求，會在請求參數或者請求頭中的Authuration中帶上返回來的token發送給服務端
服務端接收到客戶端發送的Token，和存儲在服務端的Token作一個對比
如果對比一致，用戶可以繼續反問系統的任何功能，如果對不一致，立刻跳轉到登錄的頁面

實戰　　

我們以考蟲的官網登錄請求為例：

 登錄成功后，服務端會把tokenid通過響應頭中的set-cookie返回給客戶端，當我們再次請求時，會在請求參數或者請求頭中的Authuration中帶上返回來的token發送給服務端

 

 

 


免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。



猜您在找 Restful API接口測試 REST API接口測試 API測試-接口測試基礎（1） golang 調用順豐API接口測試 Jmeter接口測試-刪除任務API Python基礎（API接口測試） API接口測試（菜鳥之路） python寫api接口測試之tornador 接口測試-免費開放的api API接口測試--python實現接口自動化
 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM