PO设计模式详解

 

一、传统模式

• 重用性低：登录功能重复

• 可维护性差：数据和代码混合

• 可读性差：元素定位方法杂乱（id、xpath、css混杂）

• 可读性差：不易识别操作的含义（特别是css和xpath语法）

• 可维护性差：如果某个元素的属性改了，你要更改多次

 

二、PO模型

• Page Object Model 页面对象模型

• PO是自动化测试项目开发实践的最佳设计模式之一

 

设计准则

地址：https://github.com/SeleniumHQ/selenium/wiki/PageObjects

 

1. The pulic methods represent the services that the page offers

   1. 使用公共方法来代表页面提供的服务

   2. 基类（基础服务：页面的基础的服务：点击元素，输入内容）

   3. 页面类：登录、添加商品

    

2. Try not to expose the internals of the page

   1. 不要暴露页面的内部细节（比如元素 ，元素的定位方法等），隔离了测试用例和业务和页面对象

    

3. Generally don't make assertions

   1. PO本身通常（绝）不应进行判断或断言. 判断和断言是测试的一部分, 应始终在测试的代码内, 而不是在PO中. PO用来包含页面的表示形式, 以及页面通过方法提供的服务, 但是与PO无关的测试代码不应包含在其中

    

4. Methods return other PageObjects

   1. 方法返回其他的页面对象，进行页面的关联

   2. 登录->首页，首页->添加商品，推荐正向返回

    

5. Need not represent an entire page

   1. PO不一定需要代表整个页面，定义你所需要实现的业务的部分即可，所以在我们的测试中有的页面对象可以非常简单（用什么写什么）. PO设计模式可用于表示页面上的组件. 如果自动化测试中的页面包含多个组件, 则每个组件都有单独的页面对象, 则可以提高可维护性.

    

6. Different results for the same action are modelled as different methods

   1. 相同的操作（但可能是不同的数据）带来的不同的结果可以封装成不同的方法。

补充：

1. 实例化PO时, 应进行一次验证, 即验证页面以及页面上可能的关键元素是否已正确加载. 在上面的示例中, SignInPage和HomePage的构造函数均检查预期的页面是否可用并准备接受测试请求（selenium官网提到的）

2. 上述只是一个经验总结，非强制

 

分层模型：

• 表现层：页面中可见的元素，都属于表现层（元素定位的编写）

• 操作层：对页面可见元素的操作。点击、输入文本、获取文本等（基类）

• 业务层：上面2层的组合，并联合到一起形成某个业务动作，在页面中对若干元素操作后所实现的功能。（页面类的方法，也可以是多个页面的组合）

• 测试用例就是组合了1个或多个页面的方法，操作对应的元素，完成的测试。测试用例本身不在PO内

• 非PO结构和PO结构对比

 

 

• PO架构图

• 项目结构