UI自动化中经常遇到例如也以下场景：需要经常对一个元素进行点击操作，我们会编写多处如下代码driver.find_element_by_id("login-btn").click()，如果开发人员修改了这个元素的id，测试人员需要维护所有对应用例里的代码，用例越多，给测试人员带来的维护工作量就越大，而PO则可以很好的解决这个问题，但其优点却不止如此。
一 、什么是PO？- PO（page object）的思想最早是2013年由IT大佬Martin Flower提出,经典图样如下图（大佬原文链接）2015年，Selenium官方给出了PO的设计原则说明
-
PO是一种设计模式。具有以下优点：
1）测试代码与页面的定位代码（如定位器或者其他的映射）相分离
2）该页面提供的方法或元素在一个独立的类中, 而不是将这些方法或元素分散在整个测试中
这允许在一个地方修改由于UI变化所带来的所有修改。 -
PO模式的核心思想：分层
1）第一层 基础层（BasePage）：封装一些最基础的selenium的原生的api方法，元素定位，框架跳转等
2）第二层 PO层：元素定位、获得元素对象，页面动作
3）第三层 测试用例层（case）：业务逻辑，数据驱动
三者的关系：PO层继承继承层，测试用例层调用PO层。注：PO不一定需要代表整个页面. PO设计模式可用于表示页面上的组件. 如果自动化测试中的页面包含多个组件, 则每个组件都有单独的页面对象, 则可以提高可维护性
| 非PO模式 | PO模式 |
|---|---|
| 面向过程的线性脚本 | POM把页面元素定位和业务操作流程分开。实现松耦合。 |
| 复用性差 | UI元素的改变不需要修改业务逻辑代码。只需要找到对应的PO页修改定位即可，数据代码分离 |
| 维护性差 | PO能使我们的测试代码提高代码的可读性，高复用性，可维护性。 |
若套用PO模式，慧测框架的basePage层已与其他独立开，但PO和case层未完全解耦，框架在PO层加了自动关闭窗口，PO层只能做到有限的封装，暂未有达到页面维度的封装。
如一开始提到的问题，一旦前端元素有变动，所有使用到该元素的case都需要进行维护， 随着自动化用例越来越多，自动化用例的维护工作量将越来越大，建议将po层独立开，且不局限以页面为单位，可以细化到页面各模块或组件。
