Python接口測試實戰1（上）- 接口測試理論

如有任何學習問題，可以添加作者微信：lockingfree

課程目錄

Python接口測試實戰1（上）- 接口測試理論
Python接口測試實戰1（下）- 接口測試工具的使用
Python接口測試實戰2 - 使用Python發送請求
Python接口測試實戰3（上）- Python操作數據庫
Python接口測試實戰3（下）- unittest測試框架
Python接口測試實戰4（上） - 接口測試框架實戰
Python接口測試實戰4（下） - 框架完善：用例基類，用例標簽，重新運行上次失敗用例
Python接口測試實戰5（上） - Git及Jenkins持續集成
Python接口測試實戰5（下） - RESTful、Web Service及Mock Server

PDF下載：鏈接:https://pan.baidu.com/s/1OwAa8nl1eeBj8fcrgd3sBA 密碼:e9d8

本節內容

• 接口及接口測試
• 網絡基礎知識：IP,域名, DNS及端口
• 網絡基礎知識：OSI七層模型及TCP協議
• HTTP協議

接口及接口測試

這里插播一個段子

上圖中，程序員口中提到的接口是什么意思呢？
手機殼有沒有顏色這個屬性（功能）？ --- 有
手機殼有沒有提供讓程序獲取它顏色的途徑？ --- 沒有，這個途徑就是接口

接口的概念

接口又稱API（Application Programming Interface,應用程序編程接口），是一些預先定義的函數，目的是提供應用程序與開發人員基於某軟件或硬件得以訪問一組例程的能力，而又無需訪問源碼，或理解內部工作機制的細節。

簡單概括為以下3點：

• 程序代碼（函數方法）
• 屏蔽實現細節
• 可以被訪問/調用來獲取信息或實現某些功能（提供訪問地址，定義了訪問規則）

接口自述（通俗的來說）：

• 首先我有一些功能（功能函數）
• 你不用關心我怎么實現的（屏蔽細節）
• 我會給你一個我的地址（接口地址）
• 你按照地址找到我，按照我規定的格式（請求類型）告訴我所需要的信息（參數）就行
• 我會給你個反饋（響應信息）

舉個栗子
西虹市公考報名處 --- 接口名稱
報名地址： 西虹市街口區帶莫路3號 --- 接口地址
現場需填寫資料： 姓名，身份證證號碼，專業，報考崗位等等 --- 接口參數
驗證規則： --- 參數驗證規則

• 身份證需與本人一致
• 專業需與報考崗位符合
• 報名時間 2024.8.22-2024.8.30
  現場會給出是否報名成功 --- 接口響應信息

軟件中的接口

軟件項目中，接口是系統與系統之間，模塊與模塊之間或者服務於服務之間相互調用的入口。
從開發者角度，接口是分工協作的產物，不同開發者實現自己的功能之后，封裝成接口，供其他開發者調用。其他開發者只要按規定格式發送一些必要參數，就能使用該功能

常見接口類型

