当自动化与面向对象相遇-PO设计模式详解

当自动化与面向对象相遇-PO设计模式详解

主题内容内容：

1.PO模式详解

2.从0到1搭建PO模型框架

3.PO模式详解

4.什么是PO模式

PO/POM，即Page Object Model的简称。实际上就是按照面向对象的思想，把页面看做对象，把里面的元素进行封装。我们可以看下图，更加便于理解：

从图中可以看出PO模式主要分三层：

基础层BasePage：封装一些最基础的方法，元素定位，框架跳转等

PO层：元素定位、获得元素对象，页面动作

测试用例层：业务逻辑，数据驱动

三者的关系：PO层继承继承层，测试用例层调用PO层。

进一步理解：

页面对象模型(PO)是一种设计模式，用来管理维护一组页面元素的对象库

在PO下，应用程序的每一个页面都有一个对应的Page类

每一个Page类维护着该页面的元素集和操作这些元素的方法

1.2 PO模式与非PO模式

非PO模式

PO模式

面向过程的线性脚本

POM把页面元素定位和业务操作流程分开。实现松耦合。

复用性差

UI元素的改变不需要修改业务逻辑代码。只需要找到对应的PO页修改定位即可，数据代码分离

维护性差

PO能使我们的测试代码提高代码的可读性，高复用性，可维护性。

1.3 PO模式的基本原则

The public methods represent the services that the page offers

Try not to expose the internals of the page

Generally don't make assertions

Methods return other PageObjects

Need not represent an entire page

Different results for the same action are modelled as different methods

简单翻译：

用公共方法代表页面提供的功能

不要暴露页面元素到外部

一般不在方法内加断言

方法应该返回其他PO对象（可以是页面或者是断言数据等）

不需要封装页面内所有元素

同样的行为不同的结果可以封装成不同的方法

2.从0到1搭建PO模型框架

接上节课的微信登录例子，怎样把它变成PO模式的框架呢？先来做下分析：

封装页面，如：登录页面可以设计成LoginPage类

封装方法，如：登录页面的登录方法是login(username,password)

外部文件维护数，如：定位用户名和密码框的表达方法不写在代码里，放在外部文件中

页面元素属性化，如：只要涉及到要操作的元素名称，具体定位方式不在代码中，元素定位做到可以配置化，配置以键值对的形式存在。

2.1 深入理解PO基本原则，遵循设计步骤

根据前面的理论知识，举个登录的例子，首先梳理一遍登录流程：

要进行一次成功的登录，需要做哪些事情？

要进入登录页面，需要经过哪些页面？

要能够完成登录操作，需要操作哪些元素？

要完成这些元素的操作，又需要哪些操作？

经过分析，我们不难知道：

要进行一次成功的登录：需要进入首页，然后点击登录按钮，再在登录页面输入正确的用户名和密码，最后点击登录按钮

要进入登录页面：成功进入首页，然后点击登录按钮

要能够完成登录操作：需要用户名和密码输入框、登录按钮

要完成这些元素操作：需要senk_key()、click()的方法

接下来可以记录下，完成登录的操作，一共经过两个页面：首页和登录页，当然为了简化起见，可以直接从登陆页开始。这里就确定了PO设计中的页面设计。

再根据前面PO模型的结构：可以把整个脚本再拆开，建立几个包：page、testcase等等。

把所有的页面放到page中，把测试用例放到testcase中，我们就可以得到下图的结构：

2.2 App启动的及日志封装：__init__.py 

2.3 BasePage编写：base_page.py 

2.4 登录页面编写：login_page.py 

2.5 测试用例编写：test_demo.py 

经过PO模式的整理，让脚本不再是脚本，这就是成型的测试框架，当然后续为了更加方便的引用自动化，可以把代码进一步优化，并且加入持续集成。

END

免费领取软件测试课程笔记+超多学习资料+学习完整视频，可以关注我们官方公众号哦：特斯汀软件测试

本文著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。