Page Object 模式 python webdriver 版本
这里介绍下我近期对 PO 模式的理解, 整体思想是分层，让不同层去做不同类型的事情，让代码结构清晰，增加复用性
一般分两层或三层（也有四层的）：
两层：
- 对象逻辑层
- 业务数据层
三层：
- 对象库层
- 逻辑层
- 业务层
四层：
- 对象库层
- 逻辑层
- 业务层
- 数据层
不同层本质差不多
下面以登录为例子 （网上绝大多数都是以登录为例子，但登录只能让新手明白 PO 大概是怎样子，优势却很难传递出来）
普通方式：
PO 模式
对象库层
逻辑层
业务层
分析
一 代码量多了大概三倍， 代码量增加是一定的先忽略，后面重点讨论
二 分层之后真的易于维护吗？
我们来看下当元素发生变化的时候，只需要在对象库层找打对应元素修改。 咦？ 你会说普通方式不也一样吗， 看上去一样，其实有细微差异，而一些细微差异会导致很大不同
- 效率高 ： PO 模式每个元素有变量定义，更方便查找。 而普通方式得通过备注或上下文来推断效率低。 ps：随着 case 不断增加，海量元素的定义对于英语一般的同学挑战也大，有人说有谷歌翻译。定义的时候可以通过翻译， 但到时候回过来查过元素怎么办？ 翻译通常是 1 对多，我们当时选哪个？ 用哪个来搜索？ 这或许也是海量变量定义带来的困扰
- 复用多收益大： 当某个元素被多次引用的时候，只需要修改一处便可，而普通方式需要一处一处找出来并修改，可以看出来复用越多 PO 模式收益越大
当界面需求发生变化
- 1.新增或删除了一些功能点或调整操作步骤先后顺序，但上层业务不变
- 效率高 ：同理，PO 模式的逻辑层方法有具体定义，情况和元素发生变化一样 修改逻辑层，业务层不变。这样看来结构简单清晰，舒服更符合人类习惯， 普通方式就是继续堆 case
- 复用多收益大： 同样这里如果逻辑复用越多，PO 模式收益越大，因为对于 PO 模式来说都只需要修改一个地方多处受益
-
- 上层业务发生变化
看上去两者差异不大
小结
总得来看：
- case 越多使用 PO 模式会使你的代码结构更清晰
- 元素复用越多 PO 模式下维护非常容易
- 逻辑复用越多 PO 模式下维护非常容易（如果逻辑复用多，需要多考虑逻辑层的颗粒度）
- 元素/逻辑/数据复用越多应选择更多层的 PO 模式
好，我们再回过头来看看代码量大的问题，有没有办法精简一些呢？ 把 a*N 中的 a 变成 1.8, 1.5， 1.2， 甚至接近 1 呢？
开始下一轮探索:
探索 代码量大的问题
以三层 PO 为例我们大概的流程是这样的：
在对象库层，我们定义了元素，再为元素定义了一些基本的操作流， 在逻辑层 为集成了基本操作流，在业务层 组装逻辑 和 数据输入
看上去 第二 第三步骤 有点重复 能不能去掉？ 如果只剩下第一 四个步骤 那代码量瞬间就下来了 那该有多爽
试试看
如果去掉第二/三步骤，那意味着我们只需要定义元素，并在业务层需要指定操作的时候再自动生成对应所需操作。即需要时生成，用完后丢弃。
这里需要用到 python 下面的魔法方法 "getattribute"
思路：
在访问类 App 属性时挡截下来，历遍对象库层找到对应元素返回对应的对象类 App.LoginPage，而对象库层都继承了 BasePage 类，在 BasePage 中同样重构了"getattribute"，当 App.LoginPage 对象尝试调用 click() 之类的方法时，就临时绑定 click 方法（click/swip/get_text/set_text.....）。
这样做的话，就只需要编写元素对象库，在 业务层直接自由调用，即时生成，用完丢弃。 代码量大幅减少
对象库层 （这里使用 airtest 下面的 poco 控件识别框架举例，和 Appium Selenium 略微不同）
业务层
如此看来用例编写者就更接近只需要关注业务了
以下是关键思路的实现 以 App 类为例子 BasePage Element 大概相同
-
App 类
结尾
以上这近几天对 PO 的新认识，欢迎大家多多指点
添加部分具体代码
对象元素库层：
BasePage:
ScoutingPage：
业务层：
执行报告如下：
【资源分享】
下面这份资源，对于想学习【软件测试】的朋友来说应该是最全面最完整的备战仓库，希望也能帮助到你！
