傳統(tǒng)Web自動(dòng)化框架實(shí)踐指南

我們今天來看看一個(gè)成熟的Web自動(dòng)化框架是什么樣子的，如果你還對(duì)測(cè)試框架的概念有所疑惑，請(qǐng)移步iTesting公眾號(hào)的歷史文章測(cè)試框架之我見。

以下是Web自動(dòng)化框架實(shí)踐正文：

貼一個(gè)圖，是iTesting現(xiàn)在所在項(xiàng)目用的框架（實(shí)則為筆者4年前項(xiàng)目所有框架），我們來一步步分析說明：

注意觀察圖中每一個(gè)小方格右上方的數(shù)字，從1 到7，代表了測(cè)試框架的不同部分，我們來逐一介紹：

0：Core Framework。

這個(gè)是測(cè)試框架的靈魂，我們可以看出它又分為幾個(gè)部分，最底層就是Selenium， Webdriver，包括它們支持的原生庫。倒數(shù)第二層是支持最底層的第3方庫，二次開發(fā)生成的自定義庫，API還有自己定義的Keywords。再上一層是一些公共的方法，這些方法普遍應(yīng)用倒數(shù)第2層的API或者M(jìn)ehod，這一層的方法實(shí)現(xiàn)了具體的功能，微信搜索iTesting，關(guān)注本公眾號(hào)，比如說連接數(shù)據(jù)庫，并進(jìn)行增刪改查的功能；連接Web Service并調(diào)用相應(yīng)接口的功能；自動(dòng)生成要運(yùn)行的所有測(cè)試用例的功能；自動(dòng)注釋掉一些測(cè)試用例的功能。最上一層是解耦的測(cè)試腳本，每一個(gè)測(cè)試腳本完成一項(xiàng)特定的功能，比如，登錄，定課，注銷等。

1：Config File

Config ?file用來提供測(cè)試運(yùn)行時(shí)的各種參數(shù)，配置。

這個(gè)文件或者文件夾存放了測(cè)試需要的precondition，settings，運(yùn)行環(huán)境參數(shù)，還有運(yùn)行每一個(gè)具體case時(shí)候需要的測(cè)試數(shù)據(jù)。

測(cè)試所需的共同的配置可以放到一個(gè)文件里（例如Timeout，多線程支持標(biāo)志位），環(huán)境運(yùn)行參數(shù)可以放到另外一個(gè)文件里（例如UAT， LIVE），測(cè)試數(shù)據(jù)可以保存在Excel， XML，或者直接寫在文件里，以環(huán)境運(yùn)行參數(shù)為分隔符（例如UAT和Live下都有同一個(gè)變量名username）。

2：AUT ? application under test

這個(gè)模塊就是我們要測(cè)試的application。它分為2個(gè)部分：

一個(gè)部分是Pages（2-2）， 即各個(gè)待測(cè)試頁面。Pages里包含了頁面上所有的待測(cè)元素，以及這個(gè)頁面上的所有用戶能做的操作，我們通常把這些操作封裝成一個(gè)個(gè)的函數(shù)，以使它們來實(shí)現(xiàn)特定的功能，例如book_pl_class(class_info)函數(shù)，這個(gè)函數(shù)接受一個(gè)入?yún)ⅲ雲(yún)⑹且粋€(gè)Entity 類，包括了一節(jié)課所有必要信息，函數(shù)本身實(shí)現(xiàn)了pl class的預(yù)訂（通過接收參數(shù)，點(diǎn)擊相應(yīng)元素等操作）。函數(shù)返回值是一節(jié)課的所有信息。應(yīng)注意的是Pages里不應(yīng)該包含測(cè)試用例邏輯，所有的特定測(cè)試邏輯應(yīng)該與頁面具體操作解耦。

Pages我們引用了Page Object模式（將測(cè)試對(duì)象及單個(gè)的測(cè)試步驟封裝在每個(gè)Page對(duì)象中，以page為單位進(jìn)行管理），這個(gè)模式的好處是將測(cè)試方法和測(cè)試對(duì)象完全解耦，我們舉個(gè)例子， 在使用page object模式之前我們的代碼可能是這樣：

def login(self, user_name, password):    user_element = self.browser.find_element_by_id("username")    user_element.send_keys(user_name)    password_element = elf.browser.find_element_by_id("password")    password_element.send_keys(password +Keys.RETURN)

login方法和各個(gè)element對(duì)象（這里只有username 和password這兩個(gè)element）耦合在一起，當(dāng)UI改變導(dǎo)致element的定位方式改變后，我們不得不去方法內(nèi)部更改元素定位的方法，另外當(dāng)某個(gè)元素在不同方法重復(fù)使用時(shí)，還需要反復(fù)查找。這樣引發(fā)的問題是，當(dāng)一個(gè)方法需要很多頁面元素操作才完成時(shí)， 定位元素的大量代碼和方法實(shí)現(xiàn)的功能代碼耦合在一起，不僅更改起來困難，而且方法不直觀，不便于用戶理解。

我們來看引入了page obejct后代碼變成了什么：

