本文章轉載于搜狗測試

項目背景

公司產品的UI自動化測試，由于產品的業務流復雜，所以只針對部分流程進行自動化測試，復雜的業務流還是需要手動測試，因為可能花費了大量的時間去寫腳本和維護，然而手工的話只需要幾下就好了，在進行自動化的時候，一定要想清楚，哪些適合做，哪些不適合。

也就是我們常說的投入產出比，一定要考慮好這個才行。

一般說來，針對UI自動化，都是選取界面穩定，業務流不復雜的。

RF介紹

Robot Framework是一款python編寫的功能自動化測試框架。具備良好的可擴展性，支持關鍵字驅動，可以同時測試多種類型的客戶端或者接口，可以進行分布式測試執行。主要用于輪次很多的驗收測試和驗收測試驅動開發（ATDD）。

RIDE編輯器介紹

RF是通過RIDE編輯器進行工作的，安裝成功后，執行命令“[PythonDir]\Scripts\ride.py”，就可以打開RIDE編輯器。

分層思想

說起分層，就一定能要說下“關鍵字驅動”。

關鍵字驅動就是當調用不同的關鍵字，導致測試結果不同。

RF的分層，類似于selenium的POM模式，可以提高用例的可維護性，提高用例的可讀性，提供較高的可擴展性。

實踐展示

目前的分層如下：

第一個是測試用例層，這里保存全部的測試用例，第二個是功能模塊層，將需要做的功能都都細分后放在里面。第三個是數據庫層，通過對數據庫的校驗，來驗證UI操作的的成功與否。第四層是元素層，將各個功能中涉及的元素都提取出來，便于后期維護修改。

第五個是業務流層，這里就是展現我們業務邏輯的層面。

測試用例層

名單管理部分就是測試用例層，所有需要執行的測試用例都放在這里，這里可以再仔細看下

這里面按照系統功能模塊進行劃分，新建了幾個resource，再resource下建立新的測試用例。

下面是用戶信息查詢的測試用例

在這里我們可以看到，表格中沒有關鍵字，只有數據，我們只需要在這里輸入不同的數據，就可以實現數據驅動，輸入不同的數據，檢測結果，進行測試。

那用例流程在哪里呢，可以看到template中，就是我們導入測試用例的地方，需要在resource中導入相關的關鍵字才行。

只有變為藍色時，才表示可用的。如果已經正確導入，但是沒有及時變藍，那么就關閉ride，重新打開，相信我，我遇到很多次這樣的情況了。

功能模塊層

下面是功能模塊層，把每個功能都作為一個關鍵字封裝起來，

看一個詳情，這其中包含了添加風險等級的操作流程，并且基本上每一個操作都封裝為一個用戶關鍵字了，這就是為了提高用例的可讀性

基本上通過看這個用例，就可以知道干了什么事情。

同時也提高了腳本的可維護性，便于維護腳本。當一個操作的元素定位變化時，我們不需要修改整個腳本，而只需要找到對應的關鍵字，修改它的定位元素就行了。

元素層

看一下點擊新建這個關鍵字

可以看到這個關鍵字中內容很少，只是一個點擊操作，點擊一個元素。

也許有人覺得這樣也需要去單獨轉化為一個關鍵字嗎，直接寫多方便。

是的，可以直接寫在腳本中，但是直接看這個代碼，你能知道這個點擊元素的操作產生了什么效果嗎？加入其他地方也需要點擊這個按鈕，那么是不是其他地方再寫一遍呢？

當然不，注意看左邊，這個關鍵字是在一個叫public-opera的resource中的，因為系統的原因，有很多業務都需要操作相同的元素，所以這里將這里單獨分層出來，作為“公共元素層”

這樣當其他的腳本中需要用到這些操作時，只需要導入public-opera，然后直接調用就可以了

數據庫交互層

在此系統中，很多操作都對后臺有交互，所以不能僅僅檢查頁面元素的顯示，而且需要連接數據庫，進行校驗，以便檢測操作是否真正成功。

變量

在數據庫連接腳本中，以及測試腳本中，需要重復用到很多變量，于是將這些變量也提出來，方便維護，這樣以后當變更數據庫地址，或者其他變量時，不需要找到對應的腳本中修改，只需要在這里修改即可。

自定義庫

在使用RF的過程中，RF自身提供的關鍵字很多時候并不滿足我們的需求，此時就需要自己開發系統關鍵字，自定義庫這一層中便放了自定義的幾個系統關鍵字。使用python寫了一個py文件，然后將py文件導入，就可以使用py文件中的方法了

業務流層

這里才是具體的業務流展現的地方，將每個業務都封裝成一個關鍵字，在test case中的template直接輸入關鍵字名字便可調用了。

這里便展現了一個業務具體的操作流程，從登陸，進入指定頁面，然后搜索對應的數據，獲取頁面上的數據，與數據庫中的數據進行比對，如果相同，說明成功，反之失敗。

當業務流有變化時，直接調整各個關鍵字的順序即可，這也是分層的優勢，大大提高了腳本的可重用性和可維護性。