python 基於unittest寫介面自動化指令碼

二、核心**

三、報告

四、後言

unittest用例管理、提供執行器、擴充套件可能性。

其實不用unittest思路也是一樣的。

遵循unittest格式

定義乙個合法引數集，用例種去deepcopy這個值進行修改

編寫tool類來實現引數化。

--api #介面封裝類

--request_api 請求類封裝

--response 響應類封裝

--db #mysql redis等操作方法

--log #日誌

--opt #定製化操作，登入等操作

--tool #生成隨機資料、假資料、查驗證碼、修改資料等操作

config

--domain #存放請求網域名稱

--setting #存放各項配置

request

--... #按專案分類存放各種介面的資訊

testcase

--... #按專案分類存放各種測試資料

定義乙個api類，存放請求響應斷言等等資訊，使用request庫進行請求

引數化**，資料不想寫死，就呼叫這裡的方法來生成

目前還沒實現，只是用日誌方式存下了請求會話。

報告的話，設想的還是和之前的文章一樣，用markdown + mkdocs實現

之所以一開始沒寫報告是因為時間很緊，而我發現我也不需要去看報告。編寫完就執行，bugfix後就回歸，都是能實時看到結果的。不得不說這個系統幫了我大忙，上線後需求又改了。僅改了下斷言花了十分鐘就全面回歸了這個版本的測試用例。

目前還沒有報告模組、郵件通知模組。因為當時時間很緊，新公司現有框架不滿足老業務的資料生成，就用python來實現了。

有公司規劃的介面測試1.0 2.0 3.0來實現介面測試的普及，加上web頁面，加上各種元件來維護用例。包括我前面寫的讀ini來執行用例，我覺得還是價效比太低。

我認為更好的ui介面，重複的造輪子並不能解決現在測試現有的痛點。我原來是喜歡用jmeter實現介面測試的，而現在的介面原來越複雜，請求與響應的json格式多達三四層。jmeter就不太適用了。寫用例所用到的**能力其實並不高。寫用例最重要的不是工具，還是編寫者的思路。

而專門組建團隊花時間來寫用於回歸的測試用例，在我看來價效比也不高。跟隨專案版本，每個測試都參與編寫介面測試用例才是最有效率、有效果的方式。