快捷導(dǎo)航

利用python進行接口測試及類型介紹

更新時間：2022年05月19日 16:30:44 作者：錦都不二

這篇文章主要介紹了利用python進行接口測試詳情，文章基于python展開對接口測試的詳細介紹，具有一定的參考價值，需要的小伙伴可以參考一下

前言

其實我覺得接口測試很簡單，比一般的功能測試還簡單（這話我先這樣說，以后可能會刪O(∩_∩)O哈！），現(xiàn)在找工作好多公司都要求有接口測試經(jīng)驗，也有好多人問我（也就兩三個人）什么是接口測試，本著不懂也要裝懂的態(tài)度，我會說：所謂接口測試就是通過測試不同情況下的入?yún)⑴c之相應(yīng)的出參信息來判斷接口是否符合或滿足相應(yīng)的功能性、安全性要求。

我為啥說接口測試比功能測試簡單呢，因為功能測試是從頁面輸入值，然后通過點擊按鈕或鏈接等傳值給后端，而且功能測試還要測UI、前端交互等功能，但接口測試沒有頁面，它是通過接口規(guī)范文檔上的調(diào)用地址、請求參數(shù)，拼接報文，然后發(fā)送請求，檢查返回結(jié)果，所以它只需測入?yún)⒑统鰠⒕托辛耍鄬碚f簡單了不少。

正好最近在做接口測試，之前公司的方案是使用postman進行接口測試。但是偉大的墻導(dǎo)致我們只能用離線版postman。。然后一個很長很長的接口列表，一個接一個的訪問。我的天哪。。所以萌生了一個想法，使用python編寫一套接口測試腳本，設(shè)置接口列表，然后逐條訪問，輸出日志。

接口測試的坑

第一個坑：

POST 和 GET----GET一般用于獲取/查詢資源信息，而POST一般用于更新資源信息|Get是向服務(wù)器發(fā)索取數(shù)據(jù)的一種請求，而Post是向服務(wù)器提交數(shù)據(jù)的一種請求。

做過接口測試或者做過前端的人都知道，接口的訪問方式是不一致的，所以才會使用postman來進行接口測試，因為它可以設(shè)置post和get方式。使用python模擬這倆種訪問方式是重中之重。先說GET方式。GET方式就比較簡單了，把接口放進瀏覽器地址欄，點下回車就完成了一次GET。所以就需要使用python訪問URL就可以模擬一次GET 測試。

?import urllib2
?url_save = 'http://www.baidu.com/'
?try:
?s_save = urllib2.urlopen(url_save).read()
print s_save ?
except urllib2.HTTPError, e:
?print e.code
?except urllib2.URLError, e:
?print str(e)

如上所示就完成了一次GET請求，調(diào)用urllib2庫，然后將一個字符串形式的URL傳給urllib2.urlopen函數(shù)，最后使用read（）方法將GET回來的數(shù)據(jù)存儲起來。

然后說說POST。其實在python的urllib2庫中，我們剛剛所使用的urlopen函數(shù)還有其他幾樣不是必選的入?yún)ⅲ?strong>因為這些入?yún)⒔o定了初始化的值：

def urlopen(url, data=None, timeout=socket._GLOBAL_DEFAULT_TIMEOUT,
?cafile=None, capath=None, cadefault=False, context=None):

如上代碼，urllib庫有一個很智能的毛病。data不給值，訪問方式就是GET，data給了值，方式就會變成POST；所以模擬POST 方式的代碼如下：

import urllib?
import urllib2?
url = 'http://www.example.com'?
# values的形式：name：value
values = {'**' : '***',?
? ? ? ? ? '**' : '***',?
? ? ? ? ? '**' : '***' }?
#使用urllib.urlencode函數(shù)對values字典進行處理，最終形式為：**=***&**=***
data = urllib.urlencode(values)?
#如果對data順序有要求，建議自己拼接data
req = urllib2.Request(url, data)?
response = urllib2.urlopen(req)?
the_page = response.read()

就像如上代碼，把POST方式所需要的數(shù)據(jù)寫到data參數(shù)中去，POST方式就模擬成功了。

