大家好，我是金鱼座，一个走在测试领域这片蓝海中， 蹉跎前行的技术渣渣，唯有一直走下去，也许能改变点什么，加油！
最近公司老大需要让我给一个项目做自动化的设计， 本身自己对于自动化实战经验不够，但是由于长期泡群，也接触过一些相关的设计思路，所以最早学习的审核自己也简单的自学过几个自动化脚本
详见：
线性脚本篇：https://www.jianshu.com/p/dc14cb7e5570
简单PO篇：https://www.jianshu.com/p/8384a6985704
改版PO篇：https://www.jianshu.com/p/06da75c65a5b
由于文章是在学习的时期写的，对于大N，大家可以忽略， 不过对于初学者可以简单看看，也算是一种理解思路
由于之前用的是py2和unittest，而自己现在日常的代码都是py3和pytest，所以决定重新设计，下面说下自己的对于PO的一次简单升级CPO（姑且自己这么叫）
PO模式
PO我们都知道是PageObject的设计思路，通过page对象对页面操作的封装，结合适当的参数化处理，做到用例层和逻辑层与对象层的分离。方便用户后期对数据和用例的处理
CPO模式
CPO是我自己认知的简称（Component PageObject）看这个单词大家应该就知道组件化思路，再seleniumApi和Page之间增加一层封装Component层
为什么基于这种考虑？
普通的PO模式，我们最喜欢的就是增加一个BasePage，然后所有的Page来继承该Page类所有selenium封装，这种方式本身没有任何问题，但是我个人的感觉就是有个比较奇怪的问题，就是这种po模式下，实际上再其他page页面中还是会参杂的使用selenium的方法，这让我感觉体验很不好，并且无法很好的对page中的操作层有个很好的操作表达, 比如：
# 登录到一个平台
loginpage一般的处理代码：
class LoginPage(BasePage):
#输入用户名
def type_username(self,username):
self.find_element(*self.username_loc).clear()
self.find_element(*self.username_loc).send_keys(username)
那么如果是我所谓的CPO的模式是什么样子的呢？
“见文知意” 是我期望的，也是我们日常对基础api或者方法做二次封装的一个目的，那么基于这种考虑，我考虑一种将人的视角，转移到人操作的对象的视角，比如人点击一个按钮，实际本质是这个按钮的元素触发了点击事件，基于这种考虑， 我在pageobjec层上面增加了一个组件层，主要用来封装各种操作对象，让实际编写page类和case的人员完全脱离seleniumApi，达到更高的代码理解速度和编写速度，如下代码：
class LoginP():
def input_name(self, name):
Input(self.driver).input_text(LoginP.user_loc, name)
def input_search_user(self, value):
Input(self.driver).input_text(UserP.search_loc, value)
KeyBoard(self.driver).Enter(UserP.search_loc)
观察上面的两种对比：
CPO模式再使用难度上面大大减少，一个普通的测试就可以很快的对Page类进行封装
那么CPO有哪些优势？
- 操作员不需要对selenium的基本知识有相关了解
- page的操作流程再定位期间就可以无压力的对逻辑操作进行编写
- 可以了解到当前页面的涉及的html操作元素，具有提示作用
总结： 这个方式也许不是最好的， 但是就自己使用期间明显能够感受到page类操作的效率大大提示，因为当我每次操作一个业务流程时，更多的时候都是需要进行元素定位，每个定位元素都是具有标签信息的，我们可以一般定位一边无脑的编写操作流程，这也许也是一种享受。
