一、前言
自動化測試是把将手工驅動的測試行為轉化為機器自動執行，通常操作是在某一架構下進行代碼編寫，實作用例自動發現與執行，托管在CI/CD平台上，通過條件觸發或手工觸發，進行回歸測試&線上監控，代替部分的手工測試；
不同的項目适合的自動化架構也是不同的，自動化系列文章将逐個介紹實際工作中使用的自動化架構。
自動化接口測試使用到的架構：
- Postman+Newman+Allure+Jenkins/極庫雲
- Httprunner+Request+Pytest+Alluret+Jenkins
- JMeter+Ant+Allure+Jenkins
- Pytest+Request+Allure+Jenkins
自動化UI測試使用到的架構：
- Selenium+Pytest
- Appium+WDA+TestNG
- Minium+pytest
本章節先對自動化接口測試的四個架構進行對比介紹，後續系列文章介紹詳細搭建過程和封裝過程。
二、自動化接口測試簡介
1、接口測試的必要性
接口測試有着極為高效的成本收益比，是測試左移的重要環節。
接口測試為高複雜性的平台帶來高效的缺陷檢測和品質監督能力，平台複雜，系統越龐大，接口測試的效果越明顯。
總的來說，接口測試是保證高複雜性系統品質的内在要求和低成本的經濟利益驅動作用下的最佳方案，主要展現在如下三個方面：
- 節省了測試成本
- 接口測試不同于單元測試
- 收益更高
2、自動化接口測試的必要性
自動化測試是把以人為驅動的測試行為轉化為機器執行的一種過程，主要是編寫代碼、腳本，讓軟體自動運作，發現缺陷，代替部分的手工測試；
當服務端改動功能、添加新功能時、測試環境切換時、新釋出程式後，避免新代碼導緻已有功能不可用，都需要進行接口的全量回歸。人工觸發不及時且容易遺漏。
接口自動化接入持續內建，服務端釋出觸發接口測試代碼運作，盡早發現問題
抽取部分接口測試用例，定時運作程式，對線上常用的業務操作進行監控，及時發現修複。
3、自動化接口測試适用場景
- 提測前冒煙測試
- 預生産/上線前回歸測試
- 服務端底層邏輯變更後的回歸測試
- 線上伺服器可用性監控
4、成果物
通過自動化測試，進行線上可用性監控 和 回歸測試，可以節約大量手工測試時間，降本增效。線上線下均發現過較多問題。
三、自動化接口測試架構概覽
1、幾種架構對比
還有很多其他架構，本次隻針對實際工作中應用到的幾種架構進行對比。
2、自動化接口測試架構的必要性
- 提供統一的用例模闆，簡化業務接入的成本
- 處理腳本中一些異常和錯誤處理工作
- 實作一些通用的功能，簡化腳本開發的過程
- 測試場景恢複
- 測試結果/報告輸出
四、自動化接口測試架構對比
1、Postman+Newman架構
①簡介
postman是谷歌浏覽器的擴充工具，也有獨立的用戶端産品。
postman非友善日常的調試，使用簡單。
主要功能包含接口請求的發起，測試的斷言，設定前置條件，支援後置操作，支援使用全局變量/環境變量/集合變量/内部變量，參數化應用、接口關聯、postman結合newman+jenkins實作簡單的接口自動化并進行持續內建等操作。
postman進階的功能可以付費進行定制化。
②優缺點
優點:
- 免費版就已經非常強大了，門檻低，上手快，跨平台
- 使用門檻低，隻需要簡單的程式設計能力，一些複雜的斷言可能需要了解js文法;
- 支援不同的認證機制，包括Basic Auth、Digest Auth、OAuth1.0、OAuth2.0
- 可以發送大多數類型的HTTP/HTTPS請求，如GET、POST、PUT、PATCH、DELETE、 TRACE等；
- 支援資料驅動，讀取資料檔案,json,csv
- 支援設定環境變量：友善切換不同的環境進行接口測試工作，而不用修改變量或代碼；（同一套測試用例，可以通過切換環境變量運作在不同的環境中，如生産環境/預釋出/測試環境）
- 無重複工作量，接口測試的case可以直接導出形成測試用例；
- 接口測試轉換成自動化case非常友善，運作也比較簡單;
- postman是google維護，可靠;
缺點:
- 僅支援Node.js語言，而js不具有通用性；
- 不能操作檔案相關的操作，不能讀寫資料庫，不能使用非HTTP協定
- 不支援配置測試用例優先級、測試用例分組功能，隻能按順序執行；
- 測試用例中動态資料/測試準備功能/測試斷言都必須提前定義好，不能滿足所有場景的要 求(如資料庫互動) ;
- 測試用例是json格式，查閱、維護及更改都十分不變；
- 測試用例維護成本高，當有變更時，需要再次導入到newman工程中；
- 架構的擴充性差，postman的CI內建以及擴充封裝都需要單獨的開發新的項目相容post man本生的架構語言
- 不支援運作時動态傳入環境變量
- 不支援失敗重試
- 僅适合業務邏輯不複雜的小型項目
③使用要求
- 對http協定有基本的了解
- 了解接口測試概念
- 工具的基本使用
- 請求頭，請求體能厘清即可
④适用業務
- 業務中接口量大
- 業務場景獨立，關聯關系弱
- 小型API項目的自動化
- 短期項目的API回歸測試
- 編碼能力較弱的測試團隊或初學者
⑤環境依賴
- 需要 Node.js 執行環境
- 需要安裝newman ，npm install -g newman
- 安裝用到的插件，如htmlextra，allure等
⑥應用步驟
a.用例要求：接口用例中做了較完善的接口管理、全局變量/環境變量定義、動态參數應用、請求參數化、實作了接口關聯、所有的接口均有狀态/性能斷言+業務斷言
b.生成項目：導出接口測試用例、環境變量、全局變量、資料驅動檔案等
c.配置項目：架構單獨章節再行介紹具體配置過程
運作項目
- 本地使用CLI執行自動化
- 配置到jenkins job中
d.檢視報告 （其他架構都是使用Allure輸出報告，不再贅述）
代碼上傳gitlab/github
e.接入持續內建，并配置定時任務（其他架構都支援通過極庫雲或jenkins做任務排程，不再贅述）
- 接入極庫雲流水線
- 接入 Jenkins
2、JMeter+Ant架構
①簡介
JMeter可以用于性能測試，在性能測方面很強大，也可以用于自動化接口測試。
②優缺點
優點：
- 支援參數化
- 不需要寫代碼
- 支援協定較多，如HTTP、FTP、soap、websocket、jdbc、thrift、dubbo等
- 支援資料庫操作
缺點：
- 建立接口用例效率不高
- 學習成本高
- 需要會jmeter工具的基本使用
- 會資料庫基本操作及編寫SQL語句
- 了解用到的非http協定，如項目【自研長連接配接】使用的websocket協定
③使用要求
jmeter的學習成本主要在jmeter工具的使用上
對于已經掌握工具使用的人，利用jmeter進行自動化測試隻要會Ant配置即可
④适用業務
涉及資料庫操作
涉及非https接口的業務
業務需要進行性能測試，已完成主要接口腳本編寫
⑤環境依賴
不同版本JMeter對Java版本的要求不盡相同。比如：JMeter3.3僅支援Java 8，
JMeter4.0要求Java 8+（表示大于等于Java 8版本），JMeter5.0以上要求Java 8+
安裝ant插件
⑥應用步驟
- 用例要求：接口用例中做了較完善的接口管理、恰當的元件使用、動态參數應用、請求參數化、實作了接口關聯、所有的接口均有狀态斷言+業務斷言
- 生成項目：編寫測試用例、導出測試用例，資料驅動檔案等
- 配置Ant 的 build.xml檔案
- 運作項目
- 本地使用ant執行自動化
- 配置到jenkins job中
3、HttpRunner+request
①簡介
HttpRunner 是一款面向 HTTP(S) 協定的通用測試架構，隻需編寫維護一份 YAML/JSON 腳本，即可實作自動化測試、性能測試、線上監控、持續內建等多種測試需求。
支援 HTTP(S) / HTTP2 / WebSocket /thrift /dubbo 等網絡協213議，涵蓋接口測試、性能測試、線上監控、持續內建、數字型驗監測等測試類型。
簡單易用，功能強大，具有豐富的插件化機制和高度的可擴充能力。
隻需編寫維護一份 YAML/JSON 腳本
前身 ApiTestEngine (2016年)，2017年正式更名HTTPRunner，并PyPI托管
②優缺點
設計理念和主要特征在官網有詳細列出，不再贅述。這裡主要列舉一下優缺點。
優點:
- 基于YAML/JSON格式，專注于接口本身的編寫
- 接口錄制功能，操作簡單，隻需3步即可完成測試，對于較為簡單的場景尤其友善
- 接口編寫簡單，容易上手，對代碼編寫能力要求較低
- 生成測試報告，可以自動生成測試報告，架構自帶的測試報告模闆基本滿足需求，支援自定義測試報告的模闆
- 分層機制，适合冒煙流程測試，無需重複編寫接口，隻要根據需求靈活調用即可
缺點:
- HttpRunner 沒有編輯器插件，本身就是一個配置檔案，是以隻要是合法的YAML/JSON格式，就算寫錯了看沒有校驗也不出來，隻有運作起來才知道
- 架構推出時間相對較短，官方文檔沒有特别詳細的說明，且網上資料相對其他主流測試架構較少
- 擴充不友善，資料驅動需要依賴其他接口傳回,且有先後順序，這個比較麻煩,暫時架構不支援很優雅的解決這種情況.可以通過分步來解決這個問題
- 由于用例的資料導出隻能在一個測試周期中,是以我們還要解決測試資料傳遞的問題
- 通過寫入檔案的方式解決.接口傳回的測試資料寫入檔案,然後需要的地方通過讀取檔案的方式讀回資料
③使用要求
有一定的python基礎，會使用charles/fiddler/postman， 對request架構有基本了解，至少會get、post請求
④适用業務
接口關聯關系弱、業務邏輯分支多，場景多、 接口/場景複用性高
⑤環境依賴
python V3.6+
pycharm
httprunner 3.1.11以下(！重要，httprunner V4已經去掉了startproject腳手架，不适合新手快速接入)
Anacanda
⑥架構實作功能
- 概述
二次封裝采用了V2.0和V3.0結合的方式：
a.使用V2.0的分層理念，降低場景case編寫的重複性和後期維護成本
b.在V3.0上運作。使用了V3.0內建的pytest功能，包括parameters、fixture 、hooks、allure以及其他pytest生态的衆多插件
c.用例管理仍舊使用yaml，使用V2.0的har2case方法生成yaml用例，對代碼基礎薄弱的同學相對友好
d.保留了V3.0的鍊式調用和文法檢查，對有代碼基礎的同學編，提供了智能文法提示寫用例時，提供文法檢查
e.報告的生成使用了V3.0引入的allure，報告更加美觀詳細
f.可移植性，支援conda虛拟環境+requirements.txt 複制環境
- 主要功能已實作，後續功能根據業務需要持續更新
參數化、業務斷言、資料驅動、測試分層、util封裝、環境變量、配置管理、場景測試用例、 setup/teardown，不同作用範圍、 熱加載、 動态參數、 報告、 持續內建
- 整體運轉流程
圖檔來源：debugtalk的github readme
⑦應用步驟
用例要求：
a.所有基礎的接口都要錄制全
b.提前設計好要覆寫的場景，錄制用例時，不要做多餘的操作
c.放入指定的用例存放目錄
将har檔案轉換成yaml用例或者pytest用例
配置好ini檔案
運作項目
- 本地執行
- 配置到jenkins job中運作
4、pytest+requesty
①簡介
Pytest是Python的一種第三方單元測試架構，全功能且非常成熟，同自帶的Unittest測試架構類似，相比于Unittest架構使用起來更簡潔，效率更高。它的目的是讓單元測試變得更容易，并且也能擴充到支援應用層面複雜的功能測試。
②優缺點
優點：
- 能夠支援簡單的單元測試和複雜的功能測試
- pytest具有豐富的插件生态，并且可以自定義擴充
- 可以很好的和jenkins內建
- report架構----allure 也支援了pytest
- 自動識别測試子產品和測試函數
- 支援參數化
- 子產品化夾具用以管理各類測試資源
- 對 unittest 完全相容
- 社群繁榮，文檔豐富，文檔中有很多執行個體可以參考
缺點：
- 學習成本高
③使用要求
- 對pytest架構有基本了解
- 對request有基本了解
- 要求python基礎
- 了解封裝
- 了解虛拟環境
④适用業務
項目接口多，但是入參大同小異
大部分接口都做了鑒權
⑤環境依賴
python V3.9以上
pycharm
Anacanda
⑥架構實作功能
a.測試類基類封裝：基類實作了所有測試case通用的方法如列印請求/響應、日志管理、斷言等，所有測試case類繼承基類
b.統一請求封裝：
- 全局維護一個session對象，自動實作cookie/session管理功能，無需每個接口單獨進行鑒權
- 接口通用參數提取，無需每個接口單獨處理。如base_url、referer、headers處理，ssl處理等
- 提供全局統一發起請求方法，屏蔽不同請求方法的底層實作細節
c.配置化實作：通過全局配置檔案，實作公共參數管理
d.參數化實作：測試用例腳本與測試資料分類，通過yaml進行用例管理
e.公共util：實作斷言、日志管理、資料庫驅動、郵件封裝、檔案讀取等
舉例說明
以有錢聯盟小程式為例，在postman中進行接口測試時，所有的接口都需要在header中封裝cookie 和 referer，即使在環境變量中實作了參數化可以統一管理，但這個接口添加仍然很繁瑣。
轉化成自動化接口測試腳本，以某個接口為例，封裝前的代碼如下：
封裝後如下，所有的接口case都是統一的一套代碼
隻需要每個接口單獨實作yaml用例即可
⑦應用步驟
a.用例要求：使用yaml編寫測試用例，用例需要包含基本字段，如name、des、request、validata
b.準備運作配置ini檔案：主要包含用例路徑、用例自動識自定義字首、用例分組、運作參數設定等
c.準備項目配置ini檔案：主要包含公共參數的全局錄入、日志路徑及格式、資料庫連接配接資訊等
d.運作項目
五、總結
沒有最好的架構，隻有最合适的架構。
根據項目特點、技術棧、業務需要、疊代頻率、組員技術水準等，綜合進行自動化接口測試架構的選擇，降低接入成本 和 維護成本，才能做好自動化測試的持續性。
自動化系列二将對自動化UI架構進行對比介紹。
作者:360技術中台-韓丹
來源:微信公衆号:360技術工程
出處:https://mp.weixin.qq.com/s/K_ylHFJeA9xZfItHLrzaGQ