接口測試架構開發實踐2：接口自動化測試架構設計思路

軟體品質保障

專注于測試圈：測試品質保障、自動化工具/架構、平台開發、算法測試、BAT/TMD大廠測試崗面試題/面經分享、測試團隊建設與管理、測試新技術的分享。 偶爾也聊聊個人工作的收獲與經驗。可以幫忙内推位元組、阿裡、百度等大廠。

本節内容主要講解接口自動化測試架構基本組成子產品，各個子產品可選擇的方案，并根據業務需要采取對應的實作方案，最終組裝成符合業務訴求的自動化架構。

​1.接口自動化測試目的

每個tester都曾經曆過繁瑣且重複的手工測試，當你在測試環境發現缺陷時候，開發修複後，你需要再次回歸用例進行驗證缺陷是否修複；當你在測試環境上測試通過後，還需要線上上環境回歸一下核心用例；OMG，重複的工作讓人崩潰。在整個項目過程，你的測試用例是基本上是固定的（也即是提測前根據系分/PRD設計的用例），重複的是你對用例的一遍又一遍操作。而自動化的目的就是解決上述問題的：解放手工測試，降低tester重複的回歸測試成本。當然自動化的用處除此之外，還有其他的應用場景：例如通過自動化批量造測試資料、利用自動化對線上環境服務做監控等。但是自動化最核心的用處就是 回歸測試。

2.結構圖

下圖就是對接口自動化架構實作方案畫的一個通用架構。

既然需要滿足用例在多環境上回歸，那麼測試架構就需要支援多環境，而環境配置子產品可以配置被測系統的開發、測試、甚至線上環境。這樣可以讓使用者選擇測試用例在需要執行的環境上運作。

我們日常寫的接口測試用例一般都是通過ddt驅動，将測試資料組裝到一個完整的HTTP請求體中，根據用例中接口請求方法類型選擇調用HTTP核心子產品封裝好的函數，然後将響應結果進行斷言并填充到報告模闆，最後調用通知服務，将測試結果發送至釘釘群。

此外，我們需要對每次測試用例執行過程産生的資料進行定期清洗，避免自動化資料對後面的系統測試産生不必要的幹擾。

3.核心子產品講解

3.1環境配置

環境配置，屬于測試前置準備工作。當用例開始執行之前，架構會自動讀取待執行環境的配置資訊。如何實作根據環境讀取對應環境配置資訊呢？最正常的方法就是将不同環境配置資訊配置在各自的檔案中。例如，你的待測系統有三套環境：DEV、TEST、PROD，那麼你可以建立三個JSON/Yaml檔案，分别為dev.yaml、test.yaml、prod.yaml，根據檔案讀取邏輯子產品，可以手動輸入環境配置檔案字首，就可以讀取對應的配置資訊了。

DB_mysql:
	ip: localhost
	port: 3306
	user: root
	password: 123456
	database: mall
           

3.2用例管理

1.用例組成

一個完整的接口用例，必須包含測試資料、HTTP請求、斷言。

1. 測試資料：測試用例都是資料驅動的，接口測試屬于黑盒測試範疇，是以輸入決定輸出。而資料不僅僅要包含正向的，也要包含反向和異常的資料。
2. HTTP請求：包含接口名、域名、請求體、請求頭内容

1. 斷言：怎麼确定你的測試用例是通過的還是不通過的呢，斷言就顯得至關重要。斷言内容就是你要的預期結果。斷言包含對接口響應内容做斷言、也包含對落DB的資料做斷言。

将上述介紹的接口組成元素進行簡單分析下，向請求頭、域名這些可以剝離出來作為通用元素提供（實作方式可參考上篇文章介紹JMeter元件HTTP Header Manager）。而斷言内容，由于每個接口每次執行不同request body時可能會出現不同的内容，是以這塊具體的斷言内容也不能完全寫死，可以增加斷言标記（例如斷言response中某幾個字段）， 具體斷言邏輯可以單獨抽離出來交至斷言子產品處理。

最終一條自動化用例組成元素包括：

1. 用例唯一标記
2. 接口名

