PO模式是一种自动化测试设计模式，将页面定位和业务操作分开，也就是把对象定位和测试脚本分开，从而提供可维护性。
一、简介PO是Page Object(页面对象)的缩写，PO模式是自动化测试项目开发实践的最佳设计模式之一，核心思想是通过对界面元素的封装减少冗余代码，主要体现在对界面交互细节的封装，也就是在实际测试中只关注业务流程；同时在后期维护中，若元素定位发生变化， 只需要调整页面元素封装的代码，提高测试用例的可维护性、可读性。
二、PO模式的三层结构PO模式可以把一个页面分为三层，对象库层、操作层、业务层。
（一）对象库层Base（基类）：封装page 页面一些公共的方法，如初始化方法、查找元素方法、点击元素方法、输入方法、获取文本方法、截图方法等
注意：
以上方法封装时候，解包只需一此，在查找元素解包*loc； driver 为虚拟，谁调用 base 时，谁传入，无需关注从哪里来； loc：真正使用 loc 的方法只有查找元素方法使用；
（二）操作层 page(页面对象)：封装对元素的操作，一个页面封装成一个对象；
思路：继承 Base; 实现： 模块名： 实际操作模块名称 如：page_login.py 页面对象类名：以大驼峰方法将模块名抄进来，有下划线去掉下划线，如class PageLogin(Base); 方法：涉及元素，将每个元素操作单独封装成一个操作方法； 组装：根据需求组装以上操作步骤。
（三）业务层 scripts（业务层）：将一个或多个操作组合起来完成一个业务功能。比如登录：需要输入帐号、密码、点击登录三个操作。
思路：导包调用 page 页面 实现： 模块：test+实际操作模块名称 如：test_login.py 测试业务类名：以大驼峰方法将模块名抄进来，有下划线去掉下划线,如class TestLogin(unittest.TestCase): 方法： ① 初始化方法 setUp() 注：在 unittest 框架中不能使用 def init()初始化方法； #实例化 页面对象 #前置操作 如：打开网址等 ② 结束方法 teardown #关闭驱动 ③ 测试方法 #根据要操作的业务来实现
三、实例为更好的理解PO模式，下面采用版本迭代的方式来学习，便于对不同版本的优缺点进行对比和理解。
（一）版本 V1：不使用任何设计模式和单元测试框架(线性模型) V2：使用UnitTest管理用例 V3：po 模式编写 V4: po模式优化 + 数据驱动
（二）案例说明 对TPshop项目的登录模块进行自动化测试，以账号不存在及密码错误为例作为测试用例。
账号不存在 点击首页的‘登录’