一、自動化測試框架
在大部分測試人員眼中只要沾上“框架”，就感覺非常神秘，非常遙遠。大家之所以覺得復雜，是因為落地運用起來很復雜；每個公司，每個業務及產品線的業務流程都不一樣，所以就導致了“自動化測試框架”去完成自動化測試的時候產生很多不穩定因素，這樣就很難定位成一個固定的框架。其實不然，真正的自動化測試框架不是一個模式，而是一種思想和方法的集合，通俗的講就是一個架構。
二、自動化測試框架思想
為了更好的了解自動化測試框架，我們先從自動化測試的發展歷程說起；一般測試工作限在3年以上且接觸過自動化測試的應該對以下幾種自動化測試框架思想有一定的認知：
- 模塊化思想
- 庫思想
- 數據驅動思想
- 關鍵字驅動思想
以上僅僅是代表了一種自動化測試的思想，并不能定義為框架。上面講到框架=思想+方法，于是演化了以下五種框架：
1、模塊化測試腳本框架
需要創建小而獨立的可以描述的模塊、片斷以及待測應用程序的腳本。這些樹狀結構的小腳本組合起來，就能組成能用于特定的測試用例的腳本。
2、測試庫框架
與模塊化測試腳本框架很類似，并且具有同樣的優點。不同的是測試庫框架把待測應用程序分解為過程和函數而不是腳本。這個框架需要創建描述模塊、片斷以及待測應用程序的功能庫文件。
3、關鍵字驅動或表驅動的測試框架
這個框架需要開發數據表和關鍵字。這些數據表和關鍵字獨立于執行它們的測試自動化工具，并可以用來“驅動＂待測應用程序和數據的測試腳本代碼，關鍵宇驅動測試看上去與手工測試用例很類似。在一個關鍵字驅動測試中，把待測應用程序的功能和每個測試的執行步驟一起寫到一個表中。
這個測試框架可以通過很少的代碼來產生大量的測試用例。同樣的代碼在用數據表來產生各個測試用例的同時被復用。
4、數據驅動測試框架
在這里測試的輸入和輸出數據是從數據文件中讀取（數據池，ODBC源，CSV文件，EXCEL文件，Json文件，Yaml文件，ADO對象等）并且通過捕獲工具生成或者手工生成的代碼腳本被載入到變量中。在這個框架中，變量不僅被用來存放輸入值還被用來存放輸出的驗證值。整個程序中，測試腳本來讀取數值文件，記載測試狀態和信息。這類似于表驅動測試，在表驅動測 試中，它的測試用例是包含在數據文件而不是在腳本中，對于數據而言，腳本僅僅是一個“驅動器”，或者是一個傳送機構。然而，數據驅動測試不同于表驅動測試，盡管導航數據并不包含在表結構中。在數據驅動測試中，數據文件中只包含測試數據。
5、混合測試自動化框架
最普遍的執行框架是上面介紹的所有技術的一個結合，取其長處，彌補其不足。這個混合測試框架是由大部分框架隨著時間并經過若干項目演化而來的。
三、接口自動化測試框架策略
- 設計出來的框架是直接給測試人員，而且其他的測試人員只需要簡單的向里面不斷的補充測試用例即可；所以我們的框架設計必須三簡化即操作簡單，維護簡單，擴展簡單。
- 設計框架的同時一定要結合業務流程，而且不僅僅靠技術實現，其實技術實現不難，難點對業務流程的理解和把握。
- 設計框架時要將基礎的封裝成公用的，如：get請求、post請求和斷言封裝成同基礎通用類。
- 測試用例要與代碼分享，這樣便于用例管理，所以將我們選擇上面的數據驅動思想。
四、接口自動化測試框架設計
1、進行接口框架設計前，我們先看看當前的一些主流接口自動化工具框架
2、以上各工具特性
根據以上的特性可得我們優先考慮Python+Requests和HttpRunner；下面我們根據其兩個框架分別來分析下用例執行過程。
3、用例執行解析
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'])五、接口自動化測試框架落地
根據簡單易用易維護原則我們使用HttpRunner工具設計框架。
1、HttpRunner簡介
主要特性：
- 集成了Requests的全部特性，滿足對http、https的各種測試需求
- 測試用例與代碼分離，采用YAML/JSON的形式描述測試場景，保障測試用例具備可維護性
- 測試用例支持參數化和數據驅動機制
- 基于 HAR 實現接口錄制和用例生成功能
- 結合 Locust 框架，無需額外的工作即可實現分布式性能測試
- 執行方式采用 CLI 調用，可與 Jenkins 等持續集成工具完美結合
- 測試結果統計報告簡潔清晰，附帶詳盡統計信息和日志記錄
- 具有可擴展性，便于擴展實現 Web 平臺化
2、環境準備
安裝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已搭建完成
3、用例管理
在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.json5）查看運行結果
- 在此目錄下會自動生成一個reports文件，進入該文件夾可看到生成帶時間的html（執行一次就會生成一個Html文件）
?打開此Html查看
全部通過
部分通過
- 點擊Log，可查看具體請求信息和返回信息
?點擊trackback可查看定位錯誤信息
)
