關於接口測試——自動化框架的設計與實現

還在糾結 ETL 工具選型？試試免費的數棲雲，註冊便可快速上手：dtcloud.dtwave.com

1、自動化測試框架

在大部分測試人員眼中只要沾上「框架」，就感受很是神祕，很是遙遠。你們之因此以爲複雜，是由於落地運用起來很複雜；每一個公司，每一個業務及產品線的業務流程都不同，因此就致使了「自動化測試框架」去完成自動化測試的時候產生不少不穩定因素，這樣就很難定位成一個固定的框架。其實否則，真正的自動化測試框架不是一個模式，而是一種思想和方法的集合，通俗的講就是一個架構。

2、自動化測試框架思想

爲了更好的瞭解自動化測試框架，咱們先從自動化測試的發展歷程提及；通常測試工做限在3年以上且接觸過自動化測試的應該對如下幾種自動化測試框架思想有必定的認知：

• 模塊化思想
• 庫思想
• 數據驅動思想
• 關鍵字驅動思想

以上僅僅是表明了一種自動化測試的思想，並不能定義爲框架。上面講到框架=思想+方法，因而演化了如下五種框架：

一、模塊化測試腳本框架

須要建立小而獨立的能夠描述的模塊、片段以及待測應用程序的腳本。這些樹狀結構的小腳本組合起來，就能組成能用於特定的測試用例的腳本。

二、測試庫框架

與模塊化測試腳本框架很相似，而且具備一樣的優勢。不一樣的是測試庫框架把待測應用程序分解爲過程和函數而不是腳本。這個框架須要建立描述模塊、片段以及待測應用程序的功能庫文件。

三、關鍵字驅動或表驅動的測試框架

這個框架須要開發數據表和關鍵字。這些數據表和關鍵字獨立於執行它們的測試自動化工具，並能夠用來「驅動＂待測應用程序和數據的測試腳本代碼，關鍵宇驅動測試看上去與手工測試用例很相似。在一個關鍵字驅動測試中，把待測應用程序的功能和每一個測試的執行步驟一塊兒寫到一個表中。

這個測試框架能夠經過不多的代碼來產生大量的測試用例。一樣的代碼在用數據表來產生各個測試用例的同時被複用。

四、數據驅動測試框架

在這裏測試的輸入和輸出數據是從數據文件中讀取（數據池，ODBC源，CSV文件，EXCEL文件，Json文件，Yaml文件，ADO對象等）而且經過捕獲工具生成或者手工生成的代碼腳本被載入到變量中。在這個框架中，變量不只被用來存放輸入值還被用來存放輸出的驗證值。整個程序中，測試腳原本讀取數值文件，記載測試狀態和信息。這相似於表驅動測試，在表驅動測 試中，它的測試用例是包含在數據文件而不是在腳本中，對於數據而言，腳本僅僅是一個「驅動器」，或者是一個傳送機構。然而，數據驅動測試不一樣於表驅動測試，儘管導航數據並不包含在表結構中。在數據驅動測試中，數據文件中只包含測試數據。

五、混合測試自動化框架

最廣泛的執行框架是上面介紹的全部技術的一個結合，取其長處，彌補其不足。這個混合測試框架是由大部分框架隨着時間並通過若干項目演化而來的。
比 Kettle 更上手更快的 ETL 工具，無需付費當即試用：dtcloud.dtwave.com

3、接口自動化測試框架策略

1. 設計出來的框架是直接給測試人員，並且其餘的測試人員只須要簡單的向裏面不斷的補充測試用例便可；因此咱們的框架設計必須三簡化即操做簡單，維護簡單，擴展簡單。
2. 設計框架的同時必定要結合業務流程，並且不只僅靠技術實現，其實技術實現不難，難點對業務流程的理解和把握。
3. 設計框架時要將基礎的封裝成公用的，如：get請求、post請求和斷言封裝成同基礎通用類。
4. 測試用例要與代碼分享，這樣便於用例管理，因此將咱們選擇上面的數據驅動思想。

4、接口自動化測試框架設計

一、進行接口框架設計前，咱們先看看當前的一些主流接口自動化工具框架

二、以上各工具特性

工具	學習 成本	錄製	持續集成	測試報告	用例管理	性能測試	擴展難度	最低要求
Java+testng+Maven	高	否	是	是	難	是	中	Java
Requests+Python	低	否	是	是	難	是	中	Python
Robot Framework	低	否	是	是	易	否	高	工具組件
HttpRunner	低	是	是	是	易	是	低	Python

根據以上的特性可得咱們優先考慮Python+Requests和HttpRunner；下面咱們根據其兩個框架分別來分析下用例執行過程。

三、用例執行解析

Python的Requests庫針對全部的HTTP請求方法，採用的是統一的接口

requests.request(method, url, **kwargs)

其中，kwargs能夠保護HTTP請求全部可能用到的信息，例如：headers、cookies、params、data、auth等。因此，只要遵循Requests的參數規範，在接口測試用例中複用Requests參數的概念便可。而HttpRunner處理邏輯很簡單，直接讀取測試用例中的各項參數，傳遞給Requests發起請求。

1）Requests接口請求示例

def test_login(self):
 url = "www.xxx.com/api/users/login"
 data = {
 "name": "user1",
 "password": "123456"
 }
 resp = requests.post(url, json=data)
 self.assertEqual(200, resp.status_code)
 self.assertEqual(True, resp.json()["success"])

在該用例中，實現了HTTP POST請求，而後對響應結果進行判斷，檢查響應code等是否符合預期。

