自動化測試框架的設計思路

karamay 9年前發布 | 66K 次閱讀自動化測試軟件測試

在開始設計之前,我們首先需要考慮以下幾個方面：

使用該框架寫出來的自動化測試案例，需要給開發,手動測試,可能還有客戶查看，所以寫的測試案例需要盡量的清晰明了，不要有太多復雜邏輯，及比較好的可讀性。

使用這個框架做自動化的人，不會有太深的編程能力，所以要提供足夠好的，最好是傻瓜化的測試點驗證方法，及很好的異常容錯處理能力。

測試框架最好是app，網頁測試，接口測試，統統都能支持。

針對上面的幾點，我們總結出以了下兩個核心點：該測試框架需要很好的可讀性和可擴展性。

思考如下。

可讀性思考

對于測試案例，比較流行的兩種觀點：

1. 希望做成自然語言描述的case

比如：

I go to “www.baidu.com”

I Input “點融網”

I click 搜索按鈕

I see “點融網最有保障的P2P，最專業的技術團隊”

此方式為不懂技術的相關人員所喜愛，簡單明了，可讀性好。

2. 希望做成編程模式

比如：

Driver.navigate_to(“www.baidu.com”)

element = driver.find_element_by_id(“id”,”kw”)

element.send_keys(“點融網”)

element = driver.find_element(“id”, ”su”)

element.click()

……

此方式是自動化測試工程師喜歡的方式。希望告訴大家，我們也是寫代碼的，記住我們也是coder。

針對以上兩個不同觀念，我們是否可以考慮將測試案例設計成，既能一定程度體現自然語言描述特點，又能兼顧使用程序語言的靈活性？

我們仔細分析測試場景，抽出UI測試的核心行為，無非就是：

檢查點：

頁面元素是否存在

頁面元素顯示內容是否正確

頁面元素是否可用

……

輔助功能：

等待元素出現

點擊某頁面元素

給元素輸入內容

……

分析抽出來的核心行為，發現這些行為基本都是針對一個個頁面元素進行的操作。那么我們就可以做如下的動作：

將頁面元素看成一個對象，封裝成一個類

將上面分析得到的核心行為都封裝成基類方法。然后確保，任何一個頁面元素都繼承該基類。

該基類提供類似于自然語言的方法名字，調用這些方法，就能很明確的知道測試案例在做什么檢查，在做什么行為，這樣就能極大的提高測試案例的可讀性

基類舉例：

該基類主要目的是在UI測試中，對元素共性的檢查點和輔助方法進行抽取，將它們封裝成一個個非常容易讀懂的方法，且具有異常處理能力。

經過上述思路的整理，針對文章開始時例舉的測試案例，就可以改寫成如下：

該測試案例是不是可讀性變強了呢？也直接用程序語言寫出來了呢？在實際的使用過程中，可以讓手動QA或者不太熟悉代碼的QA專門負責測試案例的實現，底層的方法包裝可以由經驗豐富一些的同事做。

擴展性思考

基于UI測試，我們希望除了支持web測試，還能支持app的測試，可能還需要接口測試，等等。怎么做呢？

我們就需要考慮分層問題，將測試框架分為三層。

第一層：測試案例層

該層是測試案例的具體實現，就像上面寫的case那樣，用接近自然語言的方式，來實現測試案例。

第二層：支持層

該層主要提供workflow，通用工具，元素庫的支持，便于測試案例層直接調用。

Workflow： 主要封裝測試項目中需要經常使用的針對項目的公用方法，供測試案例層直接調用。比如用戶登錄，注冊一個用戶，搜索出用戶等等經常使用的動作。

通用工具： 提供一些通用方法，比如生成一個隨機電話號碼，生成一個隨機身份證，數據庫操作，http操作支持等等

元素庫： 每一個頁面元素的定位表達式（xpath，id，name，css，link_text等等表達式）

我們的測試案例，都是針對一個個元素進行操作的。將每一個頁面的每一個元素，都看成一個繼承了基類的特定類。所以，我們的第一步，就需要找到這個元素，定位到這個元素。測試項目的所有元素都放到這里。

第三層： driver層

這一層主要封裝各種driver。比如我們針對網頁測試，使用selenium-webdriver開發包，針對app測試，我們使用appium開發包。我們在這一層進行封裝，通過調用selenium-webdriver，appium提供的原生方法，封裝成可讀性很強的方法且加上容錯機制。以后就算我們要換用其他的第三方包，我們的測試案例層和支持層的方法也不需要做任何的修改。只需要修改driver層實現的方式就可以了。在一層，我們主要實現兩個方面的封裝，一個是driver的封裝，一個是基于基類自然語言函數的封裝。

driver封裝

我們需要封裝，根據參數確實是基于web測試還是基于app測試。比如：