大家好,我是金鱼座,一个走在测试领域这片蓝海中, 蹉跎前行的技术渣渣,唯有一直走下去,也许能改变点什么,加油!
最近公司老大需要让我给一个项目做自动化的设计, 本身自己对于自动化实战经验不够,但是由于长期泡群,也接触过一些相关的设计思路,所以最早学习的审核自己也简单的自学过几个自动化脚本
详见:
线性脚本篇: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类操作的效率大大提示,因为当我每次操作一个业务流程时,更多的时候都是需要进行元素定位,每个定位元素都是具有标签信息的,我们可以一般定位一边无脑的编写操作流程,这也许也是一种享受。
网友评论