介面自動化測試--框架設計思路

• 2019 年 11 月 7 日
• 筆記

介面自動化測試--框架設計思路

1

前言

之前文章跟大家分享了一下自己在介面自動化測試中進行測試準備的一些相關知識點，接下來本篇文章詳細分享一下介面自動化框架設計的思路總結，希望能對初次探索介面自動化測試的小夥伴們有一些思路上的幫助。

小編是以python+requests+unittest

+HTMLTestRunner為基礎進行的介面自動化探索，下面結合介面測試的測試點介紹一下整個框架的搭建思路：

我們知道介面測試本質是對數據的測試，調用介面，輸入一些數據，隨後，介面返回一些數據，最後驗證介面返回數據的正確性。

2

基礎

首先要理清楚進行介面測試需要了解的內容：

1、介面文檔

a.介面協議--基於http協議的介面

b.介面域名--XXX.XX.XX

c.介面請求類型--業務中只涉及到get和post類型，其中又包含認證校驗機制

d.介面參數

e.介面的返回--包含http狀態碼、業務狀態碼、實際業務邏輯對應的返回內容

2、 介面內部邏輯

a.介面內部邏輯對應的資料庫及redis的操作（增刪改查）

3、自動校驗的結果

4、測試結果的展示

5、必要的解釋說明

a.文檔

b.注釋

3

具體內容

小編在選擇介面請求參數分離方式時對csv、excel、xml進行了對比，最終選擇xml格式。

由於excel或csv格式需要維護一組測試case和參數對應關係，每次增刪改case會需要同時修改excel或csv中對應的內容，而xml格式可以根據功能模組及介面設計參數文件的結構目錄，無需再對介面case和對應的參數進行對應修改，所以選擇了借鑒使用友組項目中介面自動化框架，也使用xml獲取參數的模式，項目結構具體如下：

整個框架思路說明：

一、最開始就需要建立一個readme文檔，即doc目錄可以對框架進行整體的說明、寫case具體的思路說明等。

二、既然是通過程式碼的形式進行自動化測試，就有可能會出現編寫過程中的問題調試，所以需要有對應的log目錄，即logs目錄。便於case執行失敗後進行問題定位

三、請求參數、按功能模組，根據開發給的的文檔，以xml文件的格式對每個介面進行添加，如datafile/input/模組名/介面名 ，及對整個所有介面參數進行檢索的interface.xml

四、公共api封裝，在進行介面測試前通過文檔我們可以知道請求域名、請求方法、公共請求參數（xml保存默認參數）、業務邏輯需要用的介面的公共參數等，可以對這些內容進行封裝，如src/common/request_interface.py

包含對介面請求的封裝，將其封裝成通用的，這樣可以滿足業務所需要的get和post兩種請求。大家可以自行根據自己業務請求的特點結合request庫提供的方法進行封裝。

如src/common/constant.py包含對域名、某一功能模組參數內容格式化獲取、url獲取、介面鑒別用戶方法等（此處不做展示）

由於業務特點，對介面進行請求前可能需要構造某一種返回邏輯的測試環境，如模擬新用戶功能，測試帳號名是手機號於已經註冊但又沒有那麼手機號可供每次作為新用戶進行註冊，這就需要將資料庫中的需要對資料庫或redis進行刪除，從而實現新用戶的模擬，其中src/common/db_manager.py和src/common/redis_manager.py分別對兩者增刪改查方法的封裝，這時它們就起到了關鍵作用（大家可以自行搜狗，根據自己的風格編寫）

當然，根據需要，也可增加其他可以使用的公共api介面，如針對php語言特點對返回的數據進行計算封裝的src/common/calculate.py

五、每個功能模組的公共部分及所有介面用例執行入口，如crazy介面的公共功能部分src/activity/crazy及測試用例run_activity_crazy.py，及all_interfaces.py

以上介面用例的編寫，對介面業務邏輯根據自己的需要進行編寫，結果展示可以藉助HTMLTestRunner，網上也有很多示例，可自行搜狗

4

結束語

好了以上就是今天要分享的內容，之後敬請關注介面自動化--編寫過程中遇到的問題總結，下次見！