如果介面測試僅僅只是掌握一些requests或者其他一些功能強大的庫的用法,是遠遠不夠的,還需要具有根據公司的業務以及需求去定製化乙個介面自動化測試框架能力。所以在這個部分,會主要介紹介面測試用例分析以及通用的流程封裝是如何完成的。
** 介面測試用例分析**
首先在做用例分析之前,可以通過追查公司一年來所有的故障原因,定位問題起因,或者通過與cto、產品經理、研發、運維、測試調查,得到質量痛點,還可以分析業務架構、流程呼叫,以及監控系統了解到業務的使用資料,從而得到
質量需求。
得到質量需求之後,通過與產品經理、專案經理、研發總監等對接後得知待測業務範圍、業務場景用例、業務介面分析,從而確定公司的測試計畫。將測試計畫與質量需求結合進行分析,就可以開始進行業務用例的設計,而介面測試用例分析,也在其內。
質量需求
樣例測試痛點
公司的介面一直不穩定影響使用者的使用
質量反饋
最近半年來出現了幾次大的故障
回歸測試
每次公升級都會影響老的功能
測試策略
目前公司沒有可靠的測試體系
重構測試
微服務化改造需要有良好的測試體系保證
介面測試封裝思想
介面封裝思想主要分為3個大維度,配置、介面封裝、業務流程。其中配置主要用作根據配置檔案獲取初始配置和依賴;介面封裝
遵循apiobject設計模式,對介面的呼叫進行抽象封裝;業務流程
則負責資料初始化、業務用例設計,包含有多個api形成的流程定義,不要再包含任何介面實現細節、以及斷言。後面將會與實戰案例結合,進行詳細的介紹。
** 基於加密介面的測試用例設計**
由於資訊保安的原因,許多的介面在傳輸的時候會對請求與響應進行加密處理,如果直接對這部分資料做斷言顯然是行不通的。還需要對這部分介面額外進行解密的處理之後,才可以對已解密的介面進行斷言。
環境準備
在進行實戰之前,需要先準備乙個對響應加密的介面。對它發起乙個get請求後,得到乙個加密過後的響應資訊。
先準備乙個json格式demo
}
使用base64對其做加密,得到乙個加密後的檔案demo64.txt
base64 demo.json >demo64.txt
使用python命令在「demo64.txt」所在目錄啟動乙個服務
python -m http.server 10000
啟動後的樣子如圖:
使用curl命令對這個服務進行get請求
curl
如果請求成功的話就代表環境已經準備成功
** 實戰練***
呼叫base64,直接對返回的請求做解密,即可得到解密後的響應,將解密後的響應轉為json格式,此時就可以對這個返回值做斷言且不會報錯了
import base64import jsonimport requestsclass testencode: url = "" def test_encode(self): r = requests.get(self.url) encode = json.loads(base64.b64decode(r.content)) assert encode["topics"]["president"] == "seveniruby"
這樣的寫法顯然不夠優雅,如果被測介面的協議發生變化,requests庫無法支援改變後的協議,需要呼叫別的第三庫傳送請求資訊,則還是需要修改底層的原始碼。碰到這種情況,可以增加一層封裝,構造一層更加通用的傳送方法。
首先需要通過乙個字典的結構體,儲存所有的請求資訊,包括傳送的協議、解碼方式、請求method等等,而這種字典形式的結構體也為後面的資料驅動改造做好了乙個重要的鋪墊。
req_data=
通過請求資訊的結構體中的schema,新增判斷條件,去選擇不同的請求協議。舉個例子,如果schema為「http」的話,就選擇呼叫被封裝的requests庫。
class apirequest: #構造send方法,通過 def send(self, data: dict): if "http" == data["schema"] : res = requests.request( data["method"],data["url"],header=data["headers"]) return json.loads(base64.decode(res.content)) elif "dubbo" == data["schema"]: pass elif "websocket" == data["schema"]: pass else: pass
呼叫在apirequest類中的send方法傳送請求並進行斷言
class testencode: def test_api(self): req_data= re = apirequest() data = re.send(req_data) assert data["topics"]["president"] == "seveniruby"
如果面對不同的演算法,還需要修改底層的原始碼,所以需要把演算法封裝。需要使用哪個演算法,就使用哪個。封裝的思想與上面相同。首先在字典結構體中新增乙個encoding欄位,用來判斷選擇的不同的加密條件
req_data=
還是通過請求資訊的結構體中的encoding,新增判斷條件,去選擇不同的解密方式。
class apirequest: def send(self, data: dict): if "http" == data["schema"] : res = requests.request( data["method"],data["url"],headers=data["headers"]) return json.loads(base64.b64decode(res.content)) #通過請求資訊的結構體中的`encoding`,去選擇不同的解密方式。 if data["encoding"] == "base64": return json.loads(base64.b64decode(res.content)) elif data["encoding"] == "private": return json.loads( requests.post("url", data=res.content).content) else: return json.loads(res.content)
總結:
首先需要明確在面對乙個加密的響應結果,可以使用什麼樣的處理方式:
如果知道使用的是哪個通用加密演算法的話,可以自行解決。
如果不了解對應的加密演算法的話,可以讓研發提供加解密的lib。
如果既不是通用加密演算法、研發也無法提供加解密的lib的話,可以讓加密方提供遠端解析服務,這樣演算法仍然是保密的。
本篇文章主要提供的就是在了解使用加密演算法的情況下,如何處理這樣的解密演算法。但是封裝的思路都是相通的,不管是面對哪種情況,都可以通過格式化的資料,指明資料的內容,並通過一層邏輯的封裝,將加解密或者選擇的協議封裝進去。
點選獲取更多資訊
介面測試實戰專案03 根據測試用例測試
上三次,我們已經了解 測試奇譚 什麼是介面測試?這篇文章讓你明白 測試奇譚 介面測試實戰專案01 介面測試環境搭建 測試奇譚 介面測試實戰專案02 根據介面文件測試 這次,我們開始按照測試用例進行介面測試。在測試之前,我先說一點 此套專案提供了乙份完整的測試用例,但如果你想掌握介面測試技能,建議你先...
介面加密測試
一般介面開發中有以下常用的幾種安全機制 使用者認證 一般的介面測試工具都會提供乙個user auth authorization的選項,以postman為例子,你可以看到以下的選項 在使用 http soap 協議傳輸資料的時候,簽名作為其中乙個引數,可以起到關鍵作用 先來乙個簡單的,通過客戶的金鑰...
WEB測試 使用者介面測試
如果有設計稿,當然按照設計稿進行測試 沒有設計稿,就參考原型 如果都沒有,就按照web大眾排版設計要求測試了,當然,還是要產品看過為準。一下簡單總結一下測試的點。1.導航測試 很少有使用者願意花時間去熟悉web應用系統的結構,因此,web應用系統導航幫助要盡可能地準確。測試點 2.圖形 多 測試 w...