1. 請求方法
2. 請求體

1. 斷言标記
2. 其他

2.用例管理媒體

正常的用例管理媒體有MySQL、Excel、Ymal/Json。如果仔細分析的話，其實就兩種，一種是“線上存儲”-MySQL方式，一種是“線下”存儲-以文本方式存儲。

MySQL存儲的好處就是可以系統的管理測試用例，如果你的平台将來需要搭建Web頁面管理用例，則可以很天然地銜接過渡，反之，如果以文本形式則不行。但是這種方式也有缺點，1.通常請求體都是Json結構，在你準備資料時候很容易沒注意檢查結構是否是json，導緻用例運作失敗，增加排查問題難度。2.如果你的待測系統多個環節是互相隔離的，出于安全考慮，你的MySQL不可能允許多個環境都能建立連接配接。而以檔案形式存儲用例則不存在這個問題，接口用例以檔案形式存儲，隸屬于接口測試架構，可以在多個環境上加載并讀取。缺點就是用例不易管理，維護起來要費時間。

具體采取哪種方式存儲用例，大家可以根據自己項目系統特點做決定。

3.用例管理常見的問題

1. 如何處理環境隔離的問題？

解決方案：建議檔案形式存儲用例。

1. 如何處理接口間參數傳遞的問題？

解決方案：接口自動化用例并非都是單接口測試用例，更多的是各種業務場景組合用例，就涉及到接口間的互相調用，即接口間參數有依賴關系。最簡單的例子就是登陸後才能進行其他場景操作，這樣就需要先擷取登陸接口的token，并将其傳入下遊接口。怎麼傳入下個接口呢？有一種方法是，将下遊接口需要依賴的上遊接口響應包含的字段給參數化，在開發組合用例時候将上遊接口響應字段取出替換下遊接口參數化的變量。

3.3HTTP

1.HttpClient

如果你的架構基于Java語言開發，HTTP核心子產品可以使用HttpClient，将其提供的GET/POST等請求方法封裝即可。HttpClient是Apache Jakarta Common下的子項目，用來提供高效的、最新的、功能豐富的支援HTTP協定的用戶端程式設計工具包。

HttpClient 提供的主要的功能

（1）實作了所有 HTTP 的方法（GET,POST,PUT,DELETE 等）

（2）支援自動轉向

（3）支援 HTTPS 協定

（4）支援代理伺服器等

http://hc.apache.org/httpclient-legacy/

2.requests

如果你的架構基于Python語言開發，則首推requests庫。

Requests 是用Python語言編寫，基于 urllib，采用 Apache2 Licensed 開源協定的 HTTP 庫。它比 urllib 更加友善，可以節約我們大量的工作，完全滿足 HTTP 測試需求。Requests 的哲學是以 PEP 20 的習語為中心開發的，是以它比 urllib 更加 Pythoner。

後面文章會詳細介紹用法以及封裝方法。

3.4常用測試架構

1.testNG

TestNG是一個基于Java語言開發的測試架構，其靈感來自JUnit和NUnit，引入了許多創新功能，如依賴測試，分組概念，使測試更強大，更容易做到。它旨在涵蓋所有類别的測試：單元，功能，端到端，內建等

TestNG的特點：

• 注解
• 靈活的運作時配置

• 支援“測試組”。
• 支援依賴測試方法，并行測試，負載測試

• 靈活的插件API
• 支援多線程測試

2.pytest

pytest是一個強大的Python測試工具，它可以用于所有類型和級别的軟體測試。pytest提供強大的功能，如'斷言'重寫，第三方插件模型，強大但簡單的fixture模型。pytest支援指令行，會自動找到你寫的測試，運作測試并報告結果。

https://learning-pytest.readthedocs.io/zh/latest/

3.5其他

測試報告有allure、htmltestreport可以選擇。

allure支援Java/Python語言開發的測試架構，報告比較美觀。

本文采取的設計架構為：Python+requests+Pytest+Yaml架構，下面的文章開始講解各個子產品的開發。

往期推薦：

接口自動化測試架構實踐1：接口測試概述