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

時間 2019-11-08

原文原文鏈接

若有任何學習問題，能夠添加做者微信：lockingfreehtml

課程目錄

更多學習資料請加QQ羣: 822601020獲取程序員

本節內容

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

接口及接口測試

這裏插播一個段子

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

接口的概念

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

簡單歸納爲如下3點：數據庫

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

接口自述（通俗的來講）：編程

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

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

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

軟件中的接口
api

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

常見接口類型

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）的自動化用例開發，測試工具開發

接口測試點參考：

怎樣掌握接口測試？

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

接口測試重難點

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

網絡基礎知識：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的特色以下：

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

TCP的特色：

TCP是面向鏈接的
每條TCP鏈接只能用於兩個斷點，一對一
TCP提供可靠交付的服務：鏈接傳輸數據、無差錯、不丟失、不重複、而且按序到達
TCP提供全雙工通訊
面向字節流。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分鐘之後纔會回收

受權與加密

常見的接口安全策略：

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

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