前面提到過 UI 自動化測試最大的障礙或者成本最大的地方就在于頁面的頻繁變化奋隶。UI 自動化測試過于依賴于界面，界面變化意味著你的代碼無法使用啊胶，需要更新維護潭苞。
雖然我們可以通過選擇更有效的用例來達到降低維護成本的目的，但是畢竟以涉及到 UI 元素變化，我們的代碼就需要改變雌团。
目前 UI 自動化測試中最流行和達成共識的做法是是采用 Page Object (簡稱 PO) 設計模式燃领，使用這種模式可以有效降低 UI 自動化測試代碼的維護量。
那么它是如何降低代碼維護量的呢锦援？
基本思想：
在 UI 自動化測試中對頁面元素的處理引入面向對象思想猛蔽。從測試用例中剝離頁面元素操作，并以頁面為單位的類將頁面元素上的定位方式及操作進行封裝灵寺。
什么意思呢曼库？不采用 PO 模式的時候，我們相當于在測試用例中直接調用 Selenium 中的各種 API略板，由這些 API 去操作頁面元素毁枯。而 PO 模式相當于在測試用例和 Selenium 之間增加了一層 PO 層。通過自定義的頁面元素叮称，再去調用 Selenium 中的 API种玛，同時也將測試用例與 Selenium 的元素操作做了分離。
也就是說颅拦，你的測試用例 TestCase 中不會再出現(xiàn)諸如 find_element() 之類的方法了蒂誉。
通過對頁面元素的封裝，將頁面涉及到的元素定位和操作全部集中到了一起距帅，不會再零散的出現(xiàn)在各個測試用例中右锨。
當頁面發(fā)生變化時，你不需要到各個測試用例中去查找需要修改的代碼碌秸，只需要在對應的頁面類中去修改其定位方式和操作即可绍移。
比如首頁上有一個菜單，每個模塊的頁面入口都在這里讥电。也就是你的幾乎每個測試用例中都會涉及到去點擊菜單蹂窖。
突然某一天，產(chǎn)品經(jīng)理要求修改這種菜單（可能因為太難看恩敌，可能因為用戶不太喜歡這種模式瞬测、也許老板覺得不夠高大上等等），菜單中的標簽類型和屬性變的面目全非纠炮。
當修改完成后月趟，你去運行你的測試腳本，突然一片紅色的 Fail恢口，讓你有點不知所措孝宗。然后逐個去修改頁面中關于菜單點擊的代碼，共修改了 xx 個文件 nxx 個用例 nxx 行代碼耕肩。
好不容易處理完畢了吧因妇！產(chǎn)品經(jīng)理說了问潭，要改回去，因為...??
如果你采用了 PO 模式婚被，不用關心自己有沒有第三方責任險了狡忙，因為不用動手了。
為什么會有這么大的改觀呢址芯？這得益于你將菜單的元素定位和點擊操作全部寫在了mainpage.py文件去枷，因為你只需要修改 1 個文件 x 行代碼即可，那些 xx 數(shù)量級的文件和用例都不用去動了是复。
通過在 UI 自動化測試中引入 PO 設計模式，可以大大提高自動化測試代碼的可維護性竖螃。
