利用python進行介面測試及型別介紹

2022-05-19 13:00:23

前言

其實我覺得介面測試很簡單，比一般的功能測試還簡單（這話我先這樣說，以後可能會刪O(∩_∩)O哈！），現在找工作好多公司都要求有介面測試經驗，也有好多人問我（也就兩三個人）什麼是介面測試，本著不懂也要裝懂的態度，我會說：所謂介面測試就是通過測試不同情況下的入參與之相應的出參資訊來判斷介面是否符合或滿足相應的功能性、安全性要求。

我為啥說介面測試比功能測試簡單呢，因為功能測試是從頁面輸入值，然後通過點選按鈕或連結等傳值給後端，而且功能測試還要測UI、前端互動等功能，但介面測試沒有頁面，它是通過介面規範檔案上的呼叫地址、請求引數，拼接報文，然後傳送請求，檢查返回結果，所以它只需測入參和出參就行了，相對來說簡單了不少。

正好最近在做介面測試，之前公司的方案是使用postman進行介面測試。但是偉大的牆導致我們只能用離線版postman。。然後一個很長很長的介面列表，一個接一個的存取。我的天哪。。所以萌生了一個想法，使用python編寫一套介面測試指令碼，設定介面列表，然後逐條存取，輸出紀錄檔。

介面測試的坑

第一個坑：

POST 和 GET----GET一般用於獲取/查詢資源資訊，而POST一般用於更新資源資訊|Get是向伺服器發索取資料的一種請求，而Post是向伺服器提交資料的一種請求。

做過介面測試或者做過前端的人都知道，介面的存取方式是不一致的，所以才會使用postman來進行介面測試，因為它可以設定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請求，呼叫urllib2庫，然後將一個字串形式的URL傳給urllib2.urlopen函數，最後使用read（）方法將GET回來的資料儲存起來。

然後說說POST。其實在python的urllib2庫中，我們剛剛所使用的urlopen函數還有其他幾樣不是必選的入參，因為這些入參給定了初始化的值：

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函數對values字典進行處理，最終形式為：**=***&**=***
data = urllib.urlencode(values) 
#如果對data順序有要求，建議自己拼接data
req = urllib2.Request(url, data) 
response = urllib2.urlopen(req) 
the_page = response.read()

就像如上程式碼，把POST方式所需要的資料寫到data引數中去，POST方式就模擬成功了。

第二個坑：cookie的使用

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

# 這裡有四種CookieJar，CookieJar是最原始的
cookie_use = cookielib.CookieJar()
 handler = urllib2.HTTPCookieProcessor(cookie_use)
 # 使用繫結好CookieJar的handler建立一個opener
 opener = urllib2.build_opener(handler)
 # 將opener安裝到urllib2中
 urllib2.install_opener(opener)
# 使用安裝好的urllib2存取某一網站獲取cookie
 urllib2.urlopen('https://....../login')
 #這個時候cookie已經被CookieJar獲取到了
 print cookie_use

在下一步，將獲取到的cookie繫結到opener頭中：

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

現在的opener就可以用來存取任意需要登入的網站了！

功能:功能實現,實現與設計一致, 介面通過性測試

健壯性: 邊界值,容錯性
效能: 並行及壓測
穩定性: 長期執行的穩定性
安全性: SQL隱碼攻擊, session依賴, 數位簽章, http介面的安全性

介面型別

常見介面種類：

Http/Https介面: 通過http/https協定傳送介面資料(通常按字串/二進位制傳輸), 如常見的網頁表單, https安全性更好
RESTful Api: REST表述性狀態傳遞. 一種設計風格,基於http/https協定, 把一切介面視為資源, 介面要分版本,在統一的域名下管理, 不同的方法(get/post..)做不同的事,通常請求及響應使用json格式
Web Service: SOAP簡單物件導向協定, 基於http實現的一種RPC方案.介面返回一些物件,可以直接通過操作物件,實現我們需要的業務處理.使用xml格式傳輸資料
RPC介面: RPC為遠端方法呼叫, 有不同的實現方案,基於TCP/Http協定的都有. RPC可以想我們本地匯入和呼叫物件一樣使用. Dubbo介面也是一種RPC介面.

常見介面資料型別：