USER_NAME_XPATH = "http://input[@id='UserName']"PASSWORD_XPATH = "http://input[@id='Password']"LOGIN_XPATH = "http://a[@class='et-btn-submit']")
user_name_textbox = PageElement(xpath=USER_NAME_XPATH)password_textbox = PageElement(xpath=PASSWORD_XPATH)login_button = PageElement(xpath=LOGIN_XPATH）
def login(self, user_name, password):     self.user_name_textbox.send_keys(user_name)     self.password_testbox.send_keys(password)?????self.login_button.click()

你看，只要login的功能邏輯不變，就無需更改login方法，任憑UI如果改變，我們只需要在方法外更改element的locator，無論username這個(gè)元素需要多少函數(shù)中引用，我們只需定義一次就好了，是不是很方便維護(hù)又一目了然啊。

還有，測(cè)試過程中經(jīng)常發(fā)現(xiàn)這樣的問題，頁面一開始就redirect到了非目標(biāo)頁面，因?yàn)槲覀儧]有針對(duì)目標(biāo)頁面本身做斷言，導(dǎo)致代碼繼續(xù)執(zhí)行，這樣浪費(fèi)了大量時(shí)間。我們可以通過驗(yàn)證目標(biāo)頁面正確與否的方法來避免這個(gè)問題。代碼如下：

class LoginPage(AbstractBasePage):   Target_XPATH = "http://a[@class='et-btn-submit']"
   def __init__(self, driver):        AbstractBasePage.__init__(self, driver)
    def is_target_page(self):        return self.is_element_displayed(By.XPATH, self.Target_XPATH)

這里我們利用了一個(gè)BasePage的類，里面定義了 is_target_page的抽象方法，然后子類繼承過來實(shí)現(xiàn)。

關(guān)于Pages還要很多好的優(yōu)化方法，可以使我們的代碼看起來簡(jiǎn)單可重用，這里不詳細(xì)介紹細(xì)節(jié)了。

另一部分就是Test scenarios（2-1），即具體的測(cè)試suite和測(cè)試用例，Test scenarios由一個(gè)個(gè)test case組成，每一個(gè)test case 通過引用相應(yīng)的Pages類/函數(shù)，和Core framework 里面的test scripts，來實(shí)現(xiàn)具體的功能， 而Test scenarios通過組合不同的test cases來覆蓋不同的業(yè)務(wù)需求.

其中， Test Scenarios/Test case 里均會(huì)用到 config file的各種參數(shù)配置。

所有的Test Scenarios創(chuàng)建好后（我們把每個(gè)test scenario封裝成一個(gè)測(cè)試類）， 就要決定如何執(zhí)行這些測(cè)試類了。那么，這些測(cè)試類每次運(yùn)行都需要全部執(zhí)行嗎？如果不需要，哪些是需要執(zhí)行的，哪些是要ignore的呢？這個(gè)時(shí)候Core framework里的common method的具體Method派上了用場(chǎng)，common里實(shí)現(xiàn)了generate_test_scenarios的方法和ignore_test_scenarios方法，利用ignore_test_scenarios方法，我們會(huì)在tests文件夾下面的ignore_testcase_lists文件里列出所有要ignore的test scenarios，然后利用generate_test_scenarios方法我們最終把所有要執(zhí)行的scenarios都放到__init__ ?里。

3：Main file。測(cè)試主函數(shù)。

測(cè)試主函數(shù)用來執(zhí)行生成的各種Test Suites， 包括實(shí)現(xiàn)多線程支持和錯(cuò)誤處理機(jī)制。它也是測(cè)試的入口函數(shù)。需要注意的是， Main 函數(shù)會(huì)裝載 Test下面的__init__文件，所有在__init__文件里的用例都會(huì)被執(zhí)行（是順序還是同時(shí)要看函數(shù)中對(duì)多線程的支持及實(shí)現(xiàn)）。

4：Test Report模塊。

Main 函數(shù)同時(shí)也會(huì)包含生成test report的方式，測(cè)試完成后，會(huì)根據(jù)需要生成txt格式，html格式test report并保持到系統(tǒng)本地。

5：Error Handling模塊。

測(cè)試運(yùn)行中，如果發(fā)現(xiàn)錯(cuò)誤，會(huì)根據(jù)Error handling規(guī)則觸發(fā)相應(yīng)的錯(cuò)誤處理機(jī)制，同時(shí)會(huì)觸發(fā)screen shots函數(shù)和log函數(shù)，把所有錯(cuò)誤截圖和log信息保存在系統(tǒng)本地。

6：Email Reports。

測(cè)試報(bào)告Email發(fā)送模塊，這個(gè)模塊可以在第7步里開發(fā)配置，也可以直接把代碼寫在Main 函數(shù)里，運(yùn)行完隨機(jī)發(fā)送測(cè)試報(bào)告。

7：Jenkins持續(xù)集成。

利用Jenkins，驅(qū)動(dòng)Main 函數(shù)，實(shí)現(xiàn)每日構(gòu)建，代碼改動(dòng)構(gòu)建。并集成Test report模塊，Email Report模塊，實(shí)現(xiàn)測(cè)試框架的閉環(huán)。

我們?cè)賮砜匆幌逻@個(gè)框架的文件結(jié)構(gòu)：

其中，a**20, ?common, **_common對(duì)應(yīng)? 0：core framework，pages，entity , tests對(duì)應(yīng)2：AUT，setings，對(duì)應(yīng) 1：config file。Main函數(shù)及report，screenshots等位于 **_common下。

以上就是iTesting項(xiàng)目組測(cè)試框架的使用情況，為了更好的理解測(cè)試框架，iTesting利用Python里的unittest和前文中測(cè)試框架設(shè)計(jì)思想，重新設(shè)計(jì)了一個(gè)簡(jiǎn)化版的測(cè)試框架，可以幫助你快速上手測(cè)試框架，請(qǐng)?zhí)砑有≈治⑿臖etterThinkBig獲取。