Page Object是Selenium自動化測試項目開發實踐的最佳設計模式之一,它主要體如今對界面交互細節的封裝,這樣可使測試方案更關注於業務而非界面細節。從而提升測試案例的可讀性。web
Page Object設計模式的優勢以下:編程
減小代碼的重複設計模式
提升測試用例的可讀性瀏覽器
提升測試用例的可維護性,特別是針對UI頻繁變化的項目。函數
當爲Web頁面編寫測試時,須要操做該Web頁面上的元素。然而,若是在測試代碼中直接操做HTML元素,那麼你的代碼是及其脆弱,由於UI常常變更。咱們能夠將一個page對象封裝成一個HTML頁面,而後經過提供的應用程序特定的API來操做頁面元素,而不是在HTML中四處搜尋。測試
Page Object原理:網站
page對象的一個基本經驗法則是:凡是人能作的是,page對象經過軟件客戶端都可以作到。所以,它也應當提供一個易於編程的接口並隱藏窗口中底層的部分。因此訪問一個文本框應該經過一個訪問方法(accessor method)來實現字符串的獲取與返回,複選框應當使用布爾值,按鈕應當被表示爲行爲導向的方法名。page對象應當將在GUI控件上因此查詢和操做數據的行爲封裝爲方法。一個好的經驗法則是,即便改變具體的控件,page對象的接口也不該當發生變化。ui
儘管該術語是「頁面」對象,但並不意味着想要針對每一個頁面創建一個這樣的對象,例如,頁面有重要意義的元素能夠獨立爲一個page對象。經驗法則的目的是經過給頁面建模,使其對應用程序的使用者變得有意義。 url
下面以登陸126郵箱爲例,經過Page Object設計模式來實現。spa
from selenium import webdriver from selenium.webdriver.common.by import By from time import sleep #建立基礎類 class BasePage(object): #初始化 def __init__(self, driver): self.base_url = 'https://mail.qq.com/' self.driver = driver self.timeout = 30 #定義打開登陸頁面方法 def _open(self): url = self.base_url self.driver.get(url) self.driver.switch_to.frame('login_frame') #切換到登陸窗口的iframe #定義定義open方法,調用_open()進行打開 def open(self): self._open() #定位方法封裝 def find_element(self,*loc): return self.driver.find_element(*loc) #建立LoginPage類 class LoginPage(BasePage): username_loc = (By.ID, "u") password_loc = (By.ID, "p") login_loc = (By.ID, "login_button") #輸入用戶名 def type_username(self,username): self.find_element(*self.username_loc).clear() self.find_element(*self.username_loc).send_keys(username) #輸入密碼 def type_password(self,password): self.find_element(*self.password_loc).send_keys(password) #點擊登陸 def type_login(self): self.find_element(*self.login_loc).click() #建立test_user_login()函數 def test_user_login(driver, username, password): """測試用戶名/密碼是否能夠登陸""" login_page = LoginPage(driver) login_page.open() login_page.type_username(username) login_page.type_password(password) login_page.type_login() #建立main()函數 def main(): driver = webdriver.Chrome() username = '' #qq號碼 password = '' #qq密碼 test_user_login(driver, username, password) sleep(3) driver.quit() if __name__ == '__main__': main()
使用本身的帳號密碼登陸,我把代碼中的帳號密碼刪掉了。
#建立基礎類 class BasePage(object): #初始化 def __init__(self, driver): self.base_url = 'https://mail.qq.com/' self.driver = driver self.timeout = 30 #定義打開登陸頁面方法 def _open(self): url = self.base_url self.driver.get(url) self.driver.switch_to.frame('login_frame') #切換到登陸窗口的iframe #定義定義open方法,調用_open()進行打開 def open(self): self._open() #定位方法封裝 def find_element(self,*loc): return self.driver.find_element(*loc)
首先建立一個基礎類BasePage,在初始化方法__init__()中定義驅動(driver),基本的URL(base_url)和超時時間(timeout)等。
定義open()方法用於打開URL網站,但它自己並未作這件事情,而是交由_open()方法來實現,而find_element()方法用於元素的定位。
Page類中定義的這些方法都是頁面操做的基本方法。下面根據登陸頁的特色再建立LoginPage類並繼承Page類,這也是Page Object設計模式中最重要的對象層。
#建立LoginPage類 class LoginPage(BasePage): username_loc = (By.ID, "u") password_loc = (By.ID, "p") login_loc = (By.ID, "login_button") #輸入用戶名 def type_username(self,username): self.find_element(*self.username_loc).clear() self.find_element(*self.username_loc).send_keys(username) #輸入密碼 def type_password(self,password): self.find_element(*self.password_loc).send_keys(password) #點擊登陸 def type_login(self): self.find_element(*self.login_loc).click()
LoginPage類中主要對登陸頁面上的元素進行封裝,使其成爲更具體的操做方法。例如,用戶名、密碼和登陸按鈕都被封裝成了方法。
#建立test_user_login()函數 def test_user_login(driver, username, password): """測試用戶名/密碼是否能夠登陸""" login_page = LoginPage(driver) login_page.open() login_page.type_username(username) login_page.type_password(password) login_page.type_login()
test_user_login()函數將單個的元素操做組成一個完整的動做,而這個動做包含了打開瀏覽器,輸入用戶名/密碼、點擊登陸等單步操做。在使用該函數時須要將driver、username、password等信息做爲函數的實參,這樣該函數具備很強的可重用性。
#建立main()函數 def main(): driver = webdriver.Chrome() username = '' #qq號碼 password = '' #qq密碼 test_user_login(driver, username, password) sleep(3) driver.quit() if __name__ == '__main__': main()
main()函數更接近於用戶的操做行爲。對用戶來講,要進行郵箱的登陸,須要關心的就是經過哪一個瀏覽器打開郵箱網址、登陸的用戶名和密碼是什麼,至於輸入框、按鈕是如何定位的,則不須要關心。
這樣分層的好處是,不一樣的層關心不一樣的問題。頁面對象層值關心元素的定位問題,測試用例只關心測試的數據。
一個有分歧的地方是page對象是否應自身包含斷言,或者僅僅提供數據給測試腳本設置斷言。在page對象中包含斷言的倡導者認爲,這有助於避免在測試腳本中出現重複的斷言,能夠更容易的提供更好的錯誤信息,而且提供更接近製做不問風格的API。再也不page對象中包含斷言的倡導者則認爲,包含斷言會混合訪問頁面數據和實現斷言邏輯的責任,而且致使page對象過於臃腫。
我比較同意在page對象中不包含斷言,雖然完美能夠經過爲經常使用的斷言提供斷言庫的方式來消除重複,提供更好的診斷,但從用戶的角度去自動化的觀點來看,判斷是否登陸成功是用戶須要作的事情,不該該交由頁面對象層來完成。
使用Page Object模式以後的另一個好處就是有助於下降冗餘。若是須要在10個用例中輸入不一樣的用戶名/密碼登陸,那麼用main()方法寫將變得很是簡潔。
所以,Page Object模型的做用在一個測試人員本身寫主場景測試案例時不容易體會到的,由於你不須要和開發、業務交流案例,也不會寫不少重複的動做。可是,當你真正開始測試ATDD或BDD,當你開始寫一些重要的異常分支流程時,當你開始爲新需求頻繁維護修改案例時,就會意識到Page Object的做用。
最後,Page Object不是萬靈藥,也不是惟一方案,提升測試案例的可讀性,避免案例步驟冗餘纔是終極目標。