• HTTP接口：通過HTTP協議傳輸的接口，可以傳輸文本表單數據，也可以傳輸Json類型的對象數據或xml類型的數據
• RPC: 遠程方法調用，隨着分布式系統的出現，當你需要調用部署到其他服務器上的方法時，需要用到RPC。RPC只是提出了這樣一個問題，有很多種解決方案，比如WebService(基於SOAP協議)， REST(基於HTTP協議）。
• SOAP: 簡單面向對象協議，基於HTTP，使用xml作為默認傳輸格式
• Web Service: 基於SOAP協議的一種RPC實現方案。相比傳統的HTTP接口只傳輸文本請求和文本相應，通過Web Service可以直接拿到遠程的一個對象，並能夠直接調用該對象的屬性和方法，比HTTP更高級。
• REST/RESTful API: REST，表述性狀態轉移。一種HTTP接口的設計風格，將一切接口視為資源，要求接口路徑同意管理，分版本管理，規定了GET/POST等請求以及HTTP狀態碼的使用規范，默認使用JSON格式傳輸。RESTful API即滿足REST風格即設計規范的API接口
  

什么是接口測試？

接口測試是測試系統組件間接口的一種測試。接口測試主要用於檢測外部系統與系統之間以及內部各個
子系統之間的交互點。測試的重點是要檢查數據的交換、傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等。

為什么要做接口測試？

• 接口測試介於單元測試與系統測試之間，單元測試一般由開發完成（不要相信開發）
• 接口是各種系統功能的基礎，一旦接口出現問題可能會引起許多系統功能的問題並且不容易定位
• 開展接口測試可以及早發現問題，有效降低測試成本
• 接口一般較UI相對穩定，利於進行自動化和持續集成

接口測試都測什么？
接口測試一般有以下崗位實施：

• 手工測試崗：先提測接口再提出功能，兼做接口自動化
• 服務端測試崗：梳理代碼，審核接口實現邏輯是否與業務設計一致，技術實現邏輯的合理性，異常流測試，接口壓測及安全性測試
• 測試開發崗：專職做接口（或UI）的自動化用例開發，測試工具開發

接口測試點參考：

怎樣掌握接口測試？

1. 了解OSI網絡模型，TCP/UDP協議，掌握HTTP/HTTPS協議，了解RPC, Web Service及REST，理解Session和Cookie
2. 掌握常用的接口測試工具如curl命令,Postman,Jmeter,LR,SoupUI,AB等
3. 掌握基本的抓包工具如Chrome開發者工具,Fiddler,Charles,Wireshark,tcpdumps等
4. 掌握一門編程語言Python或Java
5. 了解Nginx, Apache, Tomcat等服務器中間件
6. 掌握數據庫基本查詢命令，及一些NoSQL(如Redis)操作，用於檢查響應結果
7. 掌握基本的Linux日子查詢和篩選命令

接口測試重難點

1. 動態變量參數化
2. 接口依賴及中間變量問題
3. 異步接口結果驗證問題
4. 相應參數及嵌套很多的驗證問題
5. 接口測試框架的穩定性問題
6. 資源清理問題
7. 多接口場景測試
   ...

網絡基礎知識：IP,域名, DNS及端口

IP地址

就像每個人都有一個身份證號碼
IP地址是IP協議提供的一種統一的地址格式，它為互聯網上的每一個網絡和每一台主機分配一個邏輯地址

查看IP命令

• Windows: ipconfig
• Linux: ifconfig

Python練習：檢查字符串是否ip

def is_ip(ip):
    num_list = ip.split(".")
    for num in num_list:
        if not num.isdigit() or not 0 <= int(num) <=255:
            return False
    return True

print(is_ip("101.1.0.201"))

使用map函數實現方法（參考）

def  check_ipv4(str):
    ip = str.strip().split(".")
    return False if len(ip) != 4 or False in map(lambda x:True if x.isdigit() and 0<= int(x) <= 255 else False, ip) else True

端口

"端口"是英文port的意譯，可以認為是設備與外界通訊交流的出口。
如果把IP地址比作一間房子，端口就是出入這間房子的門。一個IP地址的端口可以有65536（即：2^16）個
端口類型

• 公認端口：從0到1023，緊密綁定於一些服務
• 注冊端口：人1024到49151，許多服務綁定這些端口，這些端口同樣用於許多其它目的。
• 動態或私有端口：從49152到65535。理論上，不應為服務分配這此端口。實際上，機器通常從1024起分配動態端口。

常見軟件默認端口

• Apache/Nginx(HTTP服務): 80
• Tomcat: 8080
• Oracle: 1521
• MySQL: 3306
• SQL Server: 1433
• PostgreSQL: 5432
• MongoDB: 27017
• Redis: 6379
• Memcached: 11211

查看端口命令

• Windows: netstat -ano
• Linux: netstat -ntlp

解決端口占用問題

• Windows: netstat -ano | findstr "8080",找到占用端口的程序的PID -> 打開任務管理器 -> 設置顯示PID -> 找到並結束對於程序
• Linux: netstat -ntlp | grep "8080", 找到對應的程序 -> ps -ef | grep "程序名" 找到對於的pid -> kill 相應的id

域名及DNS

由於IP地址不容易記憶，為IP地址賦予了一個利於記憶的別名，稱為域名
如，百度的ip為： 61.135.169.125，對應的域名為 www.baidu.com

如何查看域名所對於的ip？

• Windows/Linux: ping www.baidu.com

DNS
DNS即域名解析系統，域名和IP地址相互映射的一個分布式數據庫，提供域名轉到對應ip的服務

網絡基礎知識：OSI七層模型及TCP協議

OSI七層模型

OSI即開放系統互連參考模型，一種網絡架構，分為7層。

• 上三層---應用層，控制軟件方面
  • 應用層：文件傳輸，電子郵件，文件服務，虛擬終端 TFTP，HTTP，SNMP，FTP，SMTP，DNS，Telnet
  • 表示層：數據格式化，代碼轉換，數據加密
  • 會話層：解除或建立與別的接點的聯系(會話)
• 下四層---數據流層，用來管理硬件
  • 傳輸層：提供端對端的接口 TCP，UDP
  • 網絡層：為數據包選擇路由 IP，ICMP，RIP，OSPF，BGP，IGMP
  • 數據鏈路層 傳輸有地址的幀以及錯誤檢測功能 SLIP，CSLIP，PPP，ARP，RARP，MTU
  • 物理層 以二進制數據形式在物理媒體上傳輸數據 ISO2110，IEEE802，IEEE802.2

OSI七層模型及各層協議

TCP及UDP協議

TCP和UDP都是傳輸層的協議

• TCP：傳輸控制協議
• UDP: 數據報文協議

TCP和UDP的區別

• UDP的特點如下：

1. 無鏈接
2. UDP使用盡最大努力交付，不保證可靠性
3. UDP是面向報文的，UDP對應用層交付下來的報文，既不合並，也不拆分，而是保留這些報文的邊界。應用層交給UDP多長的報文，UDP就照樣發送，即一次發送一個報文
4. UDP沒有擁塞控制
5. UDP支持一對一、一對多、多對一和多對多的交互通信
6. UDP的首部開銷小，只有8字節

• TCP的特點：

1. TCP是面向連接的
2. 每條TCP連接只能用於兩個斷點，一對一
3. TCP提供可靠交付的服務：連接傳輸數據、無差錯、不丟失、不重復、並且按序到達
4. TCP提供全雙工通信
5. 面向字節流。TCP根據對方給出的窗口和當前網絡擁塞的程度來決定一個報文應該包含多少個字節

參考：TCP和UDP協議的對比

HTTP協議

HTTP：超文本傳輸協議，是用於從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議。
HTTP協議是一種無狀態協議，主要包含請求和相應兩大部分：

請求（Request)

