1. 前言

上一篇文章介紹了在設計接口用例之前應遵守的設計規范，詳見《RobotFramework接口設計規范》，當然讀者公司的內部規范也不一定非得完全遵循筆者所提到的，適合自己公司內部的一套就可以了。

由於現在公司新項目的啟動和自身負責的開發工作量的增劇，基本上更新文章都只能利用周末零碎時間來寫，一個字一個字的碼出來的，另外透露一下，下面分享的內容有部分核心思想筆者是將之前發表過的技術專利中的內容開放了一小部分哦，還是有些干貨內容值得借鑒的，也希望各位讀者多多支持一下。

接下來，我們來聊聊，RobotFramework接口設計的分層玩法和常用的控制方式。

2. RF分層推薦玩法

說到分層，大家最容易想到的就是著名的測試金字塔的分層結構，如：

那么RobotFramework設計的接口框架分層該怎么來分呢，當然分層的好處和作用筆者就不在這里過多的說了，也不是本文的重點，相信大家也都能體會到。

分層原則: 【分層目標：接口數據和接口業務分離】

可再細分為：

項目目錄結構分層
接口數據、接口用例、接口業務分離
公共方法、數據分離

3. 分層實施

3.1、項目結構分離

具體要實施接口自動化的產品項目，一般可作為一個自動化工程的主目錄。

其中，項目主目錄中，按分層思想，又可根據接口功能分成不同模塊，不同模塊可作為二級目錄。在這里模塊可划分成兩類，一類為按功能模塊，在命名時，以具體功能作為命名，如評論模塊，可命名為Comment，且功能模塊主要用來驗證某個單一模塊下各接口功能上是否符合預期，另一類為模塊業務，在命名時，以Business命名，所有業務功能驗證均存放在此目錄下，主要用來驗證實現具體業務功能時，各接口的關聯組合調用驗證，如驗證某個視頻播放功能時，其中，對於視頻播放這一具體的業務來說可能會涉及到很多接口之間的調用，包括接口前置條件，接口之間傳遞數據，接口數據清理等。

*項目的功能模塊划分以具體的項目而定，在實際的接口自動化項目開展中，需要求開發人員，提供項目接口對接文檔。接口測試人員，依據接口對接文檔描述，划分具體的功能模塊及某個功能模塊下包含了哪些具體接口。

3.2、接口業務分離

不同接口模塊下，又可根據子功能的不同，划分成不同接口。主要又包含兩部分，一部分為接口業務關鍵字（對應在其它編程語言中，這里所說的關鍵字，其實就是封裝的函數、方法），通常一個接口下，可以根據測試的業務不同，定義多個不同的關鍵字。另一部分就是接口功能用例，接口用例下僅需填測試數據即可。通常不同的用例存放不同的測試數據，即業務關鍵字的入參，業務關鍵字根據接收到不同測試數據而去自動執行對應的業務流程。

*通常將具體的一組動作序列封裝一個業務關鍵字，測試用例中之所以只存放測試數據的設計核心就是在於將測試業務與測試數據分離。因為通常測試過程中，一個業務關鍵字的動作序列不會經常變更，需要變更的是測試數據，通常不同的測試數據，會導致業務關鍵字的產生的結果不同。

3.3、公共方法數據分離

包括三部分，公共方法（Public）、項目配置文件(Config)、數據構造文件(xx_var.py)。其中：

公共方法，主要提供各個不同項目接口之間都會調用到的一些公共方法，如數據加密、解密，接口數據校驗、接口統計等。

主配置文件，主要存儲接口在各個不同環境下（通常一個產品，開發完成后，都需要在測試環境驗證通過后，才可發布到線上環境，這里所說的不同環境指的就是測試環境、線上環境）的訪問地址，通常做法可在業務關鍵字編寫腳本時，將接口訪問地址通過變量來控制，然后此變量訪問主配置文件對應的接口地址即可，通常接口環境分定義為測試環境下的接口訪問地址、預發布環境接口地址、線上接口環境地址等(可參照下述截圖部分)。

數據構造文件，由於在不同環境下，需要用到的測試數據可能會有所不同，所以可通過構建對應環境下的變量文件來為接口在不同環境下執行時提供測試數據，變量控制文件中主要存儲一些可變的變量文件，或通過函數來構造測試數據然后再將構建數據方法返回到具體變量中提供給測試用例或業務關鍵字使用。

數據控制文件的設計核心在於，在變量文件中定義構造數據的函數方法，然后將方法的返回值賦給一個變量，在具體的接口引用該變量。