當你準備使用乙個介面自動化測試框架或者自造輪子的時候，或許你需要先了解下乙個介面自動化測試框架必須具備什麼功能。
1、校驗
這個很好了解，如果沒有校驗，單純的執行介面的話，那就談不上測試了。所以支援對返回值校驗是乙個必須的功能。
2、資料隔離
資料隔離就是指具體的請求介面、引數、校驗等資料做到與**相隔離，便於維護，一旦需要調整介面用例、新增介面用例時可很快速的找到位置，隔離的另乙個好處就是可復用，框架可以推廣給其他團隊，使用者可以使用相同的**，只需要根據要求填寫各自用例即可測試起來。
3、資料傳遞
做到資料隔離可維護後，資料傳遞是另外乙個更重要的需求。
資料傳遞是指介面用例之間可以做到向下傳參，例如我們通過建立訂單介面建立乙個訂單，該介面會返回乙個訂單號，接下來我們要進行呼叫查詢訂單的介面，從返回的資料中與建立訂單用例中的資料進行校驗，此時第二個介面的請求資料是需要從第乙個介面用例中的返回中提取的。這樣的例子比比皆是，所以支援資料傳遞是又乙個必不可少的功能。
4、動態函式
實際用例場景中我們可能會有隨機生成乙個手機號、字串加密等需求，在資料與**隔離之後，此時我們就需要**可以支援做到識別對應關鍵字時可以執行對應的函式進行填充。例如在資料中填寫phone()時，具體執行時會被替換成137******xx，填寫random(5)時，會被替換成乙個五位的隨機數。等等。
5、可配置
有時，我們的需求是用例不單單只能在乙個環境上執行，可能需要同乙份介面用例可以在qa、預發、線上等多個環境都可以執行。所以框架需要做到可配置，便於切換，呼叫不同的配置檔案可以在不同的環境執行。
6、日誌
日誌包含執行的具體執行介面、請求方式、請求引數、返回值、校驗介面、請求時間、耗時等關鍵資訊，日誌的好處一來是可以便於在新增用例有問題時快速定位出**填寫有問題，二來是發現bug時方便向開發反饋提供資料，開發可以從觸發時間以及引數等資訊快速定位到問題所在。
7、視覺化報告
用例執行後，就是到了向團隊展示結果的時候了，乙個視覺化的報告可以便於團隊成員了解到每次自動化介面用例執行的成功數、失敗數等資料。
8、用例驅動
1.用例的驅動模式，涉及到怎麼存放測試資料，怎麼描述用例，又如何復用；
2.考慮到效率的話還要支援併發；
3.當然測試報告不能光記錄成功和失敗，還有用例執行耗時，介面呼叫耗時，、場景的通過率等各項數值的統計。
9、資料隔離
1.用例是否能復用應該跟用例的設計有關係，跟框架關係不是很大。
2.併發的話在介面自動化方面倒不是必須的，當然有是更完美的。
3.報告確實是越強大越好，有老闆關心的資料，有開發關心的資料是最好不過了。
下面福利來了
介面測試自動化框架彙總
前兩篇文章我們介紹了如何使用postman和curl手工執行介面測試用例，不過如果專案需要長期開發和維護的話，我們就需要開始考慮自動化測試了。自動化測試第一步就是框架選型。所以本篇將介紹目前主流的介面測試框架，以及它們各自的優缺點。名稱優點 缺點官網 postman newman 介面操作，容易上手...
介面自動化測試框架python requests
介面封裝 將介面封裝成物件，類似pageobject封裝 資料封裝 資料與 分離，資料存放在yaml檔案中 配置檔案 實現全域性配置 utils 其他功能封裝 測試用例 呼叫介面物件實現業務並斷言 requests pytest allure等 base api.py import requests...
Python介面自動化測試框架
2.建立基本的專案框架目錄 common存放常用工具檔案 my requests.py封裝自己的常用請求庫 my logger.py自己封裝的日誌模組 file handler.py資料檔案解析 test cases存放自動化測試 test data存放所有的測試資料 venv建立虛擬環境自動生成的...