python 基於unittest寫接口自動化腳本
一、項目介紹
unittest用例管理、提供執行器、擴展可能性。
其實不用unittest思路也是一樣的。
1. 測試用例與執行結果
- 遵循unittest格式
- 定義一個合法參數集，用例種去deepcopy這個值進行修改
- 編寫Tool類來實現參數化。
2. 項目目錄
common
--api #接口封裝類
--request_api 請求類封裝
--response 響應類封裝
--db #mysql redis等操作方法
--log #日誌
--opt #定製化操作，登錄等操作
--tool #生成隨機數據、假數據、查驗證碼、修改數據等操作
config
--domain #存放請求域名
--setting #存放各項配置
request
--... #按項目分類存放各種接口的信息
testcase
--... #按項目分類存放各種測試數據
二、核心代碼
1. request_api.py
定義一個api類，存放請求響應斷言等等信息，使用request庫進行請求
2. tool.py
參數化來源，數據不想寫死，就調用這裏的方法來生成
3. 某個接口的request文件
4. 某個接口的testcase文件
三、報告
1. Web報告
目前還沒實現，只是用日誌方式存下了請求會話。
報告的話，設想的還是和之前的文章一樣，用markdown + mkdocs實現
四、後言
1. 生產力還是花瓶？
之所以一開始沒寫報告是因爲時間很緊，而我發現我也不需要去看報告。編寫完就執行，bugfix後就回歸，都是能實時看到結果的。不得不說這個系統幫了我大忙，上線後需求又改了。僅改了下斷言花了十分鐘就全面迴歸了這個版本的測試用例。
2. 擴展
目前還沒有報告模塊、郵件通知模塊。因爲當時時間很緊，新公司現有框架不滿足老業務的數據生成，就用python來實現了。
3. 感悟
有公司規劃的接口測試1.0 2.0 3.0來實現接口測試的普及，加上Web頁面，加上各種組件來維護用例。包括我前面寫的讀ini來執行用例，我覺得還是性價比太低。
我認爲更好的UI界面，重複的造輪子並不能解決現在測試現有的痛點。我原來是喜歡用JMeter實現接口測試的，而現在的接口原來越複雜，請求與響應的json格式多達三四層。JMeter就不太適用了。寫用例所用到的代碼能力其實並不高。寫用例最重要的不是工具，還是編寫者的思路。
而專門組建團隊花時間來寫用於迴歸的測試用例，在我看來性價比也不高。跟隨項目版本，每個測試都參與編寫接口測試用例纔是最有效率、有效果的方式。