這樣的用例在實際項目中會存在兩個問題：

• 用例模式基本固定，會存在大量類似或重複的用例，用例維護有很大問題
• 用例與執行代碼不分離，參數數據也未分離，一樣不易維護

2）HttpRunner使用json/yaml格式處理測試用例，分離後的用例描述以下

{
 "name": "test login",
 "request": {
 "url": "www.xxx.com/api/users/login",
 "method": "POST",
 "headers": {
 "content-type": "application/json"
 },
 "json": {
 "name": "user1",
 "password": "123456"
 }
 },
 "response": {
 "status_code": 200,
 "headers": {
 "Content-Type": "application/json"
 },
 "body": {
 "success": true,
 "msg": "user login successfully."
 }
 }
 }

3）HttpRunner用例執行引擎

def run_testcase(testcase):
 req_kwargs = testcase['request']try:
     url = req_kwargs.pop('url')
     method = req_kwargs.pop('method')
 except KeyError:
     raise exception.ParamsError("Params Error")

 resp_obj = requests.request(url=url, method=method, **req_kwargs)
 diff_content = utils.diff_response(resp_obj, testcase['response'])
 success = False if diff_content else True
 return success, diff_content

4）從測試用例中獲取HTTP接口請求參數，testcase['request']

{
 "url": "www.xxx.com/api/users/login",
 "method": "POST",
 "headers": {
 "content-type": "application/json"
 },
 "json": {
 "name": "user1",
 "password": "123456"
 }
 }

5）發起Http請求

requests.request(url=url, method=method, **req_kwargs)

6）檢測測試結果，即斷言

utils.diff_response(resp_obj, testcase['response'])

5、接口自動化測試框架落地

根據簡單易用易維護原則咱們使用HttpRunner工具設計框架。

一、HttpRunner簡介

主要特性：

• 集成了Requests的所有特性，知足對http、https的各類測試需求
• 測試用例與代碼分離，採用YAML/JSON的形式描述測試場景，保障測試用例具有可維護性
• 測試用例支持參數化和數據驅動機制
• 基於 HAR 實現接口錄製和用例生成功能
• 結合 Locust 框架，無需額外的工做便可實現分佈式性能測試
• 執行方式採用 CLI 調用，可與 Jenkins 等持續集成工具完美結合
• 測試結果統計報告簡潔清晰，附帶詳盡統計信息和日誌記錄
• 具備可擴展性，便於擴展實現 Web 平臺化

#### 二、環境準備

安裝HomeBrew（MacOs軟件包管理工具，相似apt-get、yum）

• 終端執行

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

• 安裝pyenv並配置環境變量：python版本管理器，可同時管理多個Python版本（HttpRunner是基於Python開發，可是支持Python3.6.0以上）

brew install pyenv
echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bash_profile
echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bash_profile
echo 'eval "$(pyenv init -)"' >> ~/.bash_profile
exec $SHELL -l

• 安裝Python3.6

pyenv install --list //查看可安裝的Python版本
pyenv install 3.6.0 //安裝3.6.0版本
pyenv rehash //更新pyenv
pyenv versions //查看已經安裝的python版本，帶*號的是當前使用的版本

• 選擇Pyhton

pyenv global 3.6.0 //設置全局版本，即當前系統使用的版本將切換爲3.6.0

• 安裝HttpRunner並校驗

pip install httprunner
//運行以下命令，若正常顯示版本號，則說明httprunner安裝成功：
hrun -V
0.9.8

至此HttpRunner已搭建完成

三、用例管理

在HttpRunner中，測試用例引擎最大的特點就是支持Yaml/Json格式的用例描述形式；

採用YAML/JSON格式編寫維護測試用例，優點仍是很明顯的：

• 相比於表格形式，具備更增強大的靈活性和更豐富的信息承載能力；
• 相比於代碼形式，減小了沒必要要的編程語言語法重複，並最大化地統一了用例描述形式，提升了用例的可維護性。

Yaml格式

Json格式

如下以數瀾--數棲平臺2.X中的研發平臺爲例（採起Json格式）

場景：項目空間後，須要快速支持建立Demo示例，即自動建立各類目錄和任務。

1）肯定業務流程所使用到的接口並經過Postman或Jmeter調試經過及分好類

• 查詢類（Get請求）接口：查詢任務目錄、查詢資源組、查詢工做流等
• 新增類（Post請求）接口：新建目錄、新建任務等

2）根據業務流程肯定接口順序

• 如要在某個目錄下新建任務：則先要調用新建目錄接口再調用做建任務接口

3）向Json文件裏按照規則填寫接口相關信息

• 接口Base_Url
• 接口路徑
• 接口請求方式
• 接口請求參數
• 接口斷言
• 接口返回參數（關聯接口時會用到上一接口返回的參數）

如下是部分用例示例

4）用例填寫完成後，執行用例文件，如Json文件爲task.json

hrun task.json

5）查看運行結果

• 在此目錄下會自動生成一個reports文件，進入該文件夾可看到生成帶時間的html（執行一次就會生成一個Html文件）

  ）

• 打開此Html查看

所有經過

部分經過

• 點擊Log，可查看具體請求信息和返回信息

• 點擊trackback可查看定位錯誤信息

[做者簡介：泫空，6年測試相關工做經驗，曾任微醫集團搜索測試負責人，負責服務端測試、接口自動化、持續集成測試和性能測試及測試開發。曾參與中國移動政企能力提高項目等。]
免費的一站式 ETL 工具，點擊連接當即瞭解：dtcloud.dtwave.com