第利用python進行接口測試及類型介紹目錄前言接口測試的坑接口類型快速上手接口測試接口文檔分析編寫接口用例執行接口測試

前言

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

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

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

接口測試的坑

第一個坑：

POST和GETGET一般用于獲取/查詢資源信息，而POST一般用于更新資源信息|Get是向服務器發索取數據的一種請求，而Post是向服務器提交數據的一種請求。

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

importurllib2

url_save='/'

try:

s_save=urllib2.urlopen(url_save).read()

prints_save

excepturllib2.HTTPError,e:

printe.code

excepturllib2.URLError,e:

printstr(e)

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

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

defurlopen(url,data=None,timeout=socket._GLOBAL_DEFAULT_TIMEOUT,

cafile=None,capath=None,cadefault=False,context=None):

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

importurllib

importurllib2

url=''

#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獲取到了

printcookie_use

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

'''

將獲取到的cookie綁定到opener，上一步獲取的cookie并不滿足如下格式，

需要自己進行字符串的切片和拼接

opener.addheaders.append(('Cookie','name=***888=888'))

現在的opener就可以用來訪問任意需要登錄的網站了！

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

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

接口類型

常見接口種類：

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

常見接口數據類型：

請求數據類型(Content-Type):application/x-www-form-urlencoded:常規只有文本的網頁表單application/json:RESTfulApi常用格式,結構清晰,含有多層嵌套multipart/form-data:既有文本,又有上傳文件或富文本框的混合數據表單text/xml:xml格式,RPC接口常用格式響應數據類型string/html:返回字符串或網頁源碼json:RESTfulApi常用響應格式,結構清晰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系:成功200OK-[GET]：獲取資源成功201CREATED-[POST/PUT/PATCH]：創建/修改成功202Accepted-[*]：任務接受204NOCONTENT-[DELETE]：刪除成功300系:重定向301MovedPermanently:永久重定向302Found:臨時重定向400:資源錯誤400INVALIDREQUEST-[POST/PUT/PATCH]：用戶請求錯誤401Unauthorized-[*]：沒有權限(鑒權失敗,接口層)403Forbidden-[*]資源禁止訪問(服務器層,沒有訪問權限)404NOTFOUND-[*]：資源不存在405MethodNotAllowd:訪問的方法不允許,如用POST訪問只支持GET請求的接口406NotAcceptable-[GET]：用戶請求的格式不可得(比如用戶請求JSON格式，但是只有XML格式)410Gone-[GET]：資源被永久刪除422Unprocesableentity-[POST/PUT/PATCH]當創建對象時，發生驗證錯誤500系:服務器內部錯誤(接口崩潰或有Bug)500INTERNALSERVERERROR-[*]：服務器發生錯誤

接口業務類型：

返回數據型接口:只從數據庫讀取數據業務操作型接口:需要寫數據庫(接口測試需要要涉及參數化或環境清理)

快速上手接口測試

獲取接口文檔：

WikiWord文檔Postman導出抽象接口定義接口管理平臺

接口文檔分析

功能分析:是否能滿足業務(是否缺少某個前端需要的參數),是否能滿足所有業務場景(是否有漏開發接口,比如只開發了單品接口,沒開發套餐接口)設計分析:是否有不規范字段(如,nickname,passwd);不規范格式(如sex,用男,女而不是1,2);是否有易混淆字段(如amount和total);是否有單詞拼錯;是否有和數據庫字段對應但名稱不一樣的(易錯)接口分析:協議類型(http要考慮安全);請求方法(是否規范);請求編碼格式(表單/Json/xml,很多接口文檔不聲明,導致測試調試不通);接口授權方式;接口業務類型(關系到是否需要做參數化或環境清理);返回值類型及結構(關系到怎么斷言)接口依賴:需要什么環境準備和業務場景,依賴那些接口,有那些動態數據,預備環境怎么保障參數分析:各個參數的參數類型,組成規則,是否允許不傳,是否可以為空,是否允許多傳參業務分析:如price字段必須和數據庫中的商品的price字段一致,才能校驗通過非功能性:接口的技術實現方案是否合理,能否滿足高并發的性能要求,邊界值/極限值的處理是否合適,是否前后端都有數據格式校