第二個坑：cookie的使用

用python獲取cookie所需要的庫叫做cookielib。獲取cookie的例子：

# 這里有四種CookieJar，CookieJar是最原始的
cookie_use = cookielib.CookieJar()
?handler = urllib2.HTTPCookieProcessor(cookie_use)
?# 使用綁定好CookieJar的handler創(chuàng)建一個opener
?opener = urllib2.build_opener(handler)
?# 將opener安裝到urllib2中
?urllib2.install_opener(opener)
# 使用安裝好的urllib2訪問某一網(wǎng)站獲取cookie
?urllib2.urlopen('https://....../login')
?#這個時候cookie已經(jīng)被CookieJar獲取到了
?print cookie_use

在下一步，將獲取到的cookie綁定到opener頭中：

'''
? 將獲取到的cookie綁定到opener，上一步獲取的cookie并不滿足如下格式，
需要自己進行字符串的切片和拼接?
?'''
opener.addheaders.append(('Cookie', 'name=***&888=888'))

現(xiàn)在的opener就可以用來訪問任意需要登錄的網(wǎng)站了！

功能:功能實現(xiàn),實現(xiàn)與設(shè)計一致, 接口通過性測試

健壯性: 邊界值,容錯性
性能: 并發(fā)及壓測
穩(wěn)定性: 長期運行的穩(wěn)定性
安全性: SQL注入, session依賴, 數(shù)字簽名, http接口的安全性

接口類型

常見接口種類：

Http/Https接口: 通過http/https協(xié)議傳送接口數(shù)據(jù)(通常按字符串/二進制傳輸), 如常見的網(wǎng)頁表單, https安全性更好
RESTful Api: REST表述性狀態(tài)傳遞. 一種設(shè)計風格,基于http/https協(xié)議, 把一切接口視為資源, 接口要分版本,在統(tǒng)一的域名下管理, 不同的方法(get/post..)做不同的事,通常請求及響應(yīng)使用json格式
Web Service: SOAP簡單面向?qū)ο髤f(xié)議, 基于http實現(xiàn)的一種RPC方案.接口返回一些對象,可以直接通過操作對象,實現(xiàn)我們需要的業(yè)務(wù)處理.使用xml格式傳輸數(shù)據(jù)
RPC接口: RPC為遠程方法調(diào)用, 有不同的實現(xiàn)方案,基于TCP/Http協(xié)議的都有. RPC可以想我們本地導(dǎo)入和調(diào)用對象一樣使用. Dubbo接口也是一種RPC接口.

常見接口數(shù)據(jù)類型：

請求數(shù)據(jù)類型(Content-Type):application/x-www-form-urlencoded: 常規(guī)只有文本的網(wǎng)頁表單application/json: RESTful Api常用格式, 結(jié)構(gòu)清晰, 含有多層嵌套multipart/form-data: 既有文本,又有上傳文件或富文本框的混合數(shù)據(jù)表單text/xml: xml格式, RPC接口常用格式
響應(yīng)數(shù)據(jù)類型string/html: 返回字符串或網(wǎng)頁源碼json: RESTful Api常用響應(yīng)格式, 結(jié)構(gòu)清晰xml: RPC接口常用格式

常見接口安全驗證方式：

Auth_1.0/Auth_2.0: 通用接口授權(quán)方式
Session依賴: 需要登錄之后才能進行接口操作
Token驗證: 先要使用自己的appid/appsecret通過獲取token接口驗證身份獲取一個token(令牌,有一定有效期), 然后帶著token訪問接口
數(shù)字簽名: 將原本的參數(shù)按一定規(guī)則進行組合,配合時間戳或appsecret, 通過加密算法生成一個簽名sign, 攜帶簽名進行接口請求

常見接口請求方法：

GET: 獲取資源
POST: 修改資源
PUT: 上傳資源
DELETE: 刪除資源
HEAD: 只請求頁面首部
PATCH: 補丁
OPTIONS: 運行客戶端查看服務(wù)器性能
......

常見狀態(tài)碼(RESTful規(guī)范)：

