PO模式是在UI自動化測試過程當中使用非常頻繁的一種設計模式，使用這種模式后，可以有效的提升代碼的復用能力，并且讓自動化測試代碼維護起來更加方便。
PO模式的全稱叫page object model（POM），有時候叫做 page object pattern。最開始由馬丁福勒提出，這個模式受到selenium自動化測試框架大力推廣，因而成為一種非常主流的自動化測試設計模式。
在PO模式當中，每一個UI頁面使用編程語言當中的類來表示。在這個類當中，通過函數形式定義頁面的行為和操作。這讓調用方不需要關注具體執行的操作到底是點擊還是拖動，而是關注具體的業務，比如登錄、購物等等，甚至如果程序員直接把代碼給產品經理看，他也是能看懂的。
沒有使用PO模式時
在測試用例中直接編寫瀏覽器操作API，對于代碼編寫者并沒有多高的難度，因為他自己已經對這些API非常熟悉，但是這些瀏覽器操作并不能體現業務，至少沒有產品經理那么熟悉，因此他很難和產品經理進行溝通，也難和開發溝通，甚至在半個月之后，他已經忘記了自己到底寫了什么東西。
def test_login_mail(self):driver = self.driverdriver.get("http://www.xxx.xxx.com")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模式有利于梳理業務，也有利于和其他人進行溝通。當你把下面這段代碼拿給產品經理看的時候，他也大概能知道你測的是什么業務，能幫你糾正你的測試流程是否正確，或者提出一些更有建設性的意見，這對于大型項目需要頻繁溝通和梳理業務時非常有用。
def test_login_mail(self):LoginPage(driver).login()而瀏覽器本身的操作，就會被分離到一個更底層的模塊，這些代碼你可以不對調用方暴露，產品經理并不關心你這個頁面中什么元素定位，他也不懂。
class LoginPage:username_loc=(By.ID,"idInput")password_loc =(By.ID,"pwdInput")submit_loc =(By.ID,"loginBtn")span_loc=(By.CSS_SELECTOR,"div.error-tt>p")dynpw_loc =(By.ID,"lbDynPw")userid_loc =(By.ID,"spnUid")def __init__(self, driver):self.driver = driverdef login(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 方式來表示元素，所有的元素統一放在一起，修改起來也比較方便。
class LoginPage:def __init__(self, driver)self.driver = driver@propertydef username_element(self):return self.driver.find_element('id', 'idInput')@propertydef password_element(self):return self.driver.find_element('id', 'pwdInput')@propertydef submit_element(self):return self.driver.find_element('id', 'loginBtn')def login(self, name, password):self.username_element.send_keys(name)self.password_element.send_keys(password)self.submit_element.click()第三種方式可以充分利用Python的描述符特性，你會發現很多序列化庫或者ORM框架都有類似的用法。
class LoginPage:def __init__(self, driver)self.driver = driverusername = Element(css='#idInput', desc='用戶名輸入框')password = Element(css='#pwdInput', desc='密碼輸入框')confirm = Element(css='#loginBtn', desc='登錄確認按鈕')def login(self, name, password):self.username.send_keys(name)self.password.send_keys(password)self.confirm.click()而 Element 類可以通過 Python 描述符實現，這里為了方便，只定義了xpath的元素定位方法：
class Element:def __init__(self,xpath=None,desc=''):self.xpath = xpathself.desc = descdef __get__(self, instance, owner):driver = instance.browserel = driver.find_element('xpath', self.xpath)return elPO模式和DDD
PO模式是DDD(領域驅動設計)的一個簡單實現，但是還不夠徹底。如果要在自動化測試中貫徹DDD，我覺得還有一些可以優化的空間。
首先某一個業務不一定只是單個頁面的操作，比如登錄不一定只涉及到LoginPage這個頁面，因此直接在LoginPage中編寫login函數就不是很合理。對于調用方來說，應該明確說明的是誰在登錄，而不是指某個頁面。像這樣：
user.login()
# or
login(user)我們編寫的代碼就像是自然語言，任何懂英語的人都知道代碼在做什么，在DDD中，叫做領域特定語言（DSL）， 要實現這種邏輯，在Page類和調用中間應該還會有一個層級來封裝user。
其次，Page頁面會依賴更底層的資源，比如組件，元素類型。因此在 Page 類的下方應該會使用 InputElement， ButtonElement 、SelectElement 這樣的元素類和 HeaderComponent、FooterComponent 這樣的組件類。
class LoginPage:username_filed = InputElement('xxx')password_filed = PasswordElement('xxx')領域驅動設計對于大型項目梳理業務、同步業務、溝通業務是非常有幫助的，是一種以業務為中心的設計范式。PO模式對于DDD的小范圍應用，以及具體了足夠多的好處：
便于維護。每一個頁面的操作都被單獨的存放在一個類文件中，當前端頁面被修改之后，只需要找到對應類文件進行修改，其他的代碼并不需要進行修改，這符合單一職責原則。
便于重復使用。在進行自動化測試的時候，一個測試由多個測試步驟組成，這些測試步驟可能涉及到多個頁面的操作。而用例與用例之間的操作可能重合。PO模式可以重復利用這些測試步驟，簡化代碼的編寫。
提高了可讀性。頁面的操作都被以函數的形式封裝起來了。函數名就具備注釋的作用，其他人閱讀代碼時可以通過函數了解業務。
總結：
感謝每一個認真閱讀我文章的人！！！
作為一位過來人也是希望大家少走一些彎路，如果你不想再體驗一次學習時找不到資料，沒人解答問題，堅持幾天便放棄的感受的話，在這里我給大家分享一些自動化測試的學習資源，希望能給你前進的路上帶來幫助
軟件測試面試文檔
我們學習必然是為了找到高薪的工作，下面這些面試題是來自阿里、騰訊、字節等一線互聯網大廠最新的面試資料，并且有字節大佬給出了權威的解答，刷完這一套面試資料相信大家都能找到滿意的工作。
?
?