請求資料型別(Content-Type):application/x-www-form-urlencoded: 常規只有文字的網頁表單application/json: RESTful Api常用格式, 結構清晰, 含有多層巢狀multipart/form-data: 既有文字,又有上傳檔案或富文字方塊的混合資料表單text/xml: xml格式, RPC介面常用格式
響應資料型別string/html: 返回字串或網頁原始碼json: RESTful Api常用響應格式, 結構清晰xml: RPC介面常用格式

常見介面安全驗證方式：

Auth_1.0/Auth_2.0: 通用介面授權方式
Session依賴: 需要登入之後才能進行介面操作
Token驗證: 先要使用自己的appid/appsecret通過獲取token介面驗證身份獲取一個token(令牌,有一定有效期), 然後帶著token存取介面
數位簽章: 將原本的引數按一定規則進行組合,配合時間戳或appsecret, 通過加密演演算法生成一個簽名sign, 攜帶簽名進行介面請求

常見介面請求方法：

GET: 獲取資源
POST: 修改資源
PUT: 上傳資源
DELETE: 刪除資源
HEAD: 只請求頁面首部
PATCH: 修補程式
OPTIONS: 執行使用者端檢視伺服器效能
......

常見狀態碼(RESTful規範)：

200系: 成功200 OK - [GET]：獲取資源成功201 CREATED - [POST/PUT/PATCH]：建立/修改成功202 Accepted - [*]：任務接受204 NO CONTENT - [DELETE]：刪除成功
300系: 重定向301 Moved Permanently: 永久重定向302 Found: 臨時重定向
400: 資源錯誤400 INVALID REQUEST - [POST/PUT/PATCH]：使用者請求錯誤401 Unauthorized - [*]：沒有許可權(鑑權失敗, 介面層)403 Forbidden - [*] 資源禁止存取(伺服器層,沒有存取許可權)404 NOT FOUND - [*]：資源不存在405 Method Not Allowd: 存取的方法不允許, 如用POST存取只支援GET請求的介面406 Not Acceptable - [GET]：使用者請求的格式不可得(比如使用者請求JSON格式，但是隻有XML格式)410 Gone -[GET]：資源被永久刪除422 Unprocesable entity - [POST/PUT/PATCH] 當建立物件時，發生驗證錯誤
500系: 伺服器內部錯誤(介面崩潰或有Bug)500 INTERNAL SERVER ERROR - [*]：伺服器發生錯誤

介面業務型別：

返回資料型介面: 只從資料庫讀取資料
業務操作型介面: 需要寫資料庫(介面測試需要要涉及引數化或環境清理)

快速上手介面測試

獲取介面檔案：

Wiki
Word檔案
Postman匯出
抽象介面定義
介面管理平臺

介面檔案分析

功能分析: 是否能滿足業務(是否缺少某個前端需要的引數), 是否能滿足所有業務場景(是否有漏開發介面, 比如只開發了單品介面,沒開發套餐介面)
設計分析: 是否有不規範欄位(如,nickname, passwd);不規範格式(如sex,用男,女而不是1,2);是否有易混淆欄位(如amount和total);是否有單詞拼錯;是否有和資料庫欄位對應但名稱不一樣的(易錯)
介面分析: 協定型別(http要考慮安全);請求方法(是否規範);請求編碼格式(表單/Json/xml, 很多介面檔案不宣告,導致測試偵錯不通);介面授權方式;介面業務型別(關係到是否需要做引數化或環境清理); 返回值型別及結構(關係到怎麼斷言)
介面依賴: 需要什麼環境準備和業務場景, 依賴那些介面, 有那些動態資料, 預備環境怎麼保障
引數分析: 各個引數的引數型別,組成規則,是否允許不傳,是否可以為空, 是否允許多傳參
業務分析: 如price欄位必須和資料庫中的商品的price欄位一致,才能校驗通過
非功能性: 介面的技術實現方案是否合理, 能否滿足高並行的效能要求, 邊界值/極限值的處理是否合適, 是否前後端都有資料格式校驗等(如精確度為秒級的訂單號生成器,在高並行下會導致生成同一訂單號的問題)
其他: 如反爬,對headers的一些限制和校驗, ip等限制