200系: 成功200 OK - [GET]：獲取資源成功201 CREATED - [POST/PUT/PATCH]：創(chuàng)建/修改成功202 Accepted - [*]：任務(wù)接受204 NO CONTENT - [DELETE]：刪除成功
300系: 重定向301 Moved Permanently: 永久重定向302 Found: 臨時重定向
400: 資源錯誤400 INVALID REQUEST - [POST/PUT/PATCH]：用戶請求錯誤401 Unauthorized - [*]：沒有權(quán)限(鑒權(quán)失敗, 接口層)403 Forbidden - [*] 資源禁止訪問(服務(wù)器層,沒有訪問權(quán)限)404 NOT FOUND - [*]：資源不存在405 Method Not Allowd: 訪問的方法不允許, 如用POST訪問只支持GET請求的接口406 Not Acceptable - [GET]：用戶請求的格式不可得(比如用戶請求JSON格式，但是只有XML格式)410 Gone -[GET]：資源被永久刪除422 Unprocesable entity - [POST/PUT/PATCH] 當創(chuàng)建對象時，發(fā)生驗證錯誤
500系: 服務(wù)器內(nèi)部錯誤(接口崩潰或有Bug)500 INTERNAL SERVER ERROR - [*]：服務(wù)器發(fā)生錯誤

接口業(yè)務(wù)類型：

返回數(shù)據(jù)型接口: 只從數(shù)據(jù)庫讀取數(shù)據(jù)
業(yè)務(wù)操作型接口: 需要寫數(shù)據(jù)庫(接口測試需要要涉及參數(shù)化或環(huán)境清理)

快速上手接口測試

獲取接口文檔：

Wiki
Word文檔
Postman導(dǎo)出
抽象接口定義
接口管理平臺

接口文檔分析

功能分析: 是否能滿足業(yè)務(wù)(是否缺少某個前端需要的參數(shù)), 是否能滿足所有業(yè)務(wù)場景(是否有漏開發(fā)接口, 比如只開發(fā)了單品接口,沒開發(fā)套餐接口)
設(shè)計分析: 是否有不規(guī)范字段(如,nickname, passwd);不規(guī)范格式(如sex,用男,女而不是1,2);是否有易混淆字段(如amount和total);是否有單詞拼錯;是否有和數(shù)據(jù)庫字段對應(yīng)但名稱不一樣的(易錯)
接口分析: 協(xié)議類型(http要考慮安全);請求方法(是否規(guī)范);請求編碼格式(表單/Json/xml, 很多接口文檔不聲明,導(dǎo)致測試調(diào)試不通);接口授權(quán)方式;接口業(yè)務(wù)類型(關(guān)系到是否需要做參數(shù)化或環(huán)境清理); 返回值類型及結(jié)構(gòu)(關(guān)系到怎么斷言)
接口依賴: 需要什么環(huán)境準備和業(yè)務(wù)場景, 依賴那些接口, 有那些動態(tài)數(shù)據(jù), 預(yù)備環(huán)境怎么保障
參數(shù)分析: 各個參數(shù)的參數(shù)類型,組成規(guī)則,是否允許不傳,是否可以為空, 是否允許多傳參
業(yè)務(wù)分析: 如price字段必須和數(shù)據(jù)庫中的商品的price字段一致,才能校驗通過
非功能性: 接口的技術(shù)實現(xiàn)方案是否合理, 能否滿足高并發(fā)的性能要求, 邊界值/極限值的處理是否合適, 是否前后端都有數(shù)據(jù)格式校驗等(如精確度為秒級的訂單號生成器,在高并發(fā)下會導(dǎo)致生成同一訂單號的問題)
其他: 如反爬,對headers的一些限制和校驗, ip等限制

編寫接口用例

Excel/TestLink/禪道

單接口用例: 正常數(shù)據(jù)/邊界數(shù)據(jù)/異常數(shù)據(jù)(健壯性)/并發(fā)(一致性)/性能/安全性(抓包截取偽造/SQL注入/跨域請求)
場景用例: 列出常見的用戶場景, 用接口進行覆蓋, 業(yè)務(wù)場景壓測(尋找某個環(huán)節(jié)的性能瓶頸)