請求是我們發送給接口的數據對象，包含接口地址（URL），請求方法，參數，請求頭（Headers), Cookies, 數據等
真實抓包一個請求：

請求原始格式-GET（Raw格式：Fiddler抓包得到）

GET https://www.sojson.com/open/api/weather/json.shtml?city=%E5%8C%97%E4%BA%AC HTTP/1.1
Host: www.sojson.com
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: __cfduid=dccd65c484a7657b468327b66023fefc41534934250; yjs_id=59d1c42afa817b578b4b562d1f72651f; ctrl_time=1

• 第1行： 請求方法 接口地址 HTTP協議版本
• 第2-N行：請求headers(如果有Cookie，最后一行為Cookie)
• 空一行
• 請求數據（POST等方法使用，此處為空）

請求原始格式-POST請求（Raw格式：Fiddler抓包得到）

POST http://openapi.tuling123.com/openapi/api/v2 HTTP/1.1
Content-Type: application/json
cache-control: no-cache
Postman-Token: 1a39439e-61c8-4e59-82a1-736a362c5962
User-Agent: PostmanRuntime/7.2.0
Accept: */*
Host: openapi.tuling123.com
accept-encoding: gzip, deflate
content-length: 468
Connection: keep-alive

{
	"reqType":0,
    "perception": {
        "inputText": {
            "text": "附近的酒店"
        },
        "inputImage": {
            "url": "imageUrl"
        },
        "selfInfo": {
            "location": {
                "city": "北京",
                "province": "北京",
                "street": "信息路"
            }
        }
    },
    "userInfo": {
        "apiKey": "ec961279f453459b9248f0aeb6600bbe",
        "userId": "206379"
    }
}

URL

URL：統一資源定位符，接口的訪問地址（包含服務器地址+接口地址）

URL組成格式

協議\\: 服務器地址:端口號\資源路徑?參數1=值1&參數2=值2

如：https://www.sojson.com/open/api/weather/json.shtml?city=北京

注意：?號要使用英文?,不能使用中文？

URL編碼
URL編碼是一種瀏覽器用來打包請求參數及表單參數的格式, 參數和參數之間使用&分割，非ASCII碼使用%加16進制編碼替換
如：https://www.sojson.com/open/api/weather/json.shtml?city=北京
編碼后為：https://www.sojson.com/open/api/weather/json.shtml?city=%E5%8C%97%E4%BA%AC

鏈接：URL編碼/解碼工具(http://tool.chinaz.com/Tools/urlencode.aspx)

請求方法

序號	方法	描述
1	GET	請求指定的頁面信息，並返回實體主體
2	POST	向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）數據被包含在請求體中
3	HEAD	類似於get請求，只不過返回的響應中沒有具體的內容，用於獲取報頭
4	PUT	從客戶端向服務器傳送的數據取代指定的文檔的內容
5	DELETE	請求服務器刪除指定的頁面
6	CONNECT	預留給能夠將連接改為管道方式的代理服務器
7	OPTIONS	允許客戶端查看服務器的性能
8	TRACE	回顯服務器收到的請求，主要用於測試或診斷

GET請求和POST請求的區別

• GET請求：

  • GET請求可被緩存
  • GET請求保留在瀏覽器歷史記錄中
  • GET請求可被收藏為書簽
  • GET請求不應在處理敏感數據時使用
  • GET請求有長度限制
  • GET請求只應當用於取回數據

• POST請求：

  • POST請求不會被緩存
  • POST請求不會保留在瀏覽器歷史記錄中
  • POST不能被收藏為書簽
  • POST請求對數據長度沒有要求

請求參數（URL參數）

如：https://www.sojson.com/open/api/weather/json.shtml?city=北京

• 中的city=北京,向接口傳遞一個參數“city”,參數值為“北京”
• 不同的參數之間用&隔開，非ASCII碼參數會自動url encode

請求Headers（請求頭）

常見Headers

請求數據(又稱為Request Body 或 Data)

請求數據類型（Content-Type）（重點）

• application/x-www-form-urlencoded： 網頁表單格式（默認）
• application/json：REST接口常用格式
• text/xml：xml格式，RPC接口，Dubbo接口常用格式
• test/html： html格式
• multipart/form-data: 混合表單，支持上傳圖片

數據編碼

• ASCII碼: 單字節，美國信息交換標准碼, 包含數字，字母，英文標點及一些控制字符
• ISO-8859-1：又稱Latin1，單字節，向下兼容ASCII，用於支持部分於歐洲使用的語言
• ANSI編碼：單字節表示英文，雙字節表示漢字，對ASCII的擴展，不同的國家和地區制定了不同的標准，中文中的GBK,GB2312屬於ANSI編碼
• Unicode編碼: 采用二個字節編碼（英文和中文的字符都以雙字節存放），與ANSI碼不兼容
• UTF-8：是目前互聯網上使用最廣泛的一種Unicode 編碼方式，又稱萬國碼

指定請求數據編碼（解決中文亂碼）：
請求Headers設置Content-Type: application/json; charset=utf-8

• Base64: 一種用64個字符來表示任意二進制數據的方法。
  • Base64編碼的作用：由於某些系統中只能使用ASCII字符。Base64就是用來將非ASCII字符的數據轉換成ASCII字符的一種方法。
  • 而且base64特別適合在http，mime協議下快速傳輸數據。

參考：Base64編碼及其作用

響應（Response)

接口返回的信息，包含HTTP狀態碼，響應頭和相應信息

原始相應數據（Raw格式，Fiddler抓包）

HTTP/1.1 200 OK
Date: Thu, 23 Aug 2018 06:32:26 GMT
Transfer-Encoding: chunked
Connection: keep-alive

{"intent":{"actionName":"","code":10005,"intentName":"","parameters":{"lon":"","checkout_date":"2018-08-25","star":"0","city":"北京","days":"1","order":"","price_range":"","nearby_place":"酒店","brand":"","checkin_date":"2018-08-24","place":"信息路","lat":"","needgeo":"0"}},"results":[{"groupType":1,"resultType":"url","values":{"url":"http://m.elong.com/hotel/0101/nlist/#indate=2018-08-24&outdate=2018-08-25&keywords=%E4%BF%A1%E6%81%AF%E8%B7%AF"}},{"groupType":1,"resultType":"text","values":{"text":"親，已幫你找到相關酒店信息"}}]}

常見的響應格式

• html
• json
• xml

響應編碼：有時需要根據不同的編碼來正確解析響應內容

HTTP狀態碼

• 1** 信息，服務器收到請求，需要請求者繼續執行操作
• 2** 成功，操作被成功接收並處理
• 3** 重定向，需要進一步的操作以完成請求
• 4** 客戶端錯誤，請求包含語法錯誤或無法完成請求
• 5** 服務器錯誤，服務器在處理請求的過程中發生了錯誤

常見HTTP響應碼

• 200： 成功
• 301/302： 請求重定向到另外一個接口
• 400: 請求語法錯誤
• 403：資源沒有訪問權限
• 404：資源不存在（有可能是請求url錯誤或參數不正確）
• 405：請求方法不被允許（比如接口只允許Post,使用Get請求接口）
• 500：服務器內部錯誤（通常是服務器掛了或接口Bug)
• 502: 網關失效
• 504: 網關請求超時

HTTP與HTTPS

HTTP協議傳輸的數據都是未加密的，HTTPS協議是由HTTP+SSL協議構建的可進行加密傳輸、身份認證的網絡協議，要比HTTP協議安全。
HTTPS和HTTP的區別

• HTTPS協議需要到ca申請證書，一般免費證書較少，因而需要一定費用。
• HTTP是超文本傳輸協議，信息是明文傳輸，HTTPS則是具有安全性的SSL加密傳輸協議。
• HTTP和HTTPS使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。
• HTTP的連接很簡單，是無狀態的；HTTPS協議是由HTTP+SSL協議構建的可進行加密傳輸、身份認證的網絡協議，比HTTP協議安全。

Cookie和Session

• **Cookie/Cookies: **是指某些網站為了辨別用戶身份、進行session跟蹤而儲存在用戶本地終端上的數據（通常經過加密）。
• Session：服務端為客戶端訪問所建立和維持的會話，通常會生成一個唯一的id，會話有一定的有效期。
  由於HTTP是無狀態的，即服務器不知道用戶上一次做了什么，默認也無法識別用戶身份。
  比較流行的做法是：
• 用戶訪問時服務端建立會話（Session）
• 將會話id（Session ID）隨響應返回，並保存在客戶端的Cookies里
• 后續的訪問中，服務器通過辨識，客戶端請求時攜帶的Cookies內容來識別用戶

Cookie和Session的區別

• cookie是存在客戶端（瀏覽器）的進程內存中和客戶端所在的機器硬盤上
• cookie只能能夠存儲少量文本，大概4K大小
• cookie是不能在不同瀏覽器之間共享
• Session存在服務器端，存在網站進程的內存中
• Session在初次設置session的時候，會在session池中實例化一個session對象，以sessionid 的值作為key，同時會將key以cookie的形式保存到客戶端的內存中
• Session的作用域只存在當前瀏覽器的會話中，當瀏覽器關閉以后就會將sessionid丟失，但是服務器的Session對象要20分鍾以后才會回收

授權與加密

常見的接口安全策略：

1. Session/Cookie機制： 即需要登錄，登錄后可訪問各個接口，最常用的一種策略，適用於內部接口。
2. 固定appid模式： 用戶注冊時會生成一個唯一的appid，用戶調用接口時需要攜帶appid，適用於公開接口，安全性較差。
3. 動態token模式： token即身份令牌，用戶訪問接口需要使用個人appid臨時申請一個token，token有一定有效期，適用於公開接口，安全性較appid模式好。
4. 開放協議： Basic Auth/ Oauth1.0 / Oauth2.0: 適用於開放接口。
5. 數字簽名： 將所有請求參數及參數值進行排列拼接，加上用戶私鑰，再進行Md5或其他加密生成一個請求的簽名（sign）,請求是需要攜帶簽名，服務器收到請求后，會對請求重新計算簽名並核實與請求所攜帶簽名是否一致。安全性較高，可以有效防止請求被篡改。適用於內部接口及微服務接口。

常見的加密算法
在接口數據傳輸過程中常對一些敏感數據（如密碼）進行Base64編碼或MD5加密，以增加安全性。
加密算法分為對稱式加密算法和非對稱式加密算法，對稱式加解密使用同一個秘鑰，非對稱式使用不同的秘鑰。

• 對稱式加密
  • DES: 數據加密標准，速度較快，適用於加密大量數據的場合
  • AES: 高級加密標准，速度快，安全級別高
• 非對稱式加密
  • RSA: 是一個支持變長密鑰的公共密鑰算法， 分公鑰和私鑰，SSH協議使用該算法
  • MD5: 最常用的一種加密方法，是一種摘要算法。

緩存

HTTP 緩存機制作是 web 性能優化的重要手段，當用戶第一次請求服務器資源時，服務器將資源緩存到客戶端本地，在一定時間內（緩存有效期內）當用戶再次向服務器請求同樣的資源時，可以直接從緩存中讀取，而不用從服務器下載。

接口測試中緩存相關注意點

• 在更新或調試接口是，注意是否需要清理緩存（或臨時禁用緩存）
• 緩存有一定的有效期
• 接口性能測試中會關注緩存的命中率