第PO模式在selenium自動化測試框架的優勢PO模型是:PageObjectModel的簡寫頁面對象模型

作用：就是把測試頁面和測試腳本進行分離，即把頁面封裝成類，供測試腳本進行調用;

分層機制，讓不同層去做不同類型的事情，讓代碼結構清晰，增加復用性。

PO設計模式是Selenium自動化測試中最佳的設計模式之一，主要體現在對界面交互細節的封裝

2.不使用PO設計會出現以下幾種情況：

復用性不太好，擴展性不好，易讀性差，不好維護，UI界面頻繁的項目維護起來比較麻煩。

3.PO模式的優缺點

優點：

提高代碼的可讀性減少了代碼的重復提高代碼的可維護性，特別是針對UI界面頻繁的項目

缺點：

造成項目結構比較復雜，因為是根據流程進行了模塊化處理

下面重點看下PO模式在selenium自動化測試框架的優勢。

PO模式是在UI自動化測試過程當中使用非常頻繁的一種設計模式，使用這種模式后，可以有效的提升代碼的復用能力，并且讓自動化測試代碼維護起來更加方便。

PO模式的全稱叫pageobjectmodel（POM），有時候叫做pageobjectpattern。最開始由馬丁福勒提出，這個模式受到selenium自動化測試框架大力推廣，因而成為一種非常主流的自動化測試設計模式。

在PO模式當中，每一個UI頁面使用編程語言當中的類來表示。在這個類當中，通過函數形式定義頁面的行為和操作。這讓調用方不需要關注具體執行的操作到底是點擊還是拖動，而是關注具體的業務，比如登錄、購物等等，甚至如果程序員直接把代碼給產品經理看，他也是能看懂的。

沒有使用PO模式時

在測試用例中直接編寫瀏覽器操作API，對于代碼編寫者并沒有多高的難度，因為他自己已經對這些API非常熟悉，但是這些瀏覽器操作并不能體現業務，至少沒有產品經理那么熟悉，因此他很難和產品經理進行溝通，也難和開發溝通，甚至在半個月之后，他已經忘記了自己到底寫了什么東西。

deftest_login_mail(self):

driver=self.driver

driver.get("")

driver.find_element_by_id("idInput").clear()

driver.find_element_by_id("xxxxxxx").send_keys("xxxxx")

driver.find_element_by_id("xxxxxxx").clear()

driver.find_element_by_id("xxxxxxx").send_keys("xxxxxx")

driver.find_element_by_id("loginBtn").click()

使用PO模式

使用PO模式有利于梳理業務，也有利于和其他人進行溝通。當你把下面這段代碼拿給產品經理看的時候，他也大概能知道你測的是什么業務，能幫你糾正你的測試流程是否正確，或者提出一些更有建設性的意見，這對于大型項目需要頻繁溝通和梳理業務時非常有用。

deftest_login_mail(self):

LoginPage(driver).login()

而瀏覽器本身的操作，就會被分離到一個更底層的模塊，這些代碼你可以不對調用方暴露，產品經理并不關心你這個頁面中什么元素定位，他也不懂。

classLoginPage:

username_loc=(By.ID,"idInput")

password_loc=(By.ID,"pwdInput")

submit_loc=(By.ID,"loginBtn")

span_loc=(By.CSS_SELECTOR,"div.error-ttp")

dynpw_loc=(By.ID,"lbDynPw")

userid_loc=(By.ID,"spnUid")

def__init__(self,driver):

self.driver=driver

deflogin(self):

self.driver.find_element(*self.username_loc).clear()

self.driver.find_element(*self.username_loc).send_keys("xxxxx")

self.driver.find_element(*self.password_loc).clear()

self.driver.find_element(*self.password_loc).send_keys("xxxxxx")

self.driver.find_element(*self.submit_loc).click()

這種方式把元素定位方式也分離了。但是這種元素定位的表達式可讀性也不是很強，可以換用property方式來表示元素，所有的元素統一放在一起，修改起來也比較方便。

classLoginPage:

def__init__(self,driver)

self.driver=driver

@property

defusername_element(self):

returnself.driver.find_element('id','idInput')

defpassword_element(self):

returnself.driver.find_element('id','pwdInput')

defsubmit_element(self):

returnself.driver.find_element('id','loginBtn')

deflogin(self,name,password):

self.username_element.send_keys(name)

self.password_element.send_keys(password)

self.submit_element.click()

第三種方式可以充分利用Python的描述符特性，你會發現很多序列化庫或者ORM框架都有類似的用法。

classLoginPage:

def__init__(self,driver)

self.driver=driver

username=Element(css='#idInput',desc='用戶名輸入框')

password=Element(css='#pwdInput',desc='密碼輸入框')

confirm=Element(css='#loginBtn',desc='登錄確認按鈕')

deflogin(self,name,password):

self.username.send_keys(name)

self.password.send_keys(password)

self.confirm.click()

而Element類可以通過Python描述符實現，這里為了方便，只定義了xpath的元素定位方法：

classElement:

def__init__(self,xpath=None,desc=''):

self.xpath=xpath

self.desc=desc

def__get__(self,instance,owner):

driver=instance.browser

el=driver.find_element('xpath',self.xpath)

returnel

PO模式和DDD

PO模式是DDD(領域驅動設計)的一個簡單實現，但是還不夠徹底。如果要在自動化測試中貫徹DDD，我覺得還有一些可以優化的空間。

首先某一個業務不一定只是單個頁面的操作，比如登錄不一定只涉及到LoginPage這個頁面，因此直接在LoginPage中編寫login函數就不是很合理。對于調用方來說，應該明確說明的是誰在登錄，而不是指某個頁面。像這樣：

user.login()

login(user)

我們編寫的代碼就像是自然語言，任何懂英語的人都知道代碼在做什么，在DDD中，叫做領域特定語言（DSL），要實現這種邏輯，在Page類和調用中間應該還會有一個層級來封裝user。

其次，Page頁面會依賴更底層的資源，比如組件，元素類型。因此在Page類的下方應該會使用InputElement，ButtonElement、SelectElement這樣的元素類和HeaderComponent、FooterComponent這樣的組件類。

classLoginPage:

username_filed=InputElement('xxx')

password_filed=PasswordElement('xxx')

領域驅動設計對于大型項目梳理業務、同步業務、溝通業務是非常有幫助的，是一種以業務為中心的設計范式。PO模式對于DDD的小范圍應用，以及具體了足夠多的好處：

便于維護。每一個頁面的操作